European Commission logo
INSPIRE Community Forum

ObservingCapability encoding when there are no input data

  • General

    The INSPIRE Community Forum is now part of the INSPIRE helpdesk system, based on GitHub (, so please start there any new discussions.

    The current platform will remain available in read only mode in its current form and URL address until 31/01/2021, then its content will be archived and then published in a different URL which will be announced when it becomes available.

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 gml:id="OC_4">

          <ef:observingTime nilReason=""xsi:nil="true"></ef:observingTime>

          <ef:processType nilReason=""xsi:nil="true"></ef:processType>

          <ef:resultNature nilReason=""xsi:nil="true"></ef:resultNature>

          <ef:procedure xlink:title="No information"></ef:procedure>

          <ef:featureOfInterest xlink:href=""></ef:featureOfInterest>

          <ef:observedProperty xlink:title="No information"></ef:observedProperty>





Thanks in advance,

Leire Leoz

  • Katharina SCHLEIDT

    By Katharina SCHLEIDT

    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





    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,





  • Sylvain GRELLET

    By Sylvain GRELLET

    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 ...

    - 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





    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,




  • Katharina SCHLEIDT

    By Katharina SCHLEIDT

    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




This discussion is closed.

This discussion is closed and is not accepting new comments.

Environmental Monitoring & Observations

Environmental Monitoring & Observations

Environmental Monitoring Facilities, Observations and Measurements