[Location-Retrieval]: add `POINT` as possible Location response

[maxl2287]

Problem description When the network responds with a geographical Point than the /retrieve - endpoint should also handle this shape and return it.

Possible evolution Add a POINT as areaType

    Area:
      type: object
      properties:
        areaType:
          $ref: "#/components/schemas/AreaType"
      required:
        - areaType
      discriminator:
        propertyName: areaType
        mapping:
          CIRCLE: "#/components/schemas/Circle"
          POINT: "#/components/schemas/Point"
          POLYGON: "#/components/schemas/Polygon"
    AreaType:
      type: string
      description: |
        Type of this area.
        CIRCLE - The area is defined as a circle.
        POLYGON - The area is defined as a polygon.
        POINT - The area is defined as a point.
      enum:
        - CIRCLE
        - POLYGON
        - POINT

Alternative solution Solution how to map a Point location to an existing areaType (Circle with radius = 0).

[alpaycetin74]

This is reasonable. The Mobile Location Protocol (MLP) also recognizes point as a separate shape. Having said that, POINT location is quite rare. It is possible in GPS-assisted methods.

[jlurien]

As you say, a point is like a circle of radius=0. Even for commercial GPS systems, precision (radius) is in the order of few meters. Current CIRCLE allows a minimum of 1m. A POINT would only makes sense for cases of extreme precision, when the implementation is not revealing the radius, which should be very close to a meter. @maxl2287 is there a use case for this or is it just a hypothetical case to cover the MLP point?

[maxl2287]

@jlurien We have a connected NEF which is responding with geographicalArea as a Point. And currently our implementation cannot handle this with only CIRCLE and POLYGON.

That's why this issue here was created.

[jlurien]

It would be great if all devices were located as points :) I think we have the option to map Point to CIRCLE with radius=1m, or define an specific geometry for it. If it were a usual case that NEF responses with points, it would make sense to define it, but if that is very rare in practice, defining a point may create false expectations for customers. Wdyt @bigludo7? As you are leading this API.

[bigludo7]

Worth to have a discussion on this on next meeting. From my perspective I tend to share @jlurien view but if @maxl2287 has real UC & capabilities to provide a POINT precision we should be discuss this. @maxl2287 even if your NEF send you a technically a POINT should not be anyway considered as a circle with a minimum accuracy ?

Got the point on the 'false' expectation but as we already have in the yaml a minimum of 1 meter it will not change a lot on this topic.

[jlurien]

Discusses in meeting. General consensus is that is very unlikely that points are returned by networks in practice, and to cover all theoretical mappings, we can still assimilate a point to a circle with the minimum allowed radius. But we keep the issue open for further discussion.

[maxl2287]

I am okay with the fact that we use here than a circle with a minimum accuracy. So we can also close this issue.

WDYT @jlurien & @bigludo7 ?

[bigludo7]

Agreed to close it for me.

[jlurien]

POINT will be assimilated to a CIRCLE with the minimum allowed radius