European Commission logo
INSPIRE Community Forum

Inspire D2.9 (O&M & SWE guidelines) update: Request for feedback on implementation experience

Dear all,

During the maintenance process of D2.9 and of the technical guidance for implementing download services using OGC SOS, we try to get a clearer vision of the data dissemination patterns some of you used (dissemination in the meaning of data provision).

You'll find below a initial list of questions.
Thank you in advance for your contribution (even if not complete, any community feedback is much appreciated)

The questions : 
- What theme do you use to point to O&M ?
- if thats EF, to what your 'hasObservation' association points at ? A URI redirecting to : a  SOS GetObservationByID, a SOS GetObservation on a specific Offering, a GetDataAvailability (non SOS 2.0 but best practice in the OGC SOS hydro profile)


- what featureOfInterest do you use : domain VS monitoring feature ? 
To what your fOI points at  ? ex : A URI redirecting to a WFS GetFeature (using GetFeatureById)

- do you implement specialised observations as defined in Inspire D2.9 (http://inspire.ec.europa.eu/schemas/omso/3.0/SpecialisedObservations.xsd) ?
If yes, which one ?

- do you implement community specific result encoding ?

- to what procedure to you point to ?
A controlled vocab, a 'Process' as defined in D2.9 (http://inspire.ec.europa.eu/schemas/ompr/3.0/Processes.xsd), or a SensorML description

- what offering strategy do you have (if any) ? : ex one offering per sensor ?

- how do you implement the ObservingCapability ?

- could you provide us with endpoints (WFS/SOS) ?

Due to our internal deadlines, feedback before January 2016 26th would be great

Best regards
Sylvain Grellet

  • Sylvain GRELLET

    By Sylvain GRELLET

    To launch the discussion, what I can put for one of our Use Cases at BRGM : GroundWaterLevel 

    # What theme do you use to point to O&M ? EnvironmentalMonitoringFacilities

    # If that's EF, to what your 'hasObservation' association points at ? A URI redirecting to : a  SOS GetObservationByID, a SOS   GetObservation on a specific Offering, a GetDataAvailability (non SOS 2.0 but best practice in the OGC SOS hydro profile)
    - a URI redirecting to a SOS GetObservation filtered on a dedicated offering

    # What fOI do you use : domain VS monitoring feature ? 
    2 options anticipated : 
    - lightweight one : an aquifer described using Inspire GE - hydrogeology
    - and a 'bit' more heavy from a conceptual point of view (to allow the use of PointTimeSeriesObservation): a SF_SamplingPoint (dumping the location of the sensor monitoring the aquifer). The +sampledFeature role of that SF_SamplingPoint pointing then to the aquifer.
    The later has our preference

    # To what your fOI points at ? in both options above a URI redirecting to a WFS GetFeature query(ById)

    # do  you implement specialised observations as defined in Inspire D2.9 ? Yes in that UseCase a PointTimeSeriesObservation

    # do you implement community specific results encoding ? in that UseCase : WaterML2.0 MeasurementTimeseries

    # to what procedure to you point to ? 'Process' as defined in D2.9

    # What offering strategy do you have (if any) ?
    One offering per coherent GroundWater level time serie at the monitoring facility level (which can last for decades).
    If for some reason we consider we start a new time serie at the same monitoring facility, then we have another offering

    # How do you implement the ObservingCapability ?
    Right now in the EnvironmentalMonitoringFacilitiy WFS flow but we think about an enhanced GetDataAvailability operation (SOS hydrology profile) (adding the Offering parameter and the resultType to the response) to provide the ObservingCapability content.

    # Could you provide us with endpoints (WFS/SOS) ?
    EF - WFS (/!\ test server - not 100% uptime guaranteed) : https://wfspoc.brgm-rec.fr/geoserver/www/testing_links.html
    GroudWaterLevel - SOS : coming soon

    now your turn :)

    Sylvain

  • Paolo TAGLIOLATO

    By Paolo TAGLIOLATO

    Dear Sylvain, here are some notes related to the RITMARE use case.

    I added one more question (and our answer) to your list.

    Sorry for being on the deadline... and thanks for proposing the discussion.

    -----------------------------

    # What theme do you use to point to O&M ?
    -> None at the moment (currently the SOS version we are using doesn't support inspire)

    # If that's EF, to what your 'hasObservation' association points at ? A URI redirecting to : a  SOS GetObservationByID, a SOS   GetObservation on a specific Offering, a GetDataAvailability (non SOS 2.0 but best practice in the OGC SOS hydro profile)
    -> Unapplicable

    # What fOI do you use : domain VS monitoring feature ?
    # To what your fOI points at ? in both options above a URI redirecting to a WFS GetFeature query(ById)

    -> We suggest our partner the use of the spatial sampling schema and our ingestion client implementation is able to compose:
    a sampling point (couple of coordinates) and a sampled feature pointing to the URI/URL of a WFS GetFeature by ID (the WFS being hosted by the same server hosting the SOS of the partner).

    # do  you implement specialised observations as defined in Inspire D2.9 ?
    -> No, at the moment

    # do you implement community specific results encoding ?
    -> No

    # to what procedure to you point to ?
    -> A SensorML document describing a sensor INSTANCE. To ease the management of sensors (and the complex creation of related SensorML) our SensorML authoring tool is able to provide a new instance based on a SensorML "blueprint" modeling a specific sensor model. This blueprints'catalogue is developed and maintained centrally and it comprises the main sensors used by the community.
    The use of SensorML for specific instances of sensors allows to log each "history" event (notably calibration events) that, in our opinion, are key aspects for the re-usability of sensor data in the future.

    # What offering strategy do you have (if any) ?
    -> One offering per sensor, but this strategy is driven by our SOS implementation (52North) and we wish to be able to introduce new offerings for the same sensor when the need should arise.

    # How do you implement the ObservingCapability ?
    -> We don't implement it, but, as said earlier, we explicitly provide full SensorML documents.
    Swe (SOS and SensorML) provides some answer to those "Where", "What", "How" questions about the "measurement regime" (D2.9 v2.0 rc 3, par 6.8.1), questions that  partly motivate the need of the ObservingCapabilities Class:
    Result Location (Where): in sos:capabilities/sos:contents/sos:Contents/swes:offering/sos:observedArea
    ObservedProperty (What): in sos:capabilities/sos:contents/sos:Contents/swes:offering/swes:observedProperty
    Method (How): described in the SensorML document (in SensorML v.2 it could also represent a non-physical process)


    # Could you provide us with endpoints (WFS/SOS) ?
    -> See RITMARE use-case documentation


    [Now, coming to the question I would like to add:]

    ## Do you use any codeList, vocabulary, thesaurus, ontology for the definition of a) observedProperties b) featureOfInterest?
    -> our answer: a) for ObservedProperties we make use of vocabularies hosted by NERC Vocabulary Server (namely P01 and P02);
    b) not at the moment, but we considered using references to instances of Geonames Ontology (i.e. geographical features encoded as semantic resources by means of the geonames ontology) as URI of sampled features.

     

    I hope this will be useful.

    Cheers,

    Paolo

Environmental Monitoring & Observations

Environmental Monitoring & Observations

Environmental Monitoring Facilities, Observations and Measurements