European Commission logo
INSPIRE Community Forum

SOS V2.0 Offerings

Dear All,


we're currently struggling with the concept of SOS V2.0 Offerings, trying to align this with our existing experiences using SOS V1.0.


Under SOS1, it was possible to provide aggregated offerings, as required for further reuse. Thus, it was possible to provide an Offering for each Station (covering all pollutants measured at the Station), or an Offering for each pollutant (covering all Stations measuring this pollutant), or even a mega-Offering covering all stations and pollutants (even those measured with multiple methods at one Station).

Pros: as one needs to specify the Offering in the subsequent requests, one could access an Offering covering all the required data, and request it within one request

Cons: as especially the mega-offering (all pollutants for all stations) left much "empty space" within the offerings, it was not possible to explicitly see from the offerings if a specific Station could provide data for a specific pollutant for a specific time period


Under SOS2 this is very different!

While it is possible to provide multiple pollutants under the observableProperty, only one Process can be specified for all (procedure has cardinality 1 in AbstractOffering). To my current understanding, this would entail a specific Offering per FoI/Pollutant/Process triple (so for each ObservingCapabilities instance in the Station metadata)

Pros: it is explicitly clear from the Offering what time series are available

Cons: We need to provide an Offering for each explicit time series (not only is procedure unique, one can also only provide one entry for phenomenonTime. Formally, at least the way we currently understand it, if you're Station is down for an hour, the time series is broken, and you need a new Offering!)

This will make for a huge capabilities Response

Unclear: can one do a GetObservation request without specifying the Offering? If so, the user can mostly ignore the offerings when requesting data and just query for the FoI/Pollutant/Process triple

It's also not clear if the assumed split into explicit continuous time series requires that multiple observations be provided as responses for this case


We're starting to worry that while SOS2 is semantically correct on an academic level, it has shifted away from actual requirements (providing access to O&M data in an SDI Environment)


Any insights?




Kathi & Gerhard

  • Sylvain GRELLET

    By Sylvain GRELLET

    Hi Kathi, Gerhard

    In SOS 2.0, the Offering is optional for a GetObservation (see SOS 2.0 spec "Figure 9: Data types of GetObservation operation").

    Why  bothering with Offerings ? Good question I have not completely solved from my side yet.
    The offering mimics the role of the FeatureTypeList you have in a WFS : assuming you discover your service only via the GetCapabilities. 
    But at national level the GetCapabilities explodes if you provide one offering per Monitoring Facility. This issue was already heavily discussed during OGC SurfaceWaterIE back in 2010 and led to Change Request on SOS 1.0.

    There are various solutions (some can be combined):
    # Ignore offering and assume you will access your Observations from a WFS (pointing at some SOS Operation like GetObservationById). See my other thread reply : there is no Observation theme in Inspire so we always seem to access Observations from a Feature entry point

    # Provide your offerings on a per Monitoring Network basis. Depending on the level of details you provide for procedure, this might work
    # Discover available information using a combination of GetFeatureOfInterest and GetDataAvailability as presented in the OGC Sensor Observation Service 2.0 Hydrology Profile ( Read chapters : 
    - 4.2  Discovery functions and filtering
    - 7.1.1  Avoiding falsely indicated homogeneous distribution of time series in a SOS server instance
    - 7.4  GetDataAvailability



  • Katharina SCHLEIDT

    By Katharina SCHLEIDT

    Well, we can work around it, but it kinda counteracts the sense of using an SOS. To my view to date the 2 reasons for SOS are:

    • Capabilities that Show what measurements are available (if we use a WFS, we only see featureType OM_Observation, but not on what)
    • Sensible Access to time series (with WFS, i'd have to provide blocks for a predefined time interval)

    I also worry about your Suggestion of just doing offerings on the Network Level as you suggested. If we do, we have to remove all relevant Process Information, as we'd have to provide one Process for the entire network

    While i understand that at the Moment we have no Options but Workarounds, i'd be happier if we were also working towards making SOS usable again!



  • Sylvain GRELLET

    By Sylvain GRELLET

    Kathi I think, there is a slight misunderstanding.
    When I wrote "assume you will access your Observations from a WFS" I meant that an Observation discovery strategy could be : 

    1°/ where do I monitor something (with filtering available) ? -> GetFeatureOfInterest -> WFS on the monitoring facility / network

    2°/ at a given facility ask whether some data is available (also with filtering available) -> GetDataAvailability (a SOS operation). Excerpt from SOS hydro profile which defines the GetDataAvailability 'The request enables clients to filter for existing time series by their identifying metadata fields and the offering they may belong to. The resulting time series list contains all time series matching the filter criteria with their identifying metadata fields and their data coverage in form of a phenomenon time element.'

    There are implementations already available.

    3°/ access to observation -> GetObservation

    Taking a look at the hydro profile (chapters I referred to above + 7.2  GetFeatureOfInterest) might provide you with a better vision


Environmental Monitoring & Observations

Environmental Monitoring & Observations

Environmental Monitoring Facilities, Observations and Measurements