Open APIs

 View Only
  • 1.  TMF673_Geographic_Address/5.0.0 Geographic Location Design Gap

    Posted 2 days ago
    Edited by Anastasios Poimenidis 18 hours ago

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



  • 2.  RE: TMF673_Geographic_Address/5.0.0 Geographic Location Design Gap

    Posted yesterday
    Edited by Stephen Harrop yesterday

    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:

    GeoLocation v4 API Class Diagram

     

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



  • 3.  RE: TMF673_Geographic_Address/5.0.0 Geographic Location Design Gap

    Posted 18 hours ago
    Edited by Anastasios Poimenidis 15 hours ago

    Hi Stephen

    thanks a lot for your concrete reply and the acknowledgements. In the draft you are mentioning are all these objects like GeoJsonPolygon and Polygon presented in detail? 

    Also in another thought, I have no clue who should initiate the procedure in order to have this document available at some point.



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



  • 4.  RE: TMF673_Geographic_Address/5.0.0 Geographic Location Design Gap

    Posted 10 hours ago

    I'd be interested too please.



    ------------------------------
    Steve Ranford-Bragg
    BT Group plc
    ------------------------------