Hi Anastasios,
Good point. The v4 of this API was never fully completed (into conformance profiles, reference implementations and test kits) so it has sat "half done" for some time. There was a User Guide produced internally, but I see that it has not been published on the v4 preview page.
The major change moving from v1 to v4 was the move from a simple "x,y" to the above set of Geometric primitives that mirror those of GeoJSON. I might get in TMF-trouble if I retrieve and publish an uncontrolled copy of the "never quite published" v4 user guide, but the class diagram that was buried into it is below:
The main concepts are:
- GeographicLocation itself now becomes an abstract base class to these geo-primitive subclasses
- Each of these mirror their equivalent GeoJSON construct
- The objective was to provide a TMF-API wrapper to the GeoJSON work - leaving the GeoJSON class model untouched
This might make it a little "clumsy" (eg: TMF has { "@type": "GeoJsonPolygon" } referring to a GeoJSON { "type": "Polygon" } with forced enumerations.
Since this version never got fully released it may not be fully battle-tested. I know that it has issues with:
- The forced
@type value can cause code-generation issues (since the subclass is constraining the otherwise open-string of the inherited "@type")
- The idea of six subclasses of an abstract-based-class of an abstract-base-class creates a "worst-case" schema dependency graph for anyone using a PlaceRefOrValue
- I'm not sure if the GeoJsonFeature/Feature construct is correct
If any TMF-ers are happy for me to generate and send out the v4 GeoLocation User Guide as an uncontrolled copy for info only - then I'm happy to do it!
------------------------------
Stephen Harrop
Principal Integration Architect
Vodafone Group
------------------------------