problem with location encoding

[ksonda]

I believe the way the geometry is being represented in the Location and FoI entities is wrong, or maybe its an ambiguity in the STA standard spec, but the way it's done here is different from hydroserver2.

Compare https://beta.hydroserver2.org/api/sensorthings/v1.1/Locations('dfbbf648-88e3-45fc-85e9-5204cfad4fcc'):

to the example in the STA docs

to the way FROST encodes: https://ogc-demo.k8s.ilt-dmz.iosb.fraunhofer.de/FROST-Server/v1.1/Locations(2)

As far as I know most clients are built on FROST but, other implementations that are more compliant with the spec won't work with those clients (namely one we are working on that surfaced this problem) because FROST isn't actually presenting GeoJSON within the 'location' element, but just GeoJSONish geometry

[ksonda]

This may not be an issue with the software but could be an issue with the documentation site under "Creating Entities", which for Locations provides guidance that does not match the example in the STA standard document. This guidance has evidently been followed by many of the USA endpoints as well as BRGM and BGS.

Perhaps in the sensorthings standard repo we can consider an amendment to the standard that says a valid feature of the specified encoding must be supplied. As it stands it's possible to create a client that behaves differently with two endpoints that both nominally comply with the STA spec but encode the "geo+json" location differently

And perhaps FROST can attempt to validate such encodings on entity creation

[hylkevds]

Any valid GeoJSON would be correct, if the encodingType is application/geo+json:

3. GeoJSON Object A GeoJSON object represents a Geometry, Feature, or collection of Features.

Both a full Feature and just a Geometry match the encodingType and are correct. Technically, a FeatureCollection would also be allowed, but that would be semantically incorrect... Since the point of the location field is to store the geometry, using a full feature makes not much sense, so most users use a Geometry object. FROST supports both. See for instance: https://ogc-demo.k8s.ilt-dmz.iosb.fraunhofer.de/FROST-Server/v1.1/Locations(4)

The PostGIS function ST_GeomFromGeoJSON doesn't support Feature objects, only Geometry objects, so if FROST detects a full feature it will extract the Geometry from it and use that for its spatial index column.

The SensorUP docs also use direct Geometry objects: https://developers.sensorup.com/docs/#locations_post

Most GeoJSON client libraries have no trouble dealing with either form, though it may be annoying to users that both forms are allowed. If we were to restrict this for V2, I'd prefer to specify that geometry objects must be used, since that results in compacter data.

[hylkevds]

On the other hand, with JSON-FG the full-feature form will have to be used, since it can contain both a geometry and place field, plus CRS information.