Coordinates have a "Nan" string as optional altitude parameter

[Ventis]

Hi,

using the SOS API, coordinates of stations always seem to have the optional altitude parameter filled in with "NaN". This doesn't follow the OGC GeoJSON standard specifications, which say that altitude is an optional parameter and thus should not be included if it isn't set. Keeping it as an "NaN" string might causes issues in certain tools that don't know how to handle that.
Example:
https://geo.irceline.be/sos/api/v1/stations

{
    "properties": {
          "id": 1030,
          "label": "40AL01 - Linkeroever"
     },
     "geometry": {
              "coordinates": [
                     4.385223684454717,
                     51.23619419990248,
                     "NaN"
               ],
               "type": "Point"
     },
     "type": "Feature"
}

It could be a bug with the 52North SOS implementation, I'm not sure.

[opeeters]

Thanks for the feedback, @Ventis. I will discuss this with the developers of the REST-api. We have this data in our underlying DB, but I can't find an element in the DB of the SOS/REST-api to map this to.

The current REST-api is not meant to be OGC-compliant, but rather a fast access endpoint to the data. There always is a trade-off between interoperability versus usability/performance. In this case I don't see any reason not to follow OGC specifications.

@ridoo or @CarstenHollmann, I can't find any altitude, neither in the 4.3.x, 4.4.x nor 5.3.x DB-model. Or am I missing something?

[ridoo]

Wouldn't an altitude be encoded in the geometry type itself? The GeoJSONEncode actually should ignore encoding NaN altitude values.

@opeeters What version is deployed at https://geo.irceline.be/sos/api/v1/stations?

[opeeters]

4.3.6: https://geo.irceline.be/sos/
4.3.16: https://geo.irceline.be/sos-staging/

Updating to 4.4.x is in our case (combination of materialized views and tables) pretty difficult due to e.g. changes to the series table (e.g. the seriestype element). Updating to 5.3.x is also not trivial, but will involve a lot more testing of existing clients.

[ridoo]

Ah thanks for the info.

It seems that an older version of the timeseries-api (the API is now called sensorweb-server-helgoland) does rather naive way to serialize coordinates. This has changed in some version (I did not check, yet).

I see two options on a first glimpse:

1. A patched version of the timeseries-io.jar
2. A SOS upgrade to 4.3.16 which should solve the issue (as it uses v1.10.1 of the timeseries-api which includes a more holistic way of serializing geojson)