Closed KathiSchleidt closed 4 years ago
Accepted in principle. But this would mean a change to the OMSF data model, which is not under the control of INSPIRE.
If the OMSF model is not changed accordingly, we could still propose adding this property for INSPIRE, or we should discuss why this requirement is not fulfilled in the GeoJSON encoding. The latter would mean, however, that the EFS encoding for observations can only ever be an additional, not an alternative encoding.
@ilkkarinne what do you say?
The OMSF does contain the following properties more or less related to the "origin" or "source" of the Observation:
The O&M "parameter" property is not included, as it is basically just a mechanism to include non-standard name-value pairs of non-standard properties. A property with a name-value pair is also not easy to describe in a single, non-structural property.
However, as any additional properties can always be added to a GeoJSON Feature under "properties" property, adding a new property for this is in the INSPIRE context is trivial, and does not require changing the OMSF model.
When considering the name for this property, I would start from the semantic meaning of the relation "a link to the EF at which they were made", as @KathiSchleidt phrased it. If the link is to a single facility, I guess the semantics is something like "the facility where the result of the Observation was was made and/or the result of it was captured". If the link would to the entire Network, I'm not sure it's exactly the same, maybe it would then mean "the network for which the Observation was made, or which provides observing context for it".
Adding this to the properties would make sense, you'd just need to define the attributes used, similar to what we've done for STA
@ilkkarinne this answers my question from #88. samplingFeature
is in the model right now.
@KathiSchleidt Do I understand the requirement right that I add two properties:
...
parameter_name: "relatedMonitoringFeature",
parameter_value: "EnvironmentalMonitoringFacility_1"
...
Alternatively, we could a dd a single key relatedMonitoringFeature
, with a value of EnvironmentalMonitoringFacility_1
.
@KathiSchleidt Is there any feedback you could give me on this please? I am wrapping up the work currently.
@thorsten-reitz Good question, think I'd go for your alternative option, provision as relatedMonitoringFeature. Reasoning: the OM_Observation parameter you've derived the parameter_name¶meter_value attributes from has cardinality *. Within INSPIRE EF we utilize the parameter to provide various types of additional information (See the process parameters in D2.9); since reuse of attributes is not possible in JSON, no further concepts could be provided if you go this way.
Hiya, Stefania requested me to do a simple set of XML encoded EF data, partially triggered by the missing bits in this exercise. Probably too late for this work, but it's now available at: https://github.com/DataCoveEU/INSPIRE_EF Currently there's one example for Air Quality, 1 station, 2 sampling points, processes, data HTH!
In D2.9, there is a requirement for Observations to provide a link to the EF at which they were made. /req/inspire-om-core/relatedMonitoringFeature-parameter To make a reference to an Environmental Monitoring Facility or an Environmental Monitoring Network from an OM_Observation, a ‘parameter’ attribute SHALL be provided, whose ‘name’ attribute is 'relatedMonitoringFeature' and whose ‘value’ attribute is the external object identifier of the referenced spatial object. This is missing in Example 2