Closed KathiSchleidt closed 4 years ago
Indeed, while the mapping table for EnvironmentalMonitoringFacility has an entry for the observingCapability property, it is not clear what type this is mapped to in GeoJSON (the table says "ObservingCapability", but this is not further defined in the spec). The complex type should either be represented as a string (then we would need to define how) or, maybe better, split into several properties.
The examples should also be updated to include this property.
I could see flattening the ObsCaps attributes into the basic EF FT, as long as there is only one ObsCaps per EF Question is what you do when one EF measures multiple ObservedProperties. With complex features, we foresaw 2 models:
Would option 1 work with simple features?
I've added the Observing Capabilities to the profile. Please review (PR coming in a moment) and feel free to suggest how to apply that to the examples.
Closing this since PR was merged and no further feedback given.
Would have been nice if this was also added to the examples as would make for better understanding. Also - have you foreseen what you do when an EF measures multiple properties?
In the EF Model, the ObservingCapabilities FT was created to provide measurement metadata describing HOW (procedure) was WHAT (observedProperty) measured WHERE (featureOfInterest); these three associations mirror the associations of the same name defined for the O&M Observation. While unfortunately not formalized as a constraint, there is a clear statement in the DataSpec that "Consistency has to be assured between links from class ObservingCapability and observations." The result is that you have a description of a facility where you know the location and media monitored (in the example "water"), but not what is being measured. Where this is really an issue is example 1, which provides a value with UoM, but no information on what was actually measured.