Closed KathiSchleidt closed 2 years ago
Yes, that would be a great addition to the standard. I think every entity type except Observation (already has parameters) and HistoricalLocation (since it's autogenerated) should have a properties field.
Sensor/metadata does not really cover the use case, since it is likely not to be server-readable. If the datasheet for my sensor is a PDF, I would lose the ability to store other properties. The nice thing of the properties field is that it has to be JSON, and as a result the server can filter and sort on its fields.
The same goes for Location/location and FeatureOfInterest/feature. If the content type is WKT, the ability to save additional properties is lost. And even though geoJson objects have a properties field themselves, if the location is a featureCollection, you end up with multiple properties, and filtering becomes an issue again.
Seems to be addressed by commit: https://github.com/opengeospatial/sensorthings/commit/1218e535ec7a9e3aa8910b747d4eeac00b2d19f9 Though since it's not a stand-alone commit, it's not easy to see the exact changes.
Note: I've added a request for a description of the foreseen properties content to #4
Fixed with the publication of Sensing v1.1.
In order to provide fuller information, adding a properties element as in the Thing class would be most valuable. Through such an extension, we can even reach INSPIRE compliance :) The properties extension would be required for the following classes:
To my understanding, in Sensors the metadata element serves this purpose. What I'm not quite clear on is if the feature element of the FeatureOfInterest or the location element of Location can also be utilized for such additional information