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:

• Just don't provide the ObsCaps (if you really have to provide a relation to the ground water body being monitored extend the EnvironmentalMonitoringFacility with such an association. Logic here is that when you really do provide detailed information on the measurement configuration or values you'll need a more focused FoI anyway (one ground water body may be sampled at various locations - these should then be the FoI, the ground water body would then be the sampledFeature of the samplingFeature being used as the FoI)
• Define high level entries for observedProperty and procedure, i.e. WiseProperties, WiseProcess. The observedProperty can be provided as a codelist entry (what we're doing with the actual observedProperties falling under AQD), for the procedure the EEA could expose a single INSPIRE Process feature with basic information on WISE measurement stuff

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:

• The Station Feature remains the one you've currently defined
• The SamplingPoint Feature can then provide more explicit information on the observedProperty and procedure being used, together with the exact sampling location for this SamplingPoint

Thus, you have a stable solution for today, that is open for future development/extension

:)

Kathi