Hi Martin
The usage of place is common amongst many of the specs. I think it would be difficult to change this now.
Regarding the issue with type, are you sure this isn't because the pre-production TMF675 v4.0.0 API is wrongly using a type field within the GeoJsonPoint, GeoJsonMultiPoint, GeoJsonLineString, etc sub-classes? This type attribute needs to be renamed to geoType or something that doesn't class with the metadata @type field.
Your thoughts?
[Edited] On second thoughts the type attribute appears to contain the same value as the @type metadata value and should probably be removed altogether
------------------------------
Dan d'Albuquerque
Individual
------------------------------
Original Message:
Sent: Oct 13, 2020 06:39
From: Martin Goldhahn
Subject: TMF675: GeoLocation model makes generating server code difficult
Hi,
The GeoLocation model in The Geographic Location API (TMF675) is modelled as an extension of the Place model. The \@type on Place does not have enum restrictions, whereas the Geolocation has.
The code generator for Java now tries to generate GeograhicLocation as a subclass of Place overriding the property \@type, which is a string in Place and an enum in GeographicLocation.
I cannot see any reason for the use of the model Place. it is nowhere used in the service endpoints.
I use the latest published version of the swagger file at https://raw.githubusercontent.com/tmforum-apis/TMF675_GeographicLocation/master/TMF675-GeographicLocation-v4.0.0.swagger.json
Are there any plans to remove the Place model?
------------------------------
Martin Goldhahn
Altibox AS
------------------------------