Meeting on OGC Sensor Observation Service (SOS) for INSPIRE

1. Meeting on OGC Sensor Observation Service (SOS) for INSPIRE Sylvain Grellet – BRGM (French Geological Survey) s.grellet@brgm.fr

2. Previous SOS experiences • Direct SOS / OM experience • Inspire : • Support drafting EF (co-coordinated) & OM (D2.9), GE • Inspire prototyping : INSPIRE-EMF (2008-2009) • OGC : Hydro DWG (WaterML2.0, GroundWaterML 2.0), GeoSciML, … • “Inspire puzzle” related experience • Implementation of Inspire datamodels and services in European (FP7, reportings drafting) and National Contexts :GCM, HY, EF, GE, MR, AM, NZ, US • EEA Data Specification : UWWTD e-Reporting draft (2012) • Former WISE Technical Group member • BRGM, French Water Information System datamodels and Inspire compliancy

3. Previous SOS experiences • Scope:Providing & consuming observations from French Ground Water / Hydrological Monitoring networks + tests during the OGC Surface Water Interoperability Experiment • Delivered content: Point observations & time series. Thematic domain : ground/surface water quantity/quality • Technologies / software used: 52°North SOS Server, ad hoc Leaflet + Androïd/Iphone clients

4. Existing connections to INSPIRE • Other download services available: WFS, ATOM • Cross-reference of download services: Not linked for the time being but on-going debate between “WFS + reference to SOS GetObservation” VS “GetFeatureOfInterest + GetObservation”

5. Discussion: Why an INSPIRE/SOS? • To give clear guidance to Member States about what encoding / service architecture to use when implementing O&M related Inspire themes (ex : EF)

6. Discussion: Technical issues • SOS version + allowed profiles (ex : hydrology, lightweight ...) + the way profiling is done (Requirements class ? -> WaterML-WQ example) . • Encoding used : how can we document in advance, the encoding used so that the client knows beforehand what he will have to process (ex : “simple O&M” or “WaterML2.0” or specific binary lib ) • Common understanding on the use of the OM_Process : sensor Instance VS sensor Type • Common understanding on where to get the Monitoring Facility information from : WFS GetFeature, SOS GetFeatureInfo

7. Discussion: Technical issues • Common best practice advised • What will be the entry point to the SOS ? Example in the EF case -> the +hasObservation association could point to the GetCapabilities, the GetObservation or even the GetObservationById (as Monitoring Facilities and Observational dataset are not always managed by the same body), -> or should we only document SOS metadata in a catalog and search for the facilities by a GetFeatureOfInterest operation ? • Common vocabulary (or common way to call it) for the observed property/unit of measures • Need to have an “offering” or no

8. Discussion: Download service TG options • Any problems ? • Yes as lack of mature solutions for production environments + support are identified needed for WFS application schema compliant. We can anticipate the same (even more) for SOS • Yes as some will also raise the Table Joining Service option to serve observational data • No, as I hope such a decision will foster evolution both in vendor & opensource solutions

9. Discussion: Wish list • Which features would you like to see in an INSPIRE download service for observation data? • GetFeatureOfInterestand GetObservationById observations (Enhanced Operations Extension in SOS 2) • A way to document beforehand the encoding that will be retrieved from the SOS • A common way to refer to relatedObservations => Update D 2.9 accordingly

10. Additional information • Afraid people will also try to synchronise observational databases (~ dump) via a SOS. We see that with WFS as well • Will we specify asynchronous services at some point (ex : involving a callback service ?, …) ?