Open APIs

Hello all

In our joint work with Open Slice and Ubitech it will be very important to introduce geo-spatial coordinate locations in order to introduce points of presence.

The suitable API is the one introduced in TMF673_Geographic_Address/5.0.0. In the document one can find that the GeographicLocation ( which can be used to store the above) . As mentioned:

GeographicLocation can be instanciated as
* GeoJsonLineString
* GeoJsonMultiLineString
* GeoJsonMultiPoint
* GeoJsonMultiPolygon
* GeoJsonPoint
* GeoJsonPolygon

The problem that arises here is that there is no TMF documentation introducing these objects. One would expect to find something in https://www.tmforum.org/oda/open-apis/directory/geographic-location-management-api-TMF675/v4.0

Unfortunately there is no user guide/official document there for the objects mentioned above.

Could anyone help on this?

------------------------------
Anastasios Poimenidis
UBITECH
------------------------------

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
------------------------------