ObservingCapability encoding when there are no input data
Hi all,
We are working with INSPIRE EF UML including O&M feature types. In the scope of the present data transformation we are involved in, FoI is mandatory. This implies that also both procedure and observedProperty are required. In other words, both properties are not nillable, so procedure and observedProperty must have values too. However, there are no input data for certain elements. How could a valid GML be obtained if there is no information? How can this be encoded in the GML?
For the moment, “No information” value is assigned but maybe those more deeply into O&M could provide a smarter solution.
<ef:observingCapability>
<ef:ObservingCapability gml:id="OC_4">
<ef:observingTime nilReason="http://inspire.ec.europa.eu/codelist/VoidReasonValue/Unpopulated"xsi:nil="true"></ef:observingTime>
<ef:processType nilReason="http://inspire.ec.europa.eu/codelist/VoidReasonValue/Unpopulated"xsi:nil="true"></ef:processType>
<ef:resultNature nilReason="http://inspire.ec.europa.eu/codelist/VoidReasonValue/Unpopulated"xsi:nil="true"></ef:resultNature>
<ef:procedure xlink:title="No information"></ef:procedure>
<ef:featureOfInterest xlink:href="http://dd.eionet.europa.eu/vocabulary/wise/WaterBody/eionetGroundWaterBodyCode.DE001"></ef:featureOfInterest>
<ef:observedProperty xlink:title="No information"></ef:observedProperty>
</ef:ObservingCapability>
</ef:observingCapability>
Thanks in advance,
Leire Leoz
This discussion is closed and is not accepting new comments.
Hi Leire,
Counterquestion: why are you trying to fill out the ObservingCapabilities if there is (almost) no information available? In your example the only value of the ObsCaps you provide is the FoI refering to a ground water body. I'm assuming this is for your work on WISE where the stations must be reported and associated with the water body their measuring, but no further information on what is measured, or the actual values measured, are provided.
At first glance i see two options:
Does this help?
:) from Malpensa
Kathi
Hi,
We are still looking for the options how to fulfil all the requirements: from the thematic point of view, we would like to keep the connection to the feature of interest (this is done fine), but the spatial data set doesn't include any data that would fulfil the requirement to provide observed property (observedProperty) and the process (process). All three, featureOfInterest, observedProperty and process, are defined by the O&M data model and not by the INSPIRE Environmental Monitoring Facilities.
The question is if the observedProperty and process should be voidable (as featureOfInterest)? This would allow to include those associations when the data actually exist.
Any views or experiences from the practical implementation?
Kind regards,
Darja
Hi Leire, Darja
I don't knwow whether both your requests are coming from the same project but I'm aligned with what Kathi wrote above.
People deciding to monitor a groundwaterbody usually do that with a purpose in mind thus have a ´monitoring strategy ´ around what property to monitor, how ...
So
- unless you are in a reporting schema situation (in some cases, you don't indeed provide the what/how), you may be able to retrieve that information from the one(s) who decided to deploy that monitoring facility you are trying to expose.
- and if you are in reporting schema situation I'll go with picking of the solutions advised by Kathi
Best
Sylvain
Dear Kathi and Sylvain,
Thank you for the replies and proposals. I apologize, we haven't mentioned the full case. You are both right, it is the case of the reporting obligation related to the WFD. Indeed, the required need is to establish a connection between the monitoring site (monitoring station) and the water body (defined under the WFD). We are looking to follow the INSPIRE EF (monitoring site - station) and the connection to O&M feature of interest (water body). In this case, according to the XSD schema, we need to provide also the attributes observedPropery and procedure (both are mandatory and not voidable). However, this data is not required in the WFD reporting.
If we follow the suggestion to provide the high level entries for observedProperty and procedure, those properties will be "sort of a placeholder for something that is not required by the WFD reporting and that doesn't exist (or we don't know if it exists)". This concept can be used until something more precise is developed, or another approach is used to establish that relationship. Is this idea of a placeholder still correct?
Best regards,
Darja
Hi Darja,
yes, placeholder concept (so providing high level "dummy" values for observedProperty and procedure based on the WFD requirements) is still correct.
For future extension (so if and when the day comes when WFD reporting includes explicit information on observedProperty and procedure), I'd advise using a similar pattern to what we've done in AQD e-Reporting by deriving both AQD_Station as well as AQD_SamplingPoint from the INSPIRE EnvironmentalMonitoringFacility Feature Type:
Thus, you have a stable solution for today, that is open for future development/extension
:)
Kathi