Serving society Stimulating innovation Supporting legislation Meeting on OGC Sensor Observation Service (SOS) for INSPIRE Sylvain Grellet – BRGM (French Geological Survey)

Previous SOS experiences Direct SOS / OM experience  Inspire : –Support drafting EF (co-coordinated) & OM (D2.9), GE –Inspire prototyping : INSPIRE-EMF ( )  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

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

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”

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)

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

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

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

Discussion: Wish list Which features would you like to see in an INSPIRE download service for observation data?  GetFeatureOfInterest and 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

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 ?, …) ?