ࡱ > %
"e bjbj %3 [ m :x :x , , , 4 ` ` ` h Ȇ ,
` { 0 F v #
$ 9 , - 5 D D D
R , l j D D D L
" n ãO v X K 0 { n ) n h B , @/ D SA R { :x $ ^ :
INSPIREInfrastructure for Spatial Information in Europe
D2.9 Guidelines for the use of Observations & Measurements and Sensor Web Enablement-related standards in INSPIRE
TitleD2.9 Guidelines for the use of Observations & Measurements and Sensor Web Enablement-related standards in INSPIRECreatorMIG sub-group MIWP-7aDate2016-06-09SubjectUse of Observations & Measurements and Sensor Web Enablement-related standards in INSPIREPublisherJoint Research CentreTypeTextDescriptionThis document describes the use of Observations & Measurements and Sensor Web Enablement-related standards in INSPIRE ContributorMembers of the temporary sub-group MIWP-7aFormatPDFSourceMIG sub-group MIWP-7aRightsPublicIdentifierD2.9_O&M_and_SWE_Guidelines_v3.0_draft4LanguageEnRelationDirective 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE)CoverageProject duration
O&M & SWE Guidelines Executive Summary
While INSPIRE is foremost a Spatial Data Infrastructure, several of the Annex Themes have been specified so that their scope, in addition to the basic spatial information, includes measured, modelled or simulated data. The ISO 19156:2011 standard on Observations and Measurements (O&M) was designed for this explicit purpose, and thus shall be used in INSPIRE to cover these requirements.
The following INSPIRE themes have identified O&M as integrally relevant to their thematic domain and are including elements of O&M into their data specifications:
Geology
Atmospheric conditions and Meteorological geographical features
Environmental monitoring facilities
Oceanographic geographical features
SeaRegions
Soil
Species distribution
In addition to these themes, several further INSPIRE themes have been identified to which observational information, while not at the core of the data specification, is relevant. These themes are:
Area management/restriction/regulation zones and reporting units: Not mentioned but relevant for reporting on aggregated levels
Human Health and Safety: For provision of health determinants
Land cover: Observations form the basis for land cover information
Natural risk zones: Not in the datamodel, but use case B.5.1 Landslide hazard mapping states: "Monitoring data: Type of monitoring instrumentation, location of sampling measurements, type and record of measurements"
Production and industrial facilities: Relevant for provision of emissions data for E-PRTR
Population distribution - Demography: StatisticalDistribution, StatisticalValue could easily be mapped to OM_Observation
Utility and governmental services: Highly relevant from a domain perspective. It is currently stated that "Not all the application-specific spatial objects (e.g. flow measurement sensors) are incorporated. Non-geographic data (e.g. information on flow in m/s) is also out of scope of this specification"
While the O&M standard provides a generic framework for the provision of measurement data, there are many ways of utilizing the core structures.
In order to assure compatibility across thematic tailoring versions of the O&M standards, the cross-Thematic Working Group on Observations and Measurements (X-TWG-OM) has provided initial guidelines as to how this standard is to be used within INSPIRE. These guidelines have been be taken into account in the implementation of all INSPIRE themes integrating or referencing to the O&M standard.
They have been further enhanced by the Maintenance and Implementation Work Programme working group for SOS-based download services (MIWP-7a) based on feedbacks from implementations.
Acknowledgements
Many individuals and organisations have contributed to the development of these Guidelines.
The Maintenance and implementation work programme working group for SOS-based download services (MIWP-7a) responsible for these guidelines included: Sylvain Grellet (coordinator), Gerhard Dnnebeil, Anders Foureaux, Carsten Hollmann, Frdric Houb i e , D i o m e d e I l l u z z i , S i m o n J i r k a , B a r b a r a M a g a g n a , M a t t h e s R i e k e , A l e s s a n d r o S a r r e t t a , K a t h a r i n a S c h l e i d t , P a w e B S o c z e w s k i , P a o l o T a g l i o l a t o , M i c k a e l T r e g u e r a n d A l e x a n d e r K o t s e v , M i c h a e l L u t z ( E u r o p e a n C o m m i s s i o n c o n t a c t p o i n t s ) .
T h e i n i t i a l c r o s s - T h e m a tic Working Group on Observations and Measurements (X-TWG-OM) set up during annexes II & III data specification process included: Katharina Schleidt (Coordinator), Jandirk Bulens, Simon Cox, Sylvain Grellet, Huibert-Jan Lekkerkerk, Dominic Lowe, Michael Lutz, Clemens Portele, Ilkka Rinne, Heino Rudolf, Laszlo Sores, Jeremy Tandy, Spiros Ventouras, Gavin Walker, Bruce Wright, Alessandro Sarretta (European Commission contact point till May 2012), Tom Reznk (European Commission contact point from May till August 2012), Vlado Cetl (European Commission contact point from August 2012)
Contact information
Michael Lutz
European Commission Joint Research Centre
Institute for Environment and Sustainability
Spatial Data Infrastructures Unit
TP262, Via Fermi 2749
I-21027 Ispra (VA)
ITALY
E-mail: michael.lutz@jrc.ec.europa.eu
Tel.: +39-0332-7866759
Fax: +39-0332-7866325
HYPERLINK "https://ec.europa.eu/jrc/" https://ec.europa.eu/jrc/
http://inspire.ec.europa.eu/
Table of contents
TOC \o "1-3" \h \z HYPERLINK \l "_Toc455501067" 1 Scope PAGEREF _Toc455501067 \h 1
HYPERLINK \l "_Toc455501068" 2 Conformance PAGEREF _Toc455501068 \h 1
HYPERLINK \l "_Toc455501069" 3 References PAGEREF _Toc455501069 \h 1
HYPERLINK \l "_Toc455501070" 4 Terms and Definitions PAGEREF _Toc455501070 \h 2
HYPERLINK \l "_Toc455501071" 4.1 PAGEREF _Toc455501071 \h 2
HYPERLINK \l "_Toc455501072" 4.2 PAGEREF _Toc455501072 \h 2
HYPERLINK \l "_Toc455501073" 4.3 PAGEREF _Toc455501073 \h 3
HYPERLINK \l "_Toc455501074" 4.4 PAGEREF _Toc455501074 \h 3
HYPERLINK \l "_Toc455501075" 4.5 PAGEREF _Toc455501075 \h 3
HYPERLINK \l "_Toc455501076" 4.6 PAGEREF _Toc455501076 \h 3
HYPERLINK \l "_Toc455501077" 4.7 PAGEREF _Toc455501077 \h 3
HYPERLINK \l "_Toc455501078" 4.8 PAGEREF _Toc455501078 \h 3
HYPERLINK \l "_Toc455501079" 4.9 PAGEREF _Toc455501079 \h 4
HYPERLINK \l "_Toc455501080" 4.10 PAGEREF _Toc455501080 \h 4
HYPERLINK \l "_Toc455501081" 4.11 PAGEREF _Toc455501081 \h 4
HYPERLINK \l "_Toc455501082" 4.12 PAGEREF _Toc455501082 \h 4
HYPERLINK \l "_Toc455501083" 4.13 PAGEREF _Toc455501083 \h 4
HYPERLINK \l "_Toc455501084" 4.14 PAGEREF _Toc455501084 \h 4
HYPERLINK \l "_Toc455501085" 4.15 PAGEREF _Toc455501085 \h 5
HYPERLINK \l "_Toc455501086" 4.16 PAGEREF _Toc455501086 \h 5
HYPERLINK \l "_Toc455501087" 4.17 PAGEREF _Toc455501087 \h 5
HYPERLINK \l "_Toc455501088" 4.18 PAGEREF _Toc455501088 \h 5
HYPERLINK \l "_Toc455501089" 4.19 PAGEREF _Toc455501089 \h 5
HYPERLINK \l "_Toc455501090" 5 Conventions PAGEREF _Toc455501090 \h 6
HYPERLINK \l "_Toc455501091" 5.1 Conceptual schemas PAGEREF _Toc455501091 \h 6
HYPERLINK \l "_Toc455501092" 5.2 Requirements class PAGEREF _Toc455501092 \h 6
HYPERLINK \l "_Toc455501093" 5.3 Requirement PAGEREF _Toc455501093 \h 6
HYPERLINK \l "_Toc455501094" 5.4 Abbreviations PAGEREF _Toc455501094 \h 7
HYPERLINK \l "_Toc455501095" 6 Observation models in INSPIRE PAGEREF _Toc455501095 \h 8
HYPERLINK \l "_Toc455501096" 6.1.1 Use of O&M vs. Coverage Model PAGEREF _Toc455501096 \h 8
HYPERLINK \l "_Toc455501097" 6.1.2 Result/Coverage-centric view PAGEREF _Toc455501097 \h 8
HYPERLINK \l "_Toc455501098" 6.1.3 Observation-centric view PAGEREF _Toc455501098 \h 8
HYPERLINK \l "_Toc455501099" 6.2 O&M Design Patterns PAGEREF _Toc455501099 \h 9
HYPERLINK \l "_Toc455501100" 6.2.1 Decision Tree PAGEREF _Toc455501100 \h 10
HYPERLINK \l "_Toc455501101" 6.2.2 Point based observation PAGEREF _Toc455501101 \h 11
HYPERLINK \l "_Toc455501102" 6.2.3 Trajectory based Observations PAGEREF _Toc455501102 \h 17
HYPERLINK \l "_Toc455501103" 6.2.4 Grid based Observations PAGEREF _Toc455501103 \h 21
HYPERLINK \l "_Toc455501104" 6.2.5 Specimen based Observations PAGEREF _Toc455501104 \h 25
HYPERLINK \l "_Toc455501105" 7 O&M INSPIRE profile PAGEREF _Toc455501105 \h 29
HYPERLINK \l "_Toc455501106" 7.1 Core Observation profile PAGEREF _Toc455501106 \h 30
HYPERLINK \l "_Toc455501107" 7.1.1 Observation PAGEREF _Toc455501107 \h 30
HYPERLINK \l "_Toc455501108" 7.1.2 Observed property PAGEREF _Toc455501108 \h 30
HYPERLINK \l "_Toc455501109" 7.1.3 FeatureOfInterest PAGEREF _Toc455501109 \h 31
HYPERLINK \l "_Toc455501110" 7.1.4 Procedure PAGEREF _Toc455501110 \h 32
HYPERLINK \l "_Toc455501111" 7.1.5 Online resource PAGEREF _Toc455501111 \h 34
HYPERLINK \l "_Toc455501112" 7.1.6 Linking to monitoring facility / network PAGEREF _Toc455501112 \h 34
HYPERLINK \l "_Toc455501113" 7.2 External reference to an ObservationSet PAGEREF _Toc455501113 \h 35
HYPERLINK \l "_Toc455501114" 8 Web services PAGEREF _Toc455501114 \h 37
HYPERLINK \l "_Toc455501115" 8.1 Provision of O&M encoded data PAGEREF _Toc455501115 \h 38
HYPERLINK \l "_Toc455501116" 8.2 Available observation data discovery PAGEREF _Toc455501116 \h 39
HYPERLINK \l "_Toc455501117" 8.2.1 GetDataAvailability PAGEREF _Toc455501117 \h 39
HYPERLINK \l "_Toc455501118" 8.2.2 Hierarchical Observation Offerings PAGEREF _Toc455501118 \h 39
HYPERLINK \l "_Toc455501119" 8.2.3 External reference to an ObservationSet PAGEREF _Toc455501119 \h 39
HYPERLINK \l "_Toc455501120" 8.2.4 Service layer pattern PAGEREF _Toc455501120 \h 40
HYPERLINK \l "_Toc455501121" 8.3 Result encoding PAGEREF _Toc455501121 \h 40
HYPERLINK \l "_Toc455501122" 9 Expected next steps PAGEREF _Toc455501122 \h 41
HYPERLINK \l "_Toc455501123" 10 Annexes PAGEREF _Toc455501123 \h 42
HYPERLINK \l "_Toc455501124" 10.1 Annex A (normative): INSPIRE specialised observations PAGEREF _Toc455501124 \h 42
HYPERLINK \l "_Toc455501125" 10.1.1 Feature catalogue PAGEREF _Toc455501125 \h 44
HYPERLINK \l "_Toc455501126" 10.1.2 wml2: MeasurementTimeseries implementation PAGEREF _Toc455501126 \h 50
HYPERLINK \l "_Toc455501127" 10.2 Annex B (normative): INSPIRE Process PAGEREF _Toc455501127 \h 51
HYPERLINK \l "_Toc455501128" 10.2.1 Feature Catalogue PAGEREF _Toc455501128 \h 51
HYPERLINK \l "_Toc455501129" 10.2.2 Process Encoding with SensorML 1.0.1 PAGEREF _Toc455501129 \h 54
HYPERLINK \l "_Toc455501130" 10.3 Annex C (normative): ObservationSet Feature catalogue PAGEREF _Toc455501130 \h 57
HYPERLINK \l "_Toc455501131" 10.3.1 Spatial object types PAGEREF _Toc455501131 \h 57
HYPERLINK \l "_Toc455501132" 10.3.2 Imported types (informative) PAGEREF _Toc455501132 \h 57
HYPERLINK \l "_Toc455501133" 10.4 Annex D (normative): GetDataAvailability V2 Operation PAGEREF _Toc455501133 \h 59
HYPERLINK \l "_Toc455501134" 10.4.1 Operation specification PAGEREF _Toc455501134 \h 59
HYPERLINK \l "_Toc455501135" 10.4.2 Mapping with INSPIRE ObservingCapability mapping PAGEREF _Toc455501135 \h 62
HYPERLINK \l "_Toc455501136" 10.5 Annex E (normative): Hierarchical Observation Offerings Specification PAGEREF _Toc455501136 \h 62
HYPERLINK \l "_Toc455501137" 10.6 Annex F (informative): Revision history PAGEREF _Toc455501137 \h 63
HYPERLINK \l "_Toc455501138" 10.7 Annex G (informative): Short introduction to O&M PAGEREF _Toc455501138 \h 64
HYPERLINK \l "_Toc455501139" 10.7.1 Context PAGEREF _Toc455501139 \h 64
HYPERLINK \l "_Toc455501140" 10.7.2 Observations and Measurements PAGEREF _Toc455501140 \h 64
HYPERLINK \l "_Toc455501141" 10.7.3 Observations PAGEREF _Toc455501141 \h 64
HYPERLINK \l "_Toc455501142" 10.7.4 featureOfInterest and Sampling / SampledFeature identification PAGEREF _Toc455501142 \h 69
HYPERLINK \l "_Toc455501143" 10.7.5 Sampling Features in SamplingCoverageObservations PAGEREF _Toc455501143 \h 71
HYPERLINK \l "_Toc455501144" 10.7.6 Process PAGEREF _Toc455501144 \h 71
HYPERLINK \l "_Toc455501145" 10.7.7 Result PAGEREF _Toc455501145 \h 72
HYPERLINK \l "_Toc455501146" 10.8 Facility / Network PAGEREF _Toc455501146 \h 74
HYPERLINK \l "_Toc455501147" 10.9 Annex H (informative): Short introduction to SWE PAGEREF _Toc455501147 \h 74
HYPERLINK \l "_Toc455501148" 10.9.1 Context PAGEREF _Toc455501148 \h 74
HYPERLINK \l "_Toc455501149" 10.9.2 SOS Overview PAGEREF _Toc455501149 \h 74
HYPERLINK \l "_Toc455501150" 10.9.3 SensorML Overview PAGEREF _Toc455501150 \h 75
HYPERLINK \l "_Toc455501151" 10.9.4 SWE Common Result Encoding PAGEREF _Toc455501151 \h 75
HYPERLINK \l "_Toc455501152" 10.10 Annex I (informative): Observable properties model PAGEREF _Toc455501152 \h 76
HYPERLINK \l "_Toc455501153" 10.10.1 AbstractObservableProperty PAGEREF _Toc455501153 \h 76
HYPERLINK \l "_Toc455501154" 10.10.2 ObservableProperty PAGEREF _Toc455501154 \h 77
HYPERLINK \l "_Toc455501155" 10.10.3 Statistical Measures PAGEREF _Toc455501155 \h 77
HYPERLINK \l "_Toc455501156" 10.10.4 Constraints PAGEREF _Toc455501156 \h 77
HYPERLINK \l "_Toc455501157" 10.10.5 CompositeObservableProperty PAGEREF _Toc455501157 \h 77
HYPERLINK \l "_Toc455501158" 10.10.6 Feature catalogue PAGEREF _Toc455501158 \h 77
HYPERLINK \l "_Toc455501159" 10.11 Annex J (informative): Discussion paper on Out-Of-Band Results PAGEREF _Toc455501159 \h 86
HYPERLINK \l "_Toc455501160" 10.11.1 Introduction PAGEREF _Toc455501160 \h 87
HYPERLINK \l "_Toc455501161" 10.11.2 Binding existing grid coverage data sets to OM_Observations PAGEREF _Toc455501161 \h 87
HYPERLINK \l "_Toc455501162" 10.11.3 Returning OM_Observation results in-band or out-of-band PAGEREF _Toc455501162 \h 88
HYPERLINK \l "_Toc455501163" 10.11.4 XML Schema definitions for the proposed out-of-band result types PAGEREF _Toc455501163 \h 97
HYPERLINK \l "_Toc455501164" 10.12 Annex J (informative): Examples PAGEREF _Toc455501164 \h 99
HYPERLINK \l "_Toc455501165" 10.12.1 SWE Common Results PAGEREF _Toc455501165 \h 99
HYPERLINK \l "_Toc455501166" 10.12.2 GML Coverage Results PAGEREF _Toc455501166 \h 103
Figures
TOC \h \z \c "Figure" HYPERLINK \l "_Toc455501167" Figure 1 : Requirement classes dependency diagram PAGEREF _Toc455501167 \h 6
HYPERLINK \l "_Toc455501168" Figure 2 : Observation-centric view decision tree to specialised observation type PAGEREF _Toc455501168 \h 10
HYPERLINK \l "_Toc455501169" Figure 3 : PointObservation PAGEREF _Toc455501169 \h 12
HYPERLINK \l "_Toc455501170" Figure 4 : PointTimeSeriesObservation PAGEREF _Toc455501170 \h 14
HYPERLINK \l "_Toc455501171" Figure 5 : MultiPointObservation PAGEREF _Toc455501171 \h 16
HYPERLINK \l "_Toc455501172" Figure 6 : Profile Observation PAGEREF _Toc455501172 \h 18
HYPERLINK \l "_Toc455501173" Figure 7 : Trajectory Observation PAGEREF _Toc455501173 \h 20
HYPERLINK \l "_Toc455501174" Figure 8 : Grid Observation PAGEREF _Toc455501174 \h 22
HYPERLINK \l "_Toc455501175" Figure 9 : GridSeries Observation PAGEREF _Toc455501175 \h 24
HYPERLINK \l "_Toc455501176" Figure 10: Specimen Observation PAGEREF _Toc455501176 \h 26
HYPERLINK \l "_Toc455501177" Figure 11: Specimen TimeSeries Observation PAGEREF _Toc455501177 \h 28
HYPERLINK \l "_Toc455501178" Figure 12 : Relationship between sampling and domain features [ISO 9156:2011, Figure 10] PAGEREF _Toc455501178 \h 31
HYPERLINK \l "_Toc455501179" Figure 13 : Linking to sampledFeature PAGEREF _Toc455501179 \h 32
HYPERLINK \l "_Toc455501180" Figure 14 : Process Class PAGEREF _Toc455501180 \h 33
HYPERLINK \l "_Toc455501181" Figure 15 : processParameter cross reference example PAGEREF _Toc455501181 \h 34
HYPERLINK \l "_Toc455501182" Figure 16 : Providing the online resource delivering the observation PAGEREF _Toc455501182 \h 34
HYPERLINK \l "_Toc455501183" Figure 17 : Linking to a monitoring Facility / network using om:parameter PAGEREF _Toc455501183 \h 35
HYPERLINK \l "_Toc455501184" Figure 18 : Direct association to observations and observation sets PAGEREF _Toc455501184 \h 35
HYPERLINK \l "_Toc455501185" Figure 19 : PointObservationCollection PAGEREF _Toc455501185 \h 36
HYPERLINK \l "_Toc455501186" Figure 20 : Linking a monitoring facility/network to a SOS endpoint using a URI PAGEREF _Toc455501186 \h 39
HYPERLINK \l "_Toc455501187" Figure 21: Specialised Observation Types PAGEREF _Toc455501187 \h 43
HYPERLINK \l "_Toc455501188" Figure 22 : wml2:MeasurementTimeseries PAGEREF _Toc455501188 \h 51
HYPERLINK \l "_Toc455501189" Figure 23 : INSPIRE Process featureType encoded in SensorML 1.0.1 example PAGEREF _Toc455501189 \h 56
HYPERLINK \l "_Toc455501190" Figure 24 : GetDataAvailability V2 reponse example PAGEREF _Toc455501190 \h 60
HYPERLINK \l "_Toc455501191" Figure 25 : INSPIRE ObservingCapability- GetDataAvailability V2 reponse mapping PAGEREF _Toc455501191 \h 62
HYPERLINK \l "_Toc455501192" Figure 26 : The basic Observation type PAGEREF _Toc455501192 \h 65
HYPERLINK \l "_Toc455501193" Figure 27 : Sampling feature vs. sampled feature [ISO 19156:2011, figure 10] PAGEREF _Toc455501193 \h 69
HYPERLINK \l "_Toc455501194" Figure 28 : SF_Specimen overview PAGEREF _Toc455501194 \h 70
HYPERLINK \l "_Toc455501195" Figure 29 : Examples of coverage results for different sampling regimes [ISO 19156:2011, Table D.1] PAGEREF _Toc455501195 \h 73
HYPERLINK \l "_Toc455501196" Figure 30 : Complex Properties Model PAGEREF _Toc455501196 \h 76
Requirement classes overview
In this document, requirements classes are provided for 3 target types:
Logical model,
Data instance,
Web services.
They are organised as follows
Figure SEQ Figure \* ARABIC 1 : Requirement classes dependency diagramScope
The purpose of this document is to provide guidelines on how Observations & Measurements and the OGC Sensor Web Enablement framework are to be used to deliver observation data in the context of INSPIRE.
It does not aim at specifying domain specific (ex: Inspire theme) issues but focuses on observation data and their delivery.
In order to ease its reading and implementation and maximize its reuse this revised version now follows the OGC modular specification (OGC 08-131r3).
Conformance
This document provides requirements for the use of Observations & Measurements and Sensor Web Enablement-related standards in the environmental media observation context.
Requirements for three standardization target types are considered:
Logical model,
Data instance,
Web services.
Conformance with this standard shall be checked using all the relevant tests specified in INSPIRE Abstract Test Suite.
References
The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.
ISO 19115:2003, Geographic information Metadata
ISO 19115:2003/Cor 1:2006, Geographic information Metadata Corrigendum 1
ISO 19123:2005, Geographic information Schema for coverage geometry and functions
ISO 19136:2007, Geographic information Geography Markup Language v3.2 (OGC Document 07-036)
ISO 19156:2011, Geographic information Observations and measurements OGC Abstract Specification Topic 20. OGC 10-004r3 and ISO 19156:2011.
ISO/IEC 19505-2:2012, Information technology Object Management Group Unified Modeling Language (OMG UML) Part 2: Superstructure
Observations and Measurements - XML Implementation. (OGC 10-025r1). Simon Cox. Wayland, MA, USA, Open Geospatial Consortium Inc.
OGC SWE Common Data Model Encoding Standard (OGC 08-094r1). Alexandre Robin. Wayland, MA, USA, Open Geospatial Consortium Inc.
OGC Implementation Specification: Sensor Model Language (SensorML) SensorML Encoding Standard, version 1.0 Schema - Corrigendum 1. SensorML 1.0.1 (OGC 07-122r2).Mike Botts and Alexandre Robin (2007). Wayland, MA, USA, Open Geospatial Consortium.
OGC Implementation Standard: Sensor Observation Service (SOS) 2.0 (OGC 12-006). Arne Brring, Christoph Stasch and Johannes Echterhoff (2012).Wayland, MA, USA, Open Geospatial Consortium.
OGC Sensor Observation Service 2.0 Hydrology Profile (OGC 14-004r1). Volker Andres, Simon Jirka, Michael Utech (2014). Wayland, MA, USA, Open Geospatial Consortium.
OGC Implementation Standard: WaterML 2.0: Part 1 - Timeseries (OGC 10-126r4). Peter Taylor (2012). Wayland, MA, USA, Open Geospatial Consortium.
OGC SWE Service Model Implementation Standard (OGC 09-001). Johannes Echterhoff (2011). Wayland, MA, USA, Open Geospatial Consortium.
INSPIRE Technical Guidance for implementing download services using the OGC Sensor Observation Service and ISO 19143 Filter Encoding. INS SOS
INSPIRE Technical Guidance for the implementation of INSPIRE Download Services using WCS
INSPIRE D2.8.III.7 INSPIRE Data Specification on Environmental Monitoring Facilities Technical Guidelines
HYPERLINK "https://github.com/EODP-NZ/eodp-dev"New Zealand Environmental Observation Data Profile - Core, V1.0. Alistair Richie, LandCareResearch. Last consulted 09/06/2016.
EU Ambient Air Quality reporting DataModel. HYPERLINK "http://www.eionet.europa.eu/aqportal" http://www.eionet.europa.eu/aqportal
Terms and Definitions
This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r9], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word SHALL (not must) is the verb form used to indicate a requirement to be strictly followed to conform to this standard.
For the purposes of this document, the following terms and definitions apply.
GML application schema
application schema written in XML Schema in accordance with the rules specified in ISO 19136:2007
[ISO 19136:2007]
Coverage
feature that acts as a function to return values from its range for any direct position within its spatial, temporal or spatiotemporal domain
EXAMPLE Examples include a raster image, polygon overlay or digital elevation matrix.
NOTE In other words, a coverage is a feature that has multiple values for each attribute type, where each direct position within the geometric representation of the feature has a single value for each attribute type.
[ISO 19123:2005, definition 4.1.7]
Data type
specification of a value domain with operations allowed on values in this domain
[ISO/TS 19103:2005, definition 4.1.5]
EXAMPLE Integer, Real, Boolean, String, Date (conversion of a date into a series of codes).
NOTE Data types include primitive predefined types and user-definable types. All instances of a data type lack identity.
[ISO 19156:2011]
Domain feature
feature of a type defined within a particular application domain
NOTE This may be contrasted with observations and sampling features, which are features of types defined for cross-domain purposes.
[ISO 19156:2011(E)]
Ex-situ
referring to the study, maintenance or conservation of a specimen or population away from its natural surroundings
NOTE Opposite of in-situ.
[ISO 19156:2011(E)]
Feature
abstraction of real-world phenomena
[ISO 19101:2002, definition 4.11]
NOTE A feature may occur as a type or an instance. In this document, feature instance is meant unless otherwise specified.
[ISO 19156:2011(E)]
Feature type
class of features having common characteristics
[ISO 19156:2011(E)]
Measure
value described using a numeric amount with a scale or using a scalar reference system
[ISO 19136:2007, definition 4.1.41]
Measurement
set of operations having the object of determining the value of a quantity
[ISO/TS 19101-2:2008, definition 4.20]
Observation
act of measuring or otherwise determining the value of a property
[ISO 19156:2011(E)]
Observation procedure
method, algorithm or instrument, or system of these, which may be used in making an observation
[ISO 19156:2011(E)]
Observation protocol
combination of a sampling strategy and an observation procedure used in making an observation
[ISO 19156:2011(E)]
Observation result
estimate of the value of a property determined through a known observation procedure
[ISO 19156:2011(E)]
Property
facet or attribute of an object referenced by a name
[ISO 19143:2010, definition 4.21]
EXAMPLE Abby's car has the colour red, where "colour red" is a property of the car instance
[ISO 19156:2011(E)]
Property type
characteristic of a feature type
EXAMPLE cars (a feature type) all have a characteristic colour, where "colour" is a property type
NOTE 1 The value for an instance of an observable property type can be estimated through an act of observation
NOTE 2 In chemistry-related applications, the term "determinand" or "analyte" is often used.
[ISO 19156:2011(E)]
Sampling feature
feature which is involved in making observations concerning a domain feature, this feature provides the direct context for the specific observation (spatial, specimen)
EXAMPLE station, transect, section or specimen.
NOTE A sampling feature is an artefact of the observational strategy, and has no significance independent of the observational campaign.
[ISO 19156:2011(E)]
Spatial sampling feature
a sampling feature with a spatial coverage. Used for observations where the result varies within the scope of the feature
EXAMPLE ShipsTrack, Profile, Swath.
NOTE A spatial sampling feature is an artefact of the observational strategy, and has no significance independent of the observational campaign.
Specimen
A Specimen is a physical sample, obtained for observation(s) carried out ex situ, sometimes in a laboratory.
[ISO 19156:2011(E)]
Value
element of a type domain
[ISO/IEC 19501:2005]
NOTE 1 A value considers a possible state of an object within a class or type (domain).
NOTE 2 A data value is an instance of a datatype, a value without identity.
NOTE 3 A value can use one of a variety of scales including nominal, ordinal, ratio and interval, spatial and temporal. Primitive datatypes can be combined to form aggregate datatypes with aggregate values, including vectors, tensors and images.
[ISO 19156:2011(E)]
Conventions
Conceptual schemas
Conceptual schemas in the normative part of this Standard are presented in the Unified Modeling Language (UML). UML diagrams are presented in compliance with ISO/IEC 19505-2.
Requirements class
Each normative statement (requirement or recommendation) in this standard is a member of a requirements class. Each requirements class is described in a discrete clause or sub-clause, and summarized using the following template:
Requirements class/req/{classM}Target type[artefact or technology type]NameHuman readable name of the Requirement ClassDependency[identifier for another requirements class]Requirement/req/{classM}/{reqN}Recommendation/rec/{classM}/{recO}Requirement/req/{classM}/{reqP}Requirement /Recommendation[repeat as necessary]
All requirements in a class must be satisfied. Hence, the requirements class is the unit of re-use and dependency, and the value of a Dependency requirement is another requirements class. All requirements in a dependency must also be satisfied by a conforming implementation. A requirements class may consist only of dependencies and introduce no new requirements.
Requirement
All requirements are normative, and each requirement is presented using the following templates.
Either :
/req/[classM]/[reqN][Normative statement]where /req/[classM]/[reqN] identifies the requirement.
or
/rec/[classM]/[recN][Informative statement]where /rec/[classM]/[reqN] identifies the recommendation.
The use of this layout convention allows the normative provisions of this Standard to be easily located by implementers.
Abbreviations
FoIFeature of InterestGFMGeneral Feature ModelGMLGeography Markup LanguageO&MObservations and MeasurementsOGCOpen Geospatial ConsortiumSensorMLSensor Model LanguageSOSSensor Observation ServiceSWESensor Web EnablementUMLUnified Modeling LanguageXMLExtensible Markup Language
Observation models in INSPIRE
Use of O&M vs. Coverage Model
Many types of spatial data can be structured using either O&M or GML coverages. As an initial step one must determine which model to follow for specifying the data models. In certain cases, often pertaining to coverage results, the result is of primary interest while the methodology used in attaining this result is secondary. In other cases, while the result is still of importance, a good understanding of the process that was utilized in generating these results is of utmost importance in proper further utilization of the result data.
Differentiation in a Result/Coverage-centric - vs. an Observation-centric view helps determine if a specific type of data should be encoded via O&M observations or GML coverages.
Requirements class/ HYPERLINK "http://www.opengis.net/spec/waterml/2.0/req/xsd-xml-rules" req/inspire-observation-modelTarget typeLogical modelNameINSPIRE observation model identification Dependencyurn:iso:dis:iso:19156:clause:7.1Dependencyurn:iso:dis:iso:19123:clause:5Recommendation/rec/inspire-observation-model/coverage-centric-viewRecommendation/rec/inspire-observation-model/observation-centric-view
Result/Coverage-centric view
In the Result/Coverage-centric view, the result (generally a coverage in this case) is the primary object of interest while the description of the observation process is just metadata of the result.
In this view:
First class citizens are coverages
Second class citizen, the description of the observation act, can be described as metadata about the coverage.
In this context, it is even possible to envision design patterns that forgo provision of procedural information entirely as this in not of further relevance for the interpretation of the result.
/rec/inspire-observation-model/coverage-centric-viewIf a Result/Coverage-centric view is best suited for exchanging information on a specific domain, then O&M is not relevant for this purpose.
Information exchange implementation SHOULD conform to ISO 19123:2005 Geographic information Schema for coverage geometry and functions.
Note:
In the context of INSPIRE a dedicated Technical Guidance for the implementation of INSPIRE Download Services using WCSprovides additional requirements and recommendations.
Observation-centric view
In the Observation-centric view, full knowledge of the result acquisition process is necessary: the explicit relationships between the result and the feature of interest, sampling feature, procedure etc. This knowledge must be provided to ensure proper (re)use of the result.
In this view:
First class citizens is the description of the observation act. Richness in the properties and description of the observation process is required.
Second class citizen, the result, is associated to the observation.
/rec/inspire-observation-model/observation-centric-viewIf an observation-centric view is best suited for exchanging information on a specific domain, then ISO 19156:2011 International Standard on Observations and Measurements (O&M) and OGC SWE are relevant for this purpose
Information exchange implementation SHOULD conform to O&M, apply OGC SWE, and the recommendations contained in the current document.
Note:
In the context of INSPIRE a dedicated Technical Guidance for implementing download services using the OGC Sensor Observation Service and ISO 19143 Filter Encoding provides additional requirements and recommendations.
O&M Design Patterns
Requirements class/ HYPERLINK "http://www.opengis.net/spec/waterml/2.0/req/xsd-xml-rules" req/inspire-om-design-patternsTarget typeLogical modelNameINSPIRE O&M design patternsDependency/req/inspire-observation-modelDependency/req/inspire-om-coreDependencyurn:iso:dis:iso:19156:clause:7.2.2Dependencyurn:iso:dis:iso:19156:clause:8Dependencyurn:iso:dis:iso:19156:clause:9Dependencyurn:iso:dis:iso:19156:clause:10Dependencyurn:iso:dis:iso:19156:clause:11Dependencyurn:iso:dis:iso:19156:clause:D.3.4Recommendation/rec/inspire-om-design-patterns/mainRecommendation/rec/inspire-om-design-patterns/pointObservationRecommendation/rec/inspire-om-design-patterns/pointTimeSeriesObservationRecommendation/rec/inspire-om-design-patterns/multiPointObservationRecommendation/rec/inspire-om-design-patterns/profileObservationRecommendation/rec/inspire-om-design-patterns/trajectoryObservationRecommendation/rec/inspire-om-design-patterns/gridObservation Recommendation/rec/inspire-om-design-patterns/gridSeriesObservationRecommendation/rec/inspire-om-design-patterns/specimenObservationRecommendation/rec/inspire-om-design-patterns/specimenTimeSeriesObservationIn order to guide the application of O&M, different design patterns fully embracing the richness of the standard have been identified. Each of them is introduced in the following chapter by way of an example and the corresponding specialised observation type to be used.
The detailed specialised observations feature catalogue is available in REF _Ref444272201 \w \h \* MERGEFORMAT 10.1 REF _Ref444272210 \h \* MERGEFORMAT Annex A (normative): INSPIRE specialised observations.
/rec/inspire-om-design-patterns/mainO&M design patterns described in this document SHOULD be applied if an observation-centric view is best suited for exchanging information
However, in case those design patterns cant be applied because of domain specificity, domain specific O&M design patterns and corresponding UML model, encoding, conformance and conformance classes SHOULD be defined.Decision Tree
The following decision tree provides a support in the determination of the correct design pattern to use for a specific use case. Each design pattern leads to a specialised observation.
The final nodes of the decision tree (light green) provide the name/id of the design pattern to refer to within the rest of the document.
Figure SEQ Figure \* ARABIC 2 : Observation-centric view decision tree to specialised observation type
Point based observation
PointObservation
An first example of such case could be the measurement of the height of a given tree, the featureOfInterest being defined as a species occurrence point.
The PointObservation specialised observation provides the necessary artifact to exchange such information.
/rec/inspire-om-design-patterns/pointObservationWhen the Observation represents a measurement of a property at a single point in time and space the specialised observation PointObservation SHOULD be used.
Figure SEQ Figure \* ARABIC 3 : PointObservation
O&M
Attribute/associationExampleprocessUsedProcess instance links to information about the responsible party, documented process etc. See chapter REF _Ref447895394 \r \h \* MERGEFORMAT 7.1.4 REF _Ref447895394 \h \* MERGEFORMAT Procedure.featureOfInterestA SF_SamplingPoint at the geographic location of the measurementphenomenonTimeA time instant e.g. 2012-01-30T10:30:00.00Z (in ISO 8601 including time zone). See chapter REF _Ref451334990 \r \h \* MERGEFORMAT 7.1.1 REF _Ref451334982 \h \* MERGEFORMAT Observation.observedPropertyLink to a vocabulary defining species height. See chapter REF _Ref451335045 \r \h \* MERGEFORMAT 7.1.2 REF _Ref451335052 \h \* MERGEFORMAT Observed property.resultSingle valued coverage recording an estimate of the observed property (e.g. 8.2) and the unit used in the result (e.g. Meter).resultTimeThe time the result was made available (e.g. published). See chapter REF _Ref451334990 \r \h \* MERGEFORMAT 7.1.1 REF _Ref451334982 \h \* MERGEFORMAT Observation.
Point TimeSeries Observation
An example of such case could be an air quality monitoring station providing ozone concentration measurements. The featureOfInterest represents the direct surrounds of the air intake (i.e. the air bubble surrounding the air intake). The location for the measurements is provided through this featureOfInterest.
As this design pattern usually provides a time series (temporal coverage) result, the explicit phenomenonTime and/or resultTime will often be provided together with the result values.
The PointTimeSeriesObservation specialised observation provides the necessary artifact to exchange such information.
Note that such design patterns also apply for repeated manual measurements at a fixed location in space, as well as automated measurements with an irregular measurement interval.
/rec/inspire-om-design-patterns/pointTimeSeriesObservationWhen the Observation represents a time-series of point measurements of a property at a fixed location in space the specialised observation PointTimeSeriesObservation SHOULD be used
Figure SEQ Figure \* ARABIC 4 : PointTimeSeriesObservation
Two types of Timeseries are identified in WaterML2 part I : Measurement Timeseries and Categorical Timeseries. An example of the concrete type wml2:MeasurementTimeseries is provided in chapter REF _Ref455499317 \r \h \* MERGEFORMAT 10.1.2 REF _Ref455499317 \h \* MERGEFORMAT wml2: MeasurementTimeseries implementation of REF _Ref444272183 \h \* MERGEFORMAT Annex A (normative): INSPIRE specialised observations.
O&M
Attribute/associationExampleprocessUsedProcess instance links to information about the responsible party, documented process etc. See chapter REF _Ref447895394 \r \h \* MERGEFORMAT 7.1.4 REF _Ref447895394 \h \* MERGEFORMAT Procedure.featureOfInterestA SF_SamplingPoint at the geographic location of the measurement. It must be the same location for the entire time series.
Note that in the case of fixed monitoring stations further guidance are provided at chapter REF _Ref455500284 \r \h 7.1.6 REF _Ref455500285 \h Linking to monitoring facility / network.phenomenonTimeA time period (in ISO 8601) representing the start and end date/times of the time series. See chapter REF _Ref451334990 \r \h \* MERGEFORMAT 7.1.1 REF _Ref451334982 \h \* MERGEFORMAT Observation.observedPropertyLink to a vocabulary defining ozone hourly mean. See chapter REF _Ref451335045 \r \h \* MERGEFORMAT 7.1.2 REF _Ref451335052 \h \* MERGEFORMAT Observed property.resultThe result should be a set of TimeValuePairs encoded according to REF _Ref444272183 \r \h \* MERGEFORMAT 10.1 REF _Ref444272183 \h \* MERGEFORMAT Annex A (normative): INSPIRE specialised observations. It should also indicate the units used in the result (ex : g/m or ppm).resultTimeThe time the result was made available (e.g. published). See chapter REF _Ref451334990 \r \h \* MERGEFORMAT 7.1.1 REF _Ref451334982 \h \* MERGEFORMAT Observation.
MultiPoint Observation
An example of such case could be a distributed sensor network reporting the temperature at 10am.
The points themselves are not on a grid but may be distributed in any manner for example unevenly spaced around a coastline
The featureOfInterest represents a bounding box or polygon that includes all the measurement locations
The MultiPointObservation specialised observation provides the necessary artifact to exchange such information.
ADD SCHEMA FROM EXAMPLE
/rec/inspire-om-design-patterns/multiPointObservation When the Observation represents a set of measurements on the same observed property all made at exactly the same time but at different locations
the specialised observation MultiPointObservation SHOULD be used
Figure SEQ Figure \* ARABIC 5 : MultiPointObservation
O&M
Attribute/associationExample (update when Example available)processUsedfeatureOfInterestphenomenonTimeobservedPropertyresultresultTime
Trajectory based Observations
Profile Observation
An example of such case could be a ship measuring the salinity at varying depths along a water column, the featureOfInterest being a vertical water column at one given ship location.
The actual locations of individual measurements along the water column are provided with the result. All measurements are located within the water column with either relative position (from start of water column) or absolute position (i.e. coordinates including the depth).
The ProfileObservation specialised observation provides the necessary artifact to exchange such information.
/rec/inspire-om-design-patterns/profileObservationWhen the Observation represents the measurement of a property along a vertical profile in space at a single time instant the specialised observation ProfileObservation SHOULD be used
Figure SEQ Figure \* ARABIC 6 : Profile Observation
O&M
Attribute/associationExample processUsedProcess instance links to information about the responsible party, documented process etc. See chapter REF _Ref447895394 \r \h \* MERGEFORMAT 7.1.4 REF _Ref447895394 \h \* MERGEFORMAT Procedure.featureOfInterestA SF_SamplingCurve with a geometry that defines the geometry of the profile.phenomenonTimeA time instant (in ISO 8601) when the observations were taken. See chapter REF _Ref451334990 \r \h \* MERGEFORMAT 7.1.1 REF _Ref451334982 \h \* MERGEFORMAT Observation.observedPropertyLink to a vocabulary defining salinity. See chapter REF _Ref451335045 \r \h \* MERGEFORMAT 7.1.2 REF _Ref451335052 \h \* MERGEFORMAT Observed property.resultThe result encoded according to REF _Ref444272183 \r \h \* MERGEFORMAT 10.1 REF _Ref444272183 \h \* MERGEFORMAT Annex A (normative): INSPIRE specialised observations. It should also indicate the units used in the result.
For large result sets an out-of-band result (e.g. in binary) may be provided.resultTimeThe time the result was made available (e.g. published). See chapter REF _Ref451334990 \r \h \* MERGEFORMAT 7.1.1 REF _Ref451334982 \h \* MERGEFORMAT Observation.
Trajectory Observation
An example of such case could be a moving ship making sea surface temperature measurements, the featureOfInterest being the trajectory of the ship
The actual locations of individual measurements along the trajectory are provided with the results.
All measurements are located within the trajectory with either relative position (from start of the trajectory) or absolute position (i.e. coordinates).
Each measurement is made at a separate point along the trajectory and at a separate time. The result is therefore a set of time, location, value triples.
The TrajectoryObservation specialised observation provides the necessary artifact to exchange such information.
/rec/inspire-om-design-patterns/trajectoryObservationWhen the Observation represents the measurement of a property along a meandering curve in time and space the specialised observation TrajectoryObservation SHOULD be used
Figure SEQ Figure \* ARABIC 7 : Trajectory Observation
O&M
Attribute/associationExampleprocessUsedProcess instance links to information about the responsible party, documented process etc. See chapter REF _Ref447895394 \r \h \* MERGEFORMAT 7.1.4 REF _Ref447895394 \h \* MERGEFORMAT Procedure.featureOfInterestA SF_SamplingCurve with a geometry that defines the geometry of the trajectory.phenomenonTimeA time period (in ISO 8601) representing the start and end date/times of the trajectory. See chapter REF _Ref451334990 \r \h \* MERGEFORMAT 7.1.1 REF _Ref451334982 \h \* MERGEFORMAT Observation.observedPropertyLink to a vocabulary defining water temperature. See chapter REF _Ref451335045 \r \h \* MERGEFORMAT 7.1.2 REF _Ref451335052 \h \* MERGEFORMAT Observed property.resultThe result (a set of Location, Time, Value triples) encoded according to REF _Ref444272183 \r \h \* MERGEFORMAT 10.1 REF _Ref444272183 \h \* MERGEFORMAT Annex A (normative): INSPIRE specialised observations. It should also indicate the units used in the result.resultTimeThe time the result was made available (e.g. published). See chapter REF _Ref451334990 \r \h \* MERGEFORMAT 7.1.1 REF _Ref451334982 \h \* MERGEFORMAT Observation.
Grid based Observations
Grid Observation
An example of such case could be the determination of the ocean color over a gridded field taken at a single instant in time such as a rectified or georeferenced satellite data.
The featureOfInterest represents the extent of the grid.
The actual locations of individual observations within the grid are provided with the results. All individual measurement locations are located within the grid boundaries. The grid cell being observed is provided in the domain of the coverage result, the color observed is provided within the range of the coverage result
The GridObservation specialised observation provides the necessary artifact to exchange such information.
/rec/inspire-om-design-patterns/gridObservationWhen the Observation represents a gridded field at a single time instant the specialised observation GridObservation SHOULD be used
Figure SEQ Figure \* ARABIC 8 : Grid Observation
O&M
Attribute/associationExampleprocessUsedProcess instance links to information about the responsible party, documented process etc. See chapter REF _Ref447895394 \r \h \* MERGEFORMAT 7.1.4 REF _Ref447895394 \h \* MERGEFORMAT Procedure.featureOfInterestA SF_SamplingSurface that defines the extent of the Grid of data.phenomenonTimeA time instant e.g. 2012-01-30T10:30:00.00Z (in ISO 8601 including time zone) which the Grid represents. See chapter REF _Ref451334990 \r \h \* MERGEFORMAT 7.1.1 REF _Ref451334982 \h \* MERGEFORMAT Observation.observedPropertyLink to a vocabulary defining water color. See chapter REF _Ref451335045 \r \h \* MERGEFORMAT 7.1.2 REF _Ref451335052 \h \* MERGEFORMAT Observed property.resultThe result containing the grid points (as the domain of the coverage) and the observed ocean colour values (as the rangeSet of the coverage encoded according to REF _Ref444272183 \r \h \* MERGEFORMAT 10.1 REF _Ref444272183 \h \* MERGEFORMAT Annex A (normative): INSPIRE specialised observations.
For large grids an out-of-band result (e.g. in binary) may be provided.resultTimeThe time the result was made available (e.g. published). See chapter REF _Ref451334990 \r \h \* MERGEFORMAT 7.1.1 REF _Ref451334982 \h \* MERGEFORMAT Observation.
GridSeries Observation
An example of such case could be the determination of the ocean temperature over a gridded field studied over time such as in a simulation/model run
The featureOfInterest represents the extent of the grid. The ocean temperature is modelled for each grid cell over time.
The actual locations of individual observations within the grid are provided with the results. All measurement locations are located within the grid boundaries.
The GridSeriesObservation specialised observation provides the necessary artifact to exchange such information.
/rec/inspire-om-design-patterns/gridSeriesObservationWhen the Observation represents an evolving gridded field at a succession of time the specialised observation GridSeriesObservation SHOULD be used
Figure SEQ Figure \* ARABIC 9 : GridSeries Observation
O&M
Attribute/associationExampleprocessUsedProcess instance links to information about the responsible party, documented process etc. See chapter REF _Ref447895394 \r \h \* MERGEFORMAT 7.1.4 REF _Ref447895394 \h \* MERGEFORMAT Procedure.featureOfInterestA SF_SamplingSurface that defines the extent of the Grid of data.phenomenonTimeA time period (in ISO 8601) representing the start and end date/times of the model run. See chapter REF _Ref451334990 \r \h \* MERGEFORMAT 7.1.1 REF _Ref451334982 \h \* MERGEFORMAT Observation.observedPropertyLink to a vocabulary defining water temperature. See chapter REF _Ref451335045 \r \h \* MERGEFORMAT 7.1.2 REF _Ref451335052 \h \* MERGEFORMAT Observed property.resultThe result containing the grid points (as the spatio-temporal domain of the coverage with one of the axes being be a temporal axis) and the observed sea surface temperature values (as the rangeSet of the coverage encoded according to REF _Ref444272183 \r \h \* MERGEFORMAT 10.1 REF _Ref444272183 \h \* MERGEFORMAT Annex A (normative): INSPIRE specialised observations. It should also indicate the units used in the result.
For large grids an out-of-band result (e.g. in binary) may be provided.resultTimeThe time the result was made available (e.g. published). See chapter REF _Ref451334990 \r \h \* MERGEFORMAT 7.1.1 REF _Ref451334982 \h \* MERGEFORMAT Observation.
Specimen based Observations
Specimen Observation
An example of such case would be a sample or specimen taken from the sampled feature and analysed once ex situ in an external laboratory.
The SpecimenObservation specialised observation provides the necessary artifact to exchange such information.
/rec/inspire-om-design-patterns/specimenObservationWhen the Observation represents a measurement of a property of a Specimen at a single point in time the specialised observation SpecimenObservation SHOULD be used
Figure SEQ Figure \* ARABIC 10: Specimen Observation
O&M OM_Observation
Attribute/associationExampleprocessUsedProcess instance links to information about the responsible party, documented process etc. See chapter REF _Ref447895394 \r \h \* MERGEFORMAT 7.1.4 REF _Ref447895394 \h \* MERGEFORMAT Procedure.featureOfInterestA SF_Specimen corresponding to the water bottle the concentration is measured from.phenomenonTimeA time instant e.g. 2012-01-30T10:30:00.00Z (in ISO 8601). See chapter REF _Ref451334990 \r \h \* MERGEFORMAT 7.1.1 REF _Ref451334982 \h \* MERGEFORMAT Observation.observedPropertyLink to a vocabulary defining water temperature. See chapter REF _Ref451335045 \r \h \* MERGEFORMAT 7.1.2 REF _Ref451335052 \h \* MERGEFORMAT Observed property.resultSingle valued coverage recording an estimate of the observed property (e.g. 79) and the unit used in the result (e.g ppm).resultTimeThe time the result was made available (e.g. published). See chapter REF _Ref451334990 \r \h \* MERGEFORMAT 7.1.1 REF _Ref451334982 \h \* MERGEFORMAT Observation.
O&M SF_Specimen
Attribute/associationExamplematerialClassBasic classification of the material type of the specimen (here : water)samplingTimeA time instant (in ISO 8601) representing the moment when the specimen was retrieved from the sampled feature.samplingMethodInformation about the sampling context: method used, the responsible party, etcsampledFeatureLink to the domainFeature being sampled (ex : the lake of code xxxx)
Specimen TimeSeries Observation
An example of such case would be a sample or specimen taken from the sampled feature and re-analysed at regular intervals ex situ in an external laboratory. This could apply to the measurement of the biochemical oxygen demand (BOD) in waste water treatment plants; it is measured by taking one sample and studying BOD evolution over time in a laboratory. While the usual result requested is BOD 5 (5 difference of O2 consumption by micro-organisms after 5 days) or BOD 21, in some cases you may require the entire time series.
The SpecimenTimeSeriesObservation specialised observation provides the necessary artifact to exchange such information.
/rec/inspire-om-design-patterns/specimenTimeSeriesObservationWhen the Observation represents a measurement of a property of a Specimen analysed at regular intervals the specialised observation SpecimenTimeSeriesObservation SHOULD be used
Figure SEQ Figure \* ARABIC 11: Specimen TimeSeries Observation
O&M OM_Observation
Attribute/associationExampleprocessUsedProcess instance links to information about the responsible party, documented process etc. See chapter REF _Ref447895394 \r \h \* MERGEFORMAT 7.1.4 REF _Ref447895394 \h \* MERGEFORMAT Procedure.featureOfInterestA SF_Specimen corresponding to the water bottle the reapeated measurement are taken from.phenomenonTimeA time period (in ISO 8601) representing the start and end date/times of the time series. See chapter REF _Ref451334990 \r \h \* MERGEFORMAT 7.1.1 REF _Ref451334982 \h \* MERGEFORMAT Observation.observedPropertyLink to a vocabulary defining biochemical oxygen demand. See chapter REF _Ref451335045 \r \h \* MERGEFORMAT 7.1.2 REF _Ref451335052 \h \* MERGEFORMAT Observed property.resultThe result should be a set of TimeValuePairs encoded according to REF _Ref444272183 \r \h \* MERGEFORMAT 10.1 REF _Ref444272183 \h \* MERGEFORMAT Annex A (normative): INSPIRE specialised observations. It should also indicate the units used in the result.resultTimeThe time the result was made available (e.g. published). See chapter REF _Ref451334990 \r \h \* MERGEFORMAT 7.1.1 REF _Ref451334982 \h \* MERGEFORMAT Observation.
O&M SF_Specimen
Attribute/associationExamplematerialClassBasic classification of the material type of the specimen (here : water)samplingTimeA time instant (in ISO 8601) representing the moment when the specimen was retrieved from the sampled feature.samplingMethodInformation about the sampling context: method used, the responsible party, etcsampledFeatureLink to the domainFeature being sampled (ex : the waste water treatment plant of code xxxx)
O&M INSPIRE profile
Requirements for the structure and content of XML data instances provided by web services or servers.
Requirements class/req/inspire-om-coreTarget typeXML data documentNameINSPIRE profile for the implementation of O&MDependency/req/inspire-observation-modelDependencyhttp://www.opengis.net/spec/OMXML/2.0/req/observationDependencyhttp://www.opengis.net/spec/OMXML/2.0/req/samplingDependencyhttp://www.opengis.net/spec/OMXML/2.0/req/spatialSamplingRecommendation/rec/inspire-om-core/observation-identifierRecommendation/rec/inspire-om-core/observation-timeRecommendation/rec/inspire-om-core/observedProperty-communityVocabularyRecommendation/rec/inspire-om-core/observedProperty-skosRecommendation/rec/inspire-om-core/featureOfInterest-typeRecommendation/rec/inspire-om-core/featureOfInterest-identifierRecommendation/rec/inspire-om-core/featureOfInterest-sampledFeatureRecommendation/rec/inspire-om-core/featureOfInterest-sampledFeatureIdentifierRecommendation/rec/inspire-om-core/featureOfInterest-depth-elevationRecommendation/rec/inspire-om-core/procedure-noSensorInstanceRecommendation/rec/inspire-om-core/procedure-communityVocabularyRecommendation/rec/inspire-om-core/procedure-processRecommendation/rec/inspire-om-core/procedure-identifierRequirement/req/inspire-om-core/procedure-processParameterRecommendation/rec/inspire-om-core/procedure-processParameterSchRecommendation/rec/inspire-om-core/onlineResourceRequirement/req/inspire-om-core/relatedMonitoringFeature-parameterRecommendation/rec/inspire-om-core/relatedMonitoringFeature-URIRecommendation/rec/inspire-om-core/observationSetCore Observation profile
Observation
/rec/inspire-om-core/observation-identifierA om:OM_Observation SHOULD include a gml:identifier element and its value SHOUD be a unique and persistent HTTP URI as specified by the appropriate naming authority.
/rec/inspire-om-core/observation-timeThe values of temporal elements - om:phenomenonTime, om:validTime and om:resultTime - SHOULD be encoded using the ISO8601 extended time format and SHOULD include the time offset from UTC.
Observed property
/rec/inspire-om-core/observedProperty-communityVocabularyThe observedProperty SHOULD be a reference to a community managed vocabulary:
The value of the om:observedProperty/@xlink:href SHOULD be an HTTP URI through which the observedProperty description can be downloaded
The value of the om:observedProperty/@xlink:title attribute SHOULD carry the name of the observed property
/rec/inspire-om-core/observedProperty-skosIn case a RDF/XML description is used:
The value of the om:observedProperty/@xlink:href attribute SHOULD be an HTTP URI that dereferences to a RDF/XML description of the property type that conforms to the community defined skos concepts
The value of the om:observedProperty/@xlink:title attribute SHOULD match the value of the associated skos:Concept/skos:prefLabel.
Note: INSPIRE has developed an ObservableProperty model to provide a framework for extending a pre-defined term in a vocabulary with additional information, such as constraints (e.g. the earlier wavelength example), or statistical measures (e.g. the earlier temperature example).
It is non normative and provided for information in chapter REF _Ref444965943 \r \h \* MERGEFORMAT 10.10 REF _Ref444965943 \h \* MERGEFORMAT Annex I (informative): Observable properties model.
FeatureOfInterest
FeatureOfInterest type
In some cases, the featureOfInterest exists only because an observation exists, i.e. it is only defined in order to perform an observation of the real world; in this case, a specific sampling feature must be defined to serve as featureOfInterest. In other cases, a feature used in other contexts within the domain will also serve as a featureOfInterest for an observation.
This situation is summarized in Figure 10 of ISO 19156:2011.
Figure SEQ Figure \* ARABIC 12 : Relationship between sampling and domain features [ISO 9156:2011, Figure 10]
/rec/inspire-om-core/featureOfInterest-typeUnless otherwise specified in a given observation subtype, the featureOfInterest SHOULD be one of SF_SamplingFeature derived Types.
/rec/inspire-om-core/featureOfInterest-identifierThe featureOfInterest of an om:Observation SHOULD be provided with its gml:identifier.
sampledFeature
In many cases, only a featureOfInterest is provided in the form of a samplingFeature; the description of the associated sampledFeature is often missing. SampledFeature information referring to the media or realm covered is useful for providing a better understanding of the context of the featureOfInterest
/rec/inspire-om-core/featureOfInterest-sampledFeatureWhen using a SF_SamplingFeature as featureOfInterest, at least one domain feature (GFI_Feature) SHOULD be provided as sampledFeature to provide the necessary context. In case such feature is not available, then a URI entry to NASAs SWEET Ontology SHOULD be provided.
The following example points to a URI which, when dereferenced, provides the corresponding sampled domain feature (here an aquifer)
In the same domain context, but without such data content available, one could use:
Figure SEQ Figure \* ARABIC 13 : Linking to sampledFeature
/rec/inspire-om-core/featureOfInterest-sampledFeatureIdentifierWhen a domain feature (GFI_Feature) is provided as sampledFeature its gml:identifier SHOULD be provided
depth/elevation
/rec/inspire-om-core/featureOfInterest-depth-elevationWhen using a SF_SamplingFeature as featureOfInterest, in order to indicate depth or elevation a sf:parameter SHOULD be used. Its name attribute SHOULD be depth or elevation (depending on the context) and value attribute SHOULD be of type gml:MeasureType with indication of the uom.Procedure
Within this profile, the observation procedure (OM_Process) is considered as an algorithm, sensor type, or time series type, but not as an individual, physical device (sensor instance). In INSPIRE context, the theme II.7 Environmental Monitorings Facilities provides the necessary elements to exchange such information.
/rec/inspire-om-core/procedure-noSensorInstanceThe OM_Process SHOULD NOT refer to the description of a sensor instance.
/rec/inspire-om-core/procedure-communityVocabularyThe procedure SHOULD be a reference to a community managed vocabulary exposed according to /rec/inspire-om-core/procedure/process.
The Process class defined within INSPIRE allows for the lightweight provision of procedural information.
The detailed Process feature catalogue is available in chapter REF _Ref445100270 \w \h \* MERGEFORMAT 10.2 REF _Ref451356678 \h \* MERGEFORMAT Annex B (normative): INSPIRE Process along with a standardised mapping to SensorML 1.0.1.
/rec/inspire-om-core/procedure-processWhere the OM_Observation type or any sub-type thereof is used to make data available, either the Process Featuretype or its mapping to SensorML SHOULD be used to describe the procedure used in an OM_Observation
/rec/inspire-om-core/procedure-identifierThe procedure of an om:Observation SHOULD be provided with its gml:identifier
Figure SEQ Figure \* ARABIC 14 : Process Class
/req/inspire-om-core/procedure-processParameterWhere the OM_Observation type or any sub-type thereof is used to make data available and if the processParameter attribute is present in the procedure property of an OM_Observation object, its value (a name) SHALL be included in the parameter attribute of the OM_Observation object.
An example of such cross-reference is the following
Process
identifier: ukmo_global_model
documentation: http://www.metoffice.gov.uk/research/modelling-systems/unified-model/weather-forecasting
processParameter: http://inspire/processParameterValue.html#AnalysisTime
processParameter: http://inspire/processParameterValue.html#AssimilationWindow
OM_Observation
phenomenonTime: 00z 15/05/2011 - 00z 21/05/2011
resultTime: 0420z 15/05/2011
parameter: Name: http://inspire/processParameterValue.html#AnalysisTimeValue: 00z 15/05/2011
parameter: Name: http://inspire/processParameterValue.html#AssimilationWindowValue: 20z 14/05/2011 - 02z 15/05/2011Figure SEQ Figure \* ARABIC 15 : processParameter cross reference example
/rec/inspire-om-core/procedure-processParameterSchWhere the processParameter attribute is used schematron rules SHOULD be provided together with the schema in order to assure that all keys used in the observation parameters are also be listed under the process parameters.
Online resource
/rec/inspire-om-core/onlineResourceWhen providing a direct reference to an observation using resolvable HTTP URI (see /rec/inspire-SOS/ObservationURI), one or more gml:metaDataProperty//gml:GenericMetaData/
gmd:CI_OnlineResource elements identifying services that deliver the actual measurements SHOULD be provided.
http://ressource.brgm-rec.fr/service/sosRawPiezo
OGC:SOS-2.0.0
Figure SEQ Figure \* ARABIC 16 : Providing the online resource delivering the observation
Linking to monitoring facility / network
In some cases, Observations are provided but not directly linked to related Monitoring feature at which they were made. The parameter attribute of the Observation enables to do so.
/req/inspire-om-core/relatedMonitoringFeature-parameterTo make a reference to an Environmental Monitoring Facility or an Environmental Monitoring Network from an OM_Observation, a parameter attribute SHALL be provided, whose name attribute is 'relatedMonitoringFeature' and whose value attribute is the external object identifier of the referenced spatial object.
/rec/inspire-om-core/relatedMonitoringFeature-URIIn case the observation parameter is used, its value attribute SHOULD be a resolvable HTTP URI
The URI when dereferenced should provide the description of the associated Environmental Monitoring Facility
Figure SEQ Figure \* ARABIC 17 : Linking to a monitoring Facility / network using om:parameter
External reference to an ObservationSet
When multiple observations need to be referred to as a set and when no specific offering strategy provides a satisfying approach, a dedicated FeatureType as been defined.
Detailed ObservationSet feature catalogue is available in REF _Ref445107073 \r \h \* MERGEFORMAT 10.3 REF _Ref445107073 \h \* MERGEFORMAT Annex C (normative): ObservationSet Feature catalogue
/rec/inspire-om-core/observationSetThe ObservationSet FeatureType, or a subtype thereof, SHOULD be used to link to a set of Observations in case no offering strategy alternative is identified.
Figure SEQ Figure \* ARABIC 18 : Direct association to observations and observation sets
Its service implementation is provided in /rec/inspire-SOS/ObservationSetImplementation below.
A subtype of the ObservationSet reused in Inspire is the PointObservationCollection .
An example of such case could be the set of individual observations used to determine the distribution of a species.
The grouping may be made on any basis e.g. it may be useful to group together PointObservations made by the same instrument or Environmental Facility, or in a particular measurement campaign.
Detailed PointObservationCollection feature catalogue is available in REF _Ref454546783 \r \h 10.1.1.1.6 REF _Ref454546783 \h \* MERGEFORMAT PointObservationCollection.
Figure SEQ Figure \* ARABIC 19 : PointObservationCollection
Web services
Requirements for the behaviour - supported operations, methods and response encodings - of web services.
Note:
In the context of INSPIRE a dedicated Technical Guidance for implementing download services using the OGC Sensor Observation Service and ISO 19143 Filter Encoding [INS SOS] provides requirements and recommendations.
Requirements / recommendations appearing in the following chapter that refer to one of the above will plainly make the reference with the following pattern: [INS SOS] TG Requirement/Recommendation x.x
Mentioning them here serves two purposes:
providing a clear overview of what these INSPIRE O&M & SWE guidelines entails from an OGC architecture perspective,
while respecting INSPIRE technical guidance documents structure and allowing to map to INSPIRE terminology
Requirements class/req/inspire-SOSTarget typeWeb servicesNameCapabilities of a Sensor Observation Service instance.Dependencyhttp://www.opengis.net/spec/SOS/2.0/req/coreDependencyhttp://www.opengis.net/spec/SOS/2.0/req/foiRetrievalDependency HYPERLINK "http://www.opengis.net/spec/SOS/2.0/req/kvp-core" http://www.opengis.net/spec/SOS/2.0/req/kvp-coreDependencyhttp://www.opengis.net/spec/SOS/2.0/req/kvp-foiRetrievalRecommendation/rec/inspire-SOS/SOSRequirement/req/inspire-SOS/CoreRequirement/req/inspire-SOS/SpatialFilteringProfileRequirement/req/inspire-SOS/XmlKVPRecommendation/rec/inspire-SOS/SOSGuidanceRecommendation/rec/inspire-SOS/GetFoIRecommendation/rec/inspire-SOS/FoIRequirement/req/inspire-SOS/ObservationByIdRecommendation/rec/inspire-SOS/ObservationURIRecommendation/rec/inspire-SOS/GDARecommendation/rec/inspire-SOS/GDAObservingCapabilityRecommendation/rec/inspire-SOS/HierarchicalOfferingRecommendation/rec/inspire-SOS/ObservationSetImplementationRecommendation/rec/inspire-SOS/ServicePatternRequirement/req/inspire-SOS/API
Provision of O&M encoded data
/rec/inspire-SOS/SOSOGC Sensor Observation Service Interface Standard, Version 2.0 (OGC 12-006) SHOULD be used for the provision of O&M encoded data.
/req/inspire-SOS/CoreImplementation of a SOS download service SHALL conform to the Conformance Class SOS Core ([INS SOS] TG Requirement 4.1 & 5.1)
/req/inspire-SOS/SpatialFilteringProfileThe Conformance Class Spatial Filtering Profile as defined by OGC 12-006 SHALL be enabled to ensure that each observation served through the download service provides a sampling geometry. ([INS SOS] TG Requirement 4.2)
/req/inspire-SOS/XmlKVPImplementation of an SOS dataset download service SHALL conform to the OGC 12-006 Conformance Classes Core KVP Binding and XML Encoding. ([INS SOS] TG Requirement 4.3 & 5.1)
/rec/inspire-SOS/SOSGuidanceWhen implementing SOS accompanying Technical Guidance for implementing download services using the OGC Sensor Observation Service and ISO 19143 Filter Encoding SHOULD be followed
/rec/inspire-SOS/GetFoIImplementation of SOS servers to be used as INSPIRE Download Service SHOULD support the GetFeatureOfInterest operation as defined by OGC 12-006 ([INS SOS] TG Recommendation 4.3)
/rec/inspire-SOS/FoIImplementation of SOS servers receiving a GetFeatureOfInterest request specifying the featureOfInterest, SHOULD return the identified feature gml:identifier regardless of it's observational context: domainFeature, SF_SamplingFeature subtypes and a sampledFeature
/req/inspire-SOS/ObservationByIdA Direct Access Download Service SHALL implement the GetObservationByID operation as defined by OGC 12-006 ([INS SOS] TG Requirement 5.2) and use gml:identifier to provide the observation identifier.
/rec/inspire-SOS/ObservationURIWhen providing a direct reference to an observation an HTTP URI through which the observation can be downloaded SHOULD be provided.
For example in INSPIRE, the Environmental Monitoring Facilities theme provides a hasObservation association role from AbstractMonitoringObject to OM_Observation.
It is advised, at the instance level, to have hasObservation contain a reference that, when dereferenced, points to the dedicated offering (via a getObservation).
Figure SEQ Figure \* ARABIC 20 : Linking a monitoring facility/network to a SOS endpoint using a URI
Available observation data discovery
GetDataAvailability
An initial endeavour (OGC Sensor Observation Service 2.0 Hydrology Profile : OGC 14-004r1) defined the GetDatAvailability operation in order to provide standardized means for a client to construct valid parameter constellations (i.e. combinations of the query parameters offering, procedure, feature of interest and observed property) that refer to an existing observation.
The current profile enriched the approach. The detailed GetDataAvailabilityV2 specification is provided in REF _Ref447555986 \h \* MERGEFORMAT Annex D (normative): GetDataAvailability V2 Operation .
/rec/inspire-SOS/GDAImplementation of a SOS download service SHOULD implement the GetDataAvailibilityV2 operation to test for observation availability.
Within INSPIRE, the theme III.7 Environmental Monitoring Facilities defined the concept of ObservingCapability to describe the explicit observation capability(ies) of a monitoring object (basically an observation without result). The mapping provided in REF _Ref455407602 \h \* MERGEFORMAT Annex D (normative): GetDataAvailability V2 Operation - REF _Ref455407616 \h \* MERGEFORMAT Mapping with INSPIRE ObservingCapability mapping enables to use this operation to expose such information.
/rec/inspire-SOS/GDAObservingCapabilityThe GetDataAvailibilityV2 operation SHOULD be used to expose the explicit capability of a Monitoring Object.
Hierarchical Observation Offerings
The use of a hierarchical structure of SOS observation offerings will be of help to reduce the size of the Capabilities document. This way, the GetCapabilities response would contain the more high-level Observation Offerings while the more fine-grained Observation Offerings would be accessible through the GetDataAvailability operation.
Detailed hierarchical observation offering specification is provided in REF _Ref447634983 \h \* MERGEFORMAT Annex E (normative): Hierarchical Observation Offerings.
/rec/inspire-SOS/HierarchicalOfferingImplementation of a SOS download service SHOULD implement the Hierarchical Offering extension of GetCapabilities to support offering discovery
External reference to an ObservationSet
The ObservationSet defined in chapter REF _Ref454547750 \r \h 7.2 provides a way to externally refer to a set of observations.
This feature is not natively handled by the Sensor Observation Service Interface Standard in the version identified above. Thus the implementation of ObservationSet is to be implemented via WFS.
/rec/inspire-SOS/ObservationSetImplementationImplementation of the ObservationSet FeatureType, or a subtype thereof, SHOULD be done via WFS. Its member association role SHOULD point to a SOS endpoint for example via xlink:href to URIs through which each observation member can be downloaded directlyService layer pattern
The following service pattern, illustrated from an INSPIRE perspective via the use of the Environmental Monitoring Facilities theme, is advised to help the discovery of available observation data.
1/ Identify via a set of WFS querie(s) on the given application schema, the monitoring facilitiy or monitoring network of interest
2/ Run a GetDataAvailability operation on that feature to retrieve reference(s) to candidate offering(s) that might be of interest to the user.
3/ Run a GetObservation operation on the offering identifier the user whishes to retrieve observation result from.
/rec/inspire-SOS/ServicePatternWhen linking a WFS server to a SOS server the pattern GetDataAvailability then GetObservation using the offering identifier as a token SHOULD be used.
Result encoding
/req/inspire-SOS/APIFor all encodings that are used for all or parts of an OM_Observation result, a public Application Programming Interface (API) SHALL be available to read the encoded file. This API SHALL be capable of exposing the information needed to realise INSPIRE spatial objects.
Note:
For example, a library for a given programing language which is capable of decoding WaterML 2.0 part I result is valid API in that context
Providing out of band result is a subject by itself. It was not feasible to clarify it and come up with relevant recommendations within the timeframe of that V3.0 update.
Yet the discussion paper provided with the previous version of D2.9 is still relevant. It is provided for information in REF _Ref455411586 \h \* MERGEFORMAT Annex J (informative): Discussion paper on Out-Of-Band Results
Expected next steps
This document is built on current agreed practices.
Observation data provision is a topic triggering many standardisation activities worldwide.
Several of them are worth mentioning and following as they might trigger enhancements in those practices; thus further revisions of this profile.
In no specific order of importance:
SensorML 1.0.1 is kept in this technical guidance document, as it is part of the OGC SOS 2.0 specifications. Once the SOS specifications are updated with SensorML 2.0, this document should be updated accordingly.
OGC TimeSeriesML Standards Working Group is currently developing a TimeSeriesML 1.0 candidate standard. Part of its content is in direct relation to former work on WaterML2.0part I: Timeseries (OGC 10-126r4).
An OGC discussion paper has recently been produced on O&M JSON encoding: OGC Observations and Measurements - JSON implementation (OGC 15-100). This might, in turn provide alternatives to light-weight data provision.
In order to reduce the size of the sos:GetObservationResponse the use of SWE data arrays as specified in SWE common ( HYPERLINK "http://www.opengis.net/spec/SWE/2.0/req/uml-block-components" http://www.opengis.net/spec/SWE/2.0/req/uml-block-components) and implemented in Observations and Measurements - XML Implementation ( HYPERLINK "http://www.opengis.net/spec/OMXML/2.0/req/SWEArrayObservation" http://www.opengis.net/spec/OMXML/2.0/req/SWEArrayObservation) is another alternative.
It is not directly specified in the current version of the Sensor Observation Service specification but can be reconstructed from the existing operations (see 11.2 Requirements Class: Result Retrieval).
Having a direct access to this behaviour is already available (non-standard) in some SOS 2.0 implementations; specifying it is in discussion within OGC SWE Domain Working Group.
The out of band issue addressed by the attached discussion paper is of relevance for many scientific communities generating huge content file. It needs to be finalised at some point.
OGC SensorThings API (OGC 15-078r1) is in the process of being published (its revision number is subject to changes). It aims at providing providing an open and unified framework to interconnect IoT sensing devices, data, and applications over the Web. Its datamodel is based on Observations and Measurements (ISO 19156:2011).
Eventually under Research Data Alliance an activity aims a providing best practices to dynamically cite subset of data (including observations): HYPERLINK "https://www.rd-alliance.org/system/files/documents/RDA-Guidelines_TCDL_draft.pdf" https://www.rd-alliance.org/system/files/documents/RDA-Guidelines_TCDL_draft.pdf
Annexes
Annex A (normative): INSPIRE specialised observations
The Specialised Observations package defines seven specialisations of OM_Observation ( REF _Ref348710989 \h \* MERGEFORMAT Erreur! Source du renvoi introuvable.).
All the specialised Observation types essentially add constraints to the underlying O&M model which characterise the result of the observation and the sampling regime used. For example, a PointTimeSeriesObservation is a timeseries at a single point in space (e.g. at a fixed station), so the 'Spatial Sampling Feature' in 19156 must be a spatial sampling point, and the 'phenomenonTime' must be a time period i.e. the observation must be taken over a period of time. The type of the result must be a set of time, value pairs.
In actual fact, the specialised Observation types do not specialise OM_Observation directly but specialise the informative O&M class SpecialisedCoverageObservation, which in turn specialises DiscreteCoverageObservation. These two classes between them ensure that the result of the observation is a coverage, and the feature of interest is a Spatial Sampling Feature e.g. a point, an area, a line.
Figure SEQ Figure \* ARABIC 21: Specialised Observation Types
Feature catalogue
Feature catalogue metadata
Application SchemaINSPIRE Application Schema Specialised ObservationsVersion number3.0Types defined in the feature catalogue
TypePackageStereotypesGridObservationGridded ObservationsfeatureTypeGridSeriesObservationGridded ObservationsfeatureTypeMultiPointObservationPoint ObservationsfeatureTypePointObservationPoint ObservationsfeatureTypePointObservationCollectionPoint ObservationsfeatureTypePointTimeSeriesObservationPoint ObservationsfeatureTypeProfileObservationTrajectory and Profile ObservationsfeatureTypeSpecimenObservationSpecimen ObservationsfeatureTypeSpecimenTimeSeriesObservationSpecimen ObservationsfeatureTypeTimeLocationValueTripleTrajectory and Profile ObservationsdataTypeTrajectoryObservationTrajectory and Profile ObservationsfeatureTypeSpatial object types
GridObservation
GridObservation
Name:
GridObservation
Subtype of:
SamplingCoverageObservation
Definition:
Observation representing a gridded field at a single time instant.
Description:
A GridObservation is an observation of some phenomenon (or phenomena) over a gridded field. E.g. Output from a model, or rectified, georeferenced satellite data.The result of a GridObservation is a discrete coverage within a compound spatiotemporal CRS where the domain consists of a two- or three-dimensional grid of points, all having the same time instant temporal component.
Stereotypes:
featureType
Constraint: featureOfInterest must be a SF_SamplingSolid or SF_SamplingSurface
Natural language:
featureOfInterest must be a SF_SamplingSolid or SF_SamplingSurface
OCL:
inv: self.featureOfInterest->forAll(oclIsKindOf(SF_SamplingSolid)) OR inv: self.featureOfInterest->forAll(oclIsKindOf(SF_SamplingSurface))
Constraint: phenomenonTime must be a TM_Instant
Natural language:
phenomenonTime must be a TM_Instant
OCL:
inv: self.phenomenonTime.oclIsKindOf(TM_Instant)
Constraint: result must be a RectifiedGridCoverage or ReferenceableGridCoverage
Natural language:
result must be a RectifiedGridCoverage or RefererencableGridCoverage
OCL:
inv: self.result.oclIsKindOf(RectifiedGridCoverage) OR self.result.oclIsKindOf(ReferenceableGridCoverage)
GridSeriesObservation
GridSeriesObservation
Name:
GridSeriesObservation
Subtype of:
SamplingCoverageObservation
Definition:
Observation representing an evolving gridded field at a succession of time instants.
Description:
A GridSeriesObservation is a time series of gridded fields representing the same phenomenon (or phenomena) over a series of times. E.g. Ocean model output.The result of a GridSeriesObservation is a discrete coverage within a compound spatiotemporal CRS where the domain consists of a series of two- or three-dimensional grids of points, each at a successive time instant.
Stereotypes:
featureType
Constraint: featureOfInterest must be a SF_SamplingSolid
Natural language:
featureOfInterest must be a SF_SamplingSolid
OCL:
inv: self.featureOfInterest->forAll(oclIsKindOf(SF_SamplingSolid))
Constraint: One of the axes of the domain must be a temporal axis.
Natural language:
OCL:
Constraint: phenomenonTime must be a TM_Period
Natural language:
phenomenonTime must be a TM_Period
OCL:
inv: self.phenomenonTime.oclIsKindOf(TM_Period)
Constraint: result must be a RectifiedGridCoverage or ReferenceableGridCoverage
Natural language:
result must be a RectifiedGridCoverage or a ReferenceableGridCoverage
OCL:
inv: self.result.oclIsKindOf(RectifiedGridCoverage) OR self.result.oclIsKindOf(ReferenceableGridCoverage)
PointObservation
PointObservation
Name:
Point Observation
Subtype of:
SamplingCoverageObservation
Definition:
Observation that represents a measurement of a property at a single point in time and space.
Description:
The PointObservation represents a single measurement or estimation of a property at a single point in time and space. For example a single temperature measurement at a fixed weather station.
Stereotypes:
featureType
Constraint: featureOfInterest must be a SF_SamplingPoint
Natural language:
featureOfInterest must be a SF_SamplingPoint
OCL:
inv: self.featureOfInterest->forAll(oclIsKindOf(SF_SamplingPoint))
Constraint: phenomenonTime must be a TM_Instant
Natural language:
phenomenonTime must be a TM_Instant
OCL:
inv: self.phenomenonTime.oclIsKindOf(TM_Instant)
Constraint: result must be a CV_DiscretePointCoverage
Natural language:
result must be a CV_DiscretePointCoverage
OCL:
inv: self.result.oclIsKindOf(CV_DiscretePointCoverage)
MultiPointObservation
MultiPointObservation
Name:
MultiPointObservation
Subtype of:
SamplingCoverageObservation
Definition:
Observation that represents a set of measurements all made at exactly the same time but at different locations
Description:
The MultiPointObservation is an Observation that represents a set of measurements of the same observed property all made at exactly the same time but at different locations, for example a distributed sensor network reporting the temperature at 10am. The result of this observation is a MultiPointCoverage.
Stereotypes:
featureType
Constraint: featureOfInterest shall be a SF_SamplingSurface
Natural language:
featureOfInterest must be a SF_SamplingSurface
OCL:
inv: self.featureOfInterest->forAll(oclIsKindOf(SF_SamplingSurface))
Constraint: phenomenonTime shall be a TM_Instant
Natural language:
phenomenonTime must be a TM_Instant
OCL:
inv: self.phenomenonTime.oclIsKindOf(TM_Instant)
Constraint: result must be a MultiPointCoverage
Natural language:
result must be a MultiPointCoverage
OCL:
inv: self.result.oclIsKindOf(MultiPointCoverage)
PointTimeSeriesObservation
PointTimeSeriesObservation
Name:
PointTimeSeriesObservation
Subtype of:
SamplingCoverageObservation
Definition:
Observation that represents a time-series of point measurements of a property at a fixed location in space
Description:
A PointTimeSeriesObservation is a time series of observations made at the same fixed spatial location e.g. Measurements made repeatedly by a fixed monitoring instrument.
Stereotypes:
featureType
Constraint: featureOfInterest must be a SF_SamplingPoint
Natural language:
featureOfInterest must be a SF_SamplingPoint
OCL:
inv: self.featureOfInterest->forAll(oclIsKindOf(SF_SamplingPoint))
Constraint: phenomenonTime must be a TM_Period
Natural language:
phenomenonTime must be a TM_Period
OCL:
inv: self.phenomenonTime.oclIsKindOf(TM_Period)
Constraint: result must be a TimeSeries
Natural language:
result must be a Timeseries
OCL:
inv: self.result.oclIsKindOf(TimeSeries)
PointObservationCollection
PointObservationCollection
Name:
PointObservationCollection
Subtype of:
ObservationSet
Definition:
A collection of Point Observations.
Description:
The PointObservationCollection is a collection of separate PointObservations. In the case where it is useful to group together a set of otherwise independent PointObservations the PointObservationCollection should be used to make this grouping. The grouping may be made on any basis e.g. it may be useful to group together PointObservations made by the same instrument or Environmental Facility, or in a particular measurement campaign. Each member of the PointObservationCollection must be a single PointObservation.
Stereotypes:
featureType
Constraint: member shall be of type PointObservation
Natural language:
each member shall be a PointObservation
OCL:
inv: self.member.oclIsKindOf(PointObservation)
ProfileObservation
ProfileObservation
Name:
ProfileObservation
Subtype of:
SamplingCoverageObservation
Definition:
Observation representing the measurement of a property along a vertical profile in space at a single time instant.
Description:
A ProfileObservation is an Observation representing the measurement of a property along a vertical profile in space at a single time instant. For example a CTD profile measuring salinity at different depths in the ocean.
Stereotypes:
featureType
Constraint: featureOfInterest must be a SF_SamplingCurve
Natural language:
featureOfInterest must be a SF_SamplingCurve
OCL:
inv: self.featureOfInterest->forAll(oclIsKindOf(SF_SamplingCurvet))
Constraint: phenomenonTime must be a TM_Instant
Natural language:
phenomenonTime must be a TM_Instant
OCL:
inv: self.phenomenonTime.oclIsKindOf(TM_Instant)
Constraint: result must be a ReferenceableGridCoverage or RectifiedGridCoverage
Natural language:
result must be a ReferenceableGridCoverage or a RectifiedGridCoverage
OCL:
inv: self.result.oclIsKindOf(ReferenceableGridCoverage) OR inv: self.result.oclIsKindOf(RectifiedGridCoverage)
Constraint: spatial domain of the result shall contain one axis and that shall be vertical
Natural language:
OCL:
SpecimenObservation
SpecimenObservation
Name:
Specimen Observation
Subtype of:
SamplingCoverageObservation
Definition:
Observation that represents a measurement of a property of a Specimen at a single point in time.
Description:
The SpecimenObservation represents a single measurement or estimation of a property of a Specimen at a single point in time. For example the Nitrate concentration of a water sample taken from a lake.
Stereotypes:
featureType
Constraint: featureOfInterest must be a SF_Specimen
Natural language:
featureOfInterest must be a SF_Specimen
OCL:
inv: self.featureOfInterest->forAll(oclIsKindOf(SF_Specimen))
Constraint: SF_Specimen samplingLocation is mandatory
Natural language:
SF_Specimen samplingLocation is mandatory
OCL:
inv: featureOfInterest.SF_Specimen.samplingLocation -> notEmpty()
Constraint: phenomenonTime must be a TM_Instant
Natural language:
phenomenonTime must be a TM_Instant
OCL:
inv: self.phenomenonTime.oclIsKindOf(TM_Instant)
Constraint: result must be a CV_DiscretePointCoverage
Natural language:
result must be a CV_DiscretePointCoverage
OCL:
inv: self.result.oclIsKindOf(CV_DiscretePointCoverage)
SpecimenTimeSeriesObservation
SpecimenTimeSeriesObservation
Name:
SpecimenTimeSeriesObservation
Subtype of:
SamplingCoverageObservation
Definition:
Observation that represents a time-series of point measurement of a property of a Specimen analysed at regular intervals
Description:
The SpecimenTimeSeriesObservation represents a time series of observations on a Specimen made repeatedly with the same procedure.
Stereotypes:
featureType
Constraint: featureOfInterest must be a SF_Specimen
Natural language:
featureOfInterest must be a SF_Specimen
OCL:
inv: self.featureOfInterest->forAll(oclIsKindOf(SF_Specimen))
Constraint: SF_Specimen samplingLocation is mandatory
Natural language:
SF_Specimen samplingLocation is mandatory
OCL:
inv: featureOfInterest.SF_Specimen.samplingLocation -> notEmpty()
Constraint: phenomenonTime must be a TM_Period
Natural language:
phenomenonTime must be a TM_Period
OCL:
inv: self.phenomenonTime.oclIsKindOf(TM_Period)
Constraint: result must be a TimeSeries
Natural language:
result must be a Timeseries
OCL:
inv: self.result.oclIsKindOf(TimeSeries)
TrajectoryObservation
TrajectoryObservation
Name:
TrajectoryObservation
Subtype of:
SamplingCoverageObservation
Definition:
Observation representing the measurement of a property along a meandering curve in time and space.
Description:
A TrajectoryObservation is an Observation representing the measurement of a property along a curve in time and space. For example a Pollutant concentration from a mobile air quality sensor.
Stereotypes:
featureType
Constraint: featureOfInterest must be a SF_SamplingCurve
Natural language:
featureOfInterest must be a SF_SamplingPoint
OCL:
inv: self.featureOfInterest->forAll(oclIsKindOf(SF_SamplingPoint))
Constraint: phenomenonTime must be a TM_Period
Natural language:
phenomenonTime must be a TM_Period
OCL:
inv: self.phenomenonTime.oclIsKindOf(TM_Period)
Constraint: result must be a TimeSeries
Natural language:
result must be a Timeseries
OCL:
inv: self.result.oclIsKindOf(TimeSeries)
Constraint: result.point must be TimeLocationValueTriple
Natural language:
each point in the result must be a TimeLocationValueTriple
OCL:
inv: self.result.point.oclIsKindOf(TimeLocationValueTriple)
Data types
TimeLocationValueTriple
TimeLocationValueTriple
Name:
TimeLocationValue Triple
Subtype of:
AnnotatedTimeValuePair
Definition:
A triple set of Time, location, value (measurement). For example, at a point along a trajectory.
Stereotypes:
dataType
Attribute: location
Name:
location
Value type:
GM_Position
Definition:
Geographic location where value is valid.
Multiplicity:
1
Imported types (informative)
This section lists definitions for feature types, data types, enumerations and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.
AnnotatedTimeValuePair
AnnotatedTimeValuePair
Package:
Timeseries
Reference:
Taylor, Peter (ed.), OGC WaterML Encoding Standard, version 2.0.0, Open Geospatial Consortium, 2012 [OGC 10-126r3]
GM_Position
GM_Position
Package:
Coordinate geometry
Reference:
Geographic information -- Spatial schema [ISO 19107:2003]
ObservationSet
ObservationSet
Package:
Observation References
Reference:
Guidelines for the use of Observations & Measurements and Sensor Web Enablement-related standards in INSPIRE [DS-D2.9]
Definition:
Links a set of Observations
Description:
This class is used to link multiple related Observations together
SamplingCoverageObservation
SamplingCoverageObservation
Package:
Sampling Coverage Observation
Reference:
Geographic information -- Observations and measurements [ISO/TS 19156:2011]
wml2: MeasurementTimeseries implementation
The following is taken from HYPERLINK "http://schemas.opengis.net/waterml/2.0/timeseries.xsd" http://schemas.opengis.net/waterml/2.0/timeseries.xsd
Figure SEQ Figure \* ARABIC 22 : wml2:MeasurementTimeseries
Annex B (normative): INSPIRE Process
Feature Catalogue
Feature catalogue metadata
Application SchemaINSPIRE Application Schema ProcessesVersion number2.0Types defined in the feature catalogue
TypePackageStereotypesProcessProcessesfeatureTypeProcessParameterProcessesdataType
Spatial object types
Process
Process
Name:
Process
Subtype of:
OM_Process
Definition:
Description of an observation process
Stereotypes:
featureType
Attribute: documentation
Name:
documentation
Value type:
DocumentCitation
Definition:
Further information ( online/offline) associated with the process .
Multiplicity:
0..*
Stereotypes:
voidable
Attribute: inspireld
Name:
inspireId
Value type:
Identifier
Definition:
External object identifier of the spatial object.
Multiplicity:
1
Stereotypes:
voidable
Attribute: name
Name:
name
Value type:
CharacterString
Definition:
Name of the Process
Multiplicity:
0..1
Stereotypes:
voidable
Attribute: processParameter
Name:
process parameter
Value type:
ProcessParameter
Definition:
Parameter controlling the application of the process and as a consequence its output.
Description:
Typical examples of using processParameter are: description of instrumentation settings for a specific measurement or measurement series ; description of intial contidions in numerical computations e.g. simulations. NOTE The values of a procesParameter are stored in OM_Observation.parameter>NamedValue.value as they are specific to the event of the observation and not to the applied process . The relevant OM_Observation.parameter>NamedValue.name shall be the same with Process.processParameter>ProcessParameter.name.EXAMPLE Analysis time of a forecast
Instance of Process
Process.processParameter>ProcessParameter.name:http://inspire.jrc.ec.europa.eu/inspire/processParameterValue.html#AnalysisTime
Instance of OM_Observation
OM_OObservation.parameter>NamedValue.name:http://inspire.jrc.ec.europa.eu/inspire/processParameterValue.html#AnalysisTimeOM_Observation.parameter>NamedValue.value:00z-15/05/2011
Multiplicity:
0..*
Stereotypes:
voidable
Attribute: responsibleParty
Name:
responsible party
Value type:
RelatedParty
Definition:
Individual or organisation related to the process.
Description:
EXAMPLE For a numerical simulation a responsible party may be the NWP centre which conducted the simulation
Multiplicity:
1..*
Stereotypes:
voidable
Attribute: type
Name:
type
Value type:
CharacterString
Definition:
Type of process.
Description:
EXAMPLE raingauge, numerical model.
Multiplicity:
1
Stereotypes:
voidable
Data types
ProcessParameter
ProcessParameter
Name:
Process Parameter
Definition:
Description of the given parameter
Stereotypes:
dataType
Attribute: description
Name:
description
Value type:
CharacterString
Definition:
Description of the process parameter.
Multiplicity:
0..1
Attribute: name
Name:
name
Value type:
ProcessParameterNameValue
Definition:
Name of the process parameter.
Multiplicity:
1
Values:
The allowed values for this code list comprise any values defined by data providers.
Code lists
ProcessParameterNameValue
ProcessParameterNameValue
Name:
Process Parameter Name Value
Definition:
A code list of names of process parameters.
Description:
This code list itself is an empty placeholder and should be extended and specified for any thematic domain.
Extensibility:
any
Identifier:
Values:
The allowed values for this code list comprise any values defined by data providers.
Imported types (informative)
This section lists definitions for feature types, data types, enumerations and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.
CharacterString
CharacterString
Package:
Text
Reference:
Geographic information -- Conceptual schema language [ISO/TS 19103:2005]
DocumentCitation
DocumentCitation
Package:
Base Types 2
Reference:
INSPIRE Generic Conceptual Model, version 3.4 [DS-D2.5]
Definition:
Citation for the purposes of unambiguously referencing a document.
Identifier
Identifier
Package:
Base Types
Reference:
INSPIRE Generic Conceptual Model, version 3.4 [DS-D2.5]
Definition:
External unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object.
Description:
NOTE1 External object identifiers are distinct from thematic object identifiers.NOTE 2 The voidable version identifier attribute is not part of the unique identifier of a spatial object and may be used to distinguish two versions of the same spatial object.NOTE 3 The unique identifier will not change during the life-time of a spatial object.
RelatedParty
RelatedParty
Package:
Base Types 2
Reference:
INSPIRE Generic Conceptual Model, version 3.4 [DS-D2.5]
Definition:
An organisation or a person with a role related to a resource.
Description:
NOTE 1 A party, typically an individual person, acting as a general point of contact for a resource can be specified without providing any particular role.
Process Encoding with SensorML 1.0.1
Mapping to SensorML
INSPIRE Attribute & Datatype SensorML XPathdocumentation : DocumentCitationname/sml:documentation/sml:Document/gml:descriptionshortNameNAdate/sml:documentation/sml:Document/sml:datelink/sml:documentation/sml:Document/sml:onlineResource/@xlink:hrefinspireId : IdentifierNOTE The inspireId should be provided in an individual IdentifierList entry. The identifier should carry the name inspireId.
/sml:identification[1]/sml:IdentifierList/sml:identifier/@name = inspireIdlocalId/sml:identification/sml:IdentifierList/sml:identifier/sml:Term/sml:valuenamespace/sml:identification/sml:IdentifierList/sml:identifier/sml:Term/sml:codeSpace/@xlink:hrefversionIdname : CharacterString/sml:identification/sml:IdentifierList/sml:identifier/sml:Term/sml:value
/sml:identification/sml:IdentifierList/sml:identifier/@name = procedureNameprocessParameter : ProcessParameterNOTE The pair of name and description for one process parameter must always be grouped together in one ClassifierListdescription/sml:classification/sml:ClassifierList/sml:classifier/sml:Term
/sml:classification/sml:ClassifierList/sml:classifier/@name = descriptionname/sml:classification/sml:ClassifierList/sml:classifier/sml:Term/sml:value
/sml:classification/sml:ClassifierList/sml:classifier/@name = nameresponsibleParty : RelatedParty/sml:contact/sml:ResponsiblePartytype : CharacterString/sml:classification/sml:ClassifierList/sml:classifier/sml:Term/sml:value
NOTE All XPaths should start with /sml:SensorML/sml:member/sml:Component, for brevity this has been reduced to
Example
The following section applies the mapping depicted in the previous chapter and show how an INSPIRE Process can be encoded using OGC SensorML 1.0.1.
identifier
procedureName
procedureType, i.e. "raingauge"
o the water hardness of the river being sampled from
WaterHardness
Alexandre Robin
University of Alabama in Huntsville
Research Scientist
(256)9617978
robin@nsstc.uah.edu
Description of Process
2010-12-02
Figure SEQ Figure \* ARABIC 23 : INSPIRE Process featureType encoded in SensorML 1.0.1 example
Annex C (normative): ObservationSet Feature catalogue
Feature catalogue metadata
Application SchemaINSPIRE Application Schema Observation ReferencesVersion number2.0Types defined in the feature catalogue
TypePackageStereotypesObservationSetObservation ReferencesfeatureTypeSpatial object types
ObservationSet
ObservationSet
Name:
ObservationSet
Definition:
Links a set of Observations
Description:
This class is used to link multiple related Observations together
Stereotypes:
featureType
Attribute: extent
Name:
extent
Value type:
EX_Extent
Definition:
Information about the spatial and temporal extent.
Multiplicity:
1
Attribute: inspireId
Name:
inspireId
Value type:
Identifier
Definition:
External object identifier of the spatial object.
Multiplicity:
1
Association role: member
Name:
member
Value type:
OM_Observation
Definition:
One member of the ObservationSet
Multiplicity:
1..*
Imported types (informative)
This section lists definitions for feature types, data types, enumerations and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.
EX_Extent
EX_Extent
Package:
Extent information
Reference:
Geographic information -- Metadata [ISO 19115:2003/Cor 1:2006]
Identifier
Identifier
Package:
Base Types
Reference:
INSPIRE Generic Conceptual Model, version 3.4 [DS-D2.5]
Definition:
External unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object.
Description:
NOTE1 External object identifiers are distinct from thematic object identifiers.NOTE 2 The voidable version identifier attribute is not part of the unique identifier of a spatial object and may be used to distinguish two versions of the same spatial object.NOTE 3 The unique identifier will not change during the life-time of a spatial object.
Annex D (normative): GetDataAvailability V2 Operation
Operation specification
NOTE:
The content below is based on the specification of GetDataAvailabity according to OGC Sensor Observation Service 2.0 Hydrology Profile (OGC 14-004r1).
Based on the D2.9 update this schema is currently being updated with the following elements:
ElementDescriptionCardinalityofferingReference to the offering (anyURI)0..1formatDescriptorContains the following elements:
One responseFormat element containing a URI identifying the response format
One or multiple observationType elements containing one URI identifying the observation types supported for this response format0..*
It should be considered whether further elements are required to provide the necessary offering metadata (e.g. resultTime, featureOfInterestType).
Complementary to this it should also be considered to include the additional fields of the response also as optional query parameters into the GetDataAvailability request.
The following shows the example of a GetDataAvailability V2 response to the GetDataAvailability request on the observedProperty GroundWaterLevel depth (code HYPERLINK "http://id.eaufrance.fr/par/1689.xml" http://id.eaufrance.fr/par/1689.xml in the French Water Information System).
Please note: this is referred as GDA version 2 in order to distinguish it from the version specified in the OGC SOS 2.0 Hydrology Profile Best Practice Paper:
2016-01-05T15:00:00.000Z
2016-06-16T14:00:00.000Z
3433
http://ressource.brgm-rec.fr/obs/rawOfferingPiezo/06988C0281/F/PZ/2-1053
http://inspire.ec.europa.eu/featureconcept/Process
http://inspire.ec.europa.eu/schemas/omso/3.0
http://inspire.ec.europa.eu/featureconcept/PointTimeSeriesObservation
Figure SEQ Figure \* ARABIC 24 : GetDataAvailability V2 reponse example
Initial GetDataAvailability operation specification (from (OGC 14-004r1):
For the detailed schema, please refer to Annex B of OGC 14-004r1
Mapping with INSPIRE ObservingCapability mapping
The proposed mapping enables to use GetDataAvailability V2 as a way to provide INSPIRE ObservingCapability as defined in the theme III.7 Environmental Monitoring Facilities.
Figure SEQ Figure \* ARABIC 25 : INSPIRE ObservingCapability- GetDataAvailability V2 reponse mapping
Annex E (normative): Hierarchical Observation Offerings Specification
This subsection describes an approach how to model the relation between an Observation Offering and the lower-level Offerings it comprises within the ObservationOfferings section of SOS Capabilities document.
swes:extension element available the ObservationOfferings section for defining an additional element which contains information about the sub-offerings of a higher-level offering will be reused.
Since no XML schema exists to describe the offering/sub-offering relation in the swes:extension, a suitable extension element must be defined. This extension shall be named relatedOffering:
ElementDescriptionCardinalityrelatedOfferingContains an OfferingContext element which describes an offering relation0..*
Each relatedOffering element shall contain an OfferingContext element describing one relation between offering and sub-offering:
ElementDescriptionCardinalityroleRole of the relation (gml:Reference)1..1relatedOfferingLink to the related offering (gml:Reference)1..1
Finally, it is recommended to add an additional name attribute to the extension element of the Observation Offerings in order for the client to find the extension of interest if several extensions are contained in the object. The attribute should be of type NCName.
The following listing shown as example of this approach (the ro namespace prefix is a placeholder for the final namespace and namespace prefix):
http://www.52north.org/test/offering/1
codeSpace="eng">Offering for sensor 1
http://www.52north.org/test/procedure/1
Annex F (informative): Revision history
DateReleaseAuthorParagraph modifiedDescription2011-06-121.0Katharina SchleidtAllInitial D2.9 release2013-02-222.0rc3Katharina SchleidtAllReflects the content of the draft amendment to Commission Regulation (EU) No 1089/2010 for the Annex II+III spatial data themes as submitted to the INSPIRE Committee.2016-01-283.0Draft1Sylvain GrelletAllComplete restructuration of D2.9 to an OGC profile according Ispra meeting2016-03-213.0Draft2Sylvain GrelletAllGenerated after draft1 circulation to core group, feedback taken into account + link with TG SOS update exercise2016-05-123.0Draft3Sylvain GrelletAllAfter JRC revision2016-06-093.0Draft4Sylvain GrelletAllAfter Inspire maintenance group (MIWP-7a) feedbacks
Annex G (informative): Short introduction to O&M
Context
While INSPIRE is foremost a Spatial Data Infrastructure, several of the Annex II & III themes have been specified so that their scope, in addition to the basic spatial information, includes measured, modelled or simulated data about the real world. The ISO 19156:2011 International Standard on Observations and Measurements (O&M) was designed for this explicit purpose, and thus shall be used in INSPIRE to cover these requirements.
In order to maintain compatibility with the various domain specific standards based on O&M such as CSML or WaterML 2.0, INSPIRE Cross Thematic Working Group on Observations & Measurements has decided not to specialise OM_Observation with additional attributes within INSPIRE; all specialisations provided only pertain to the addition of constraints.
This section serves as a simple overview of the main concepts of the O&M standard for better understanding of the INSPIRE specific design patterns proposed. For more detailed information on O&M, please refer either to ISO 19156:2011 or the OGC Document: OGC 10-004r3 (Geographic Information: Observations and Measurements - OGC Abstract Specification Topic 20). Its Annex B provides a Mapping of O&M terminology to common usage.
Observations and Measurements
O&M is intended for cross-domain work and data exchange; it should mainly be used if provenance and quality of property values shall be provided with the data (e.g. to allow users to determine fitness-for-purpose).
It is also useful for data discovery using the primary slots in the model (feature of interest, observed property, procedure) and can assist in data fusion across discipline boundaries.
For intra-domain purposes, if the observation metadata is not important to the user, or the provider does not want to provide it, do not use O&M.
Before a decision is reached to use O&M, the requirements must be clearly analysed to determine if an Observation-centric view is necessary or if a Result/Coverage-centric view will suffice (see chapter REF _Ref447899474 \r \h 6.1.1 REF _Ref447899466 \h Use of O&M vs. Coverage Model).
Observations
SHAPE \* MERGEFORMAT
For the structuring of data pertaining to observations, the O&M standard has defined the OM_Observation type. The following diagram shows the basic OM_Observation type with all its attributes, associations and constraints.
Figure SEQ Figure \* ARABIC 26 : The basic Observation type
Observation Associations
The following associations link classes to the observation that serve to explicitly describe all aspects of the observation performed,
Feature-Of-Interest
Association:DomainRole:featureOfInterestInverse Role:propertyValueProvider
The association Domain links to the FeatureType (GFI_Feature) that is the subject of the observation and carries the observed property. This is a representation of the real world object the property is being estimated on or is a feature intended to sample the real-world object
In the REF _Ref447894069 \h \* MERGEFORMAT
Note:
In the context of INSPIRE a dedicated Technical Guidance for implementing download services using the OGC Sensor Observation Service and ISO 19143 Filter Encoding provides additional requirements and recommendations.
O&M Design Patterns chapter various example of featureOfInterest are introduced:
species occurrence point
air bubble surrounding intake
water column
trajectory
grid
water sample
Various terms are often used in other domains:
Earth Observations:2-D swath or scene; 3-D sampling spaceEarth science simulations:Section, swath, volume, gridAssay/Chemistry:SampleGeology field observations:Location of structure observation; Rock sample
Property
The association Phenomenon links to the GF_PropertyType describing the property of the feature-of-interest that is being estimated in this observation.
In the REF _Ref447894069 \h \* MERGEFORMAT
Note:
In the context of INSPIRE a dedicated Technical Guidance for implementing download services using the OGC Sensor Observation Service and ISO 19143 Filter Encoding provides additional requirements and recommendations.
O&M Design Patterns chapter, the following types are used as observedProperty:
height
O3 hourly mean
salinity
(water) temperature
(water) color
nitrate concentration
biochemical oxygen demand
The following terms are used to refer to the property in other domains:
Earth Observations:parameter, variable such as Reflectance, Particulate
Matter 2.5Metrology:measurand such as MassEarth science simulations:Variable, parameter Assay/Chemistry:Analyte Geology field observations:Strike and dip, lithology, alteration state, etc.
Procedure
Association:ProcessUsedRole:procedureInverse Role:generatedObservation
The association ProcessUsed links to the OM_Process describing the process or methodology used in the estimation of the result in this observation.
In the REF _Ref447894069 \h \* MERGEFORMAT
Note:
In the context of INSPIRE a dedicated Technical Guidance for implementing download services using the OGC Sensor Observation Service and ISO 19143 Filter Encoding provides additional requirements and recommendations.
O&M Design Patterns chapter, the following types are used as observedProperty:
Triagulation
EquipmentType : Horiba APNA (360), detection limit 0.1
Survey Ship Type X, Probe Type Y, Thermometer Type Z, Camera Type A, Lens Type B, Simulation algorithm xx
Laboratory X, Method Y
The following terms are used to refer to the procedure in other domains:
Earth Observations:method, sensor type such as ASTERMetrology:instrument such as a balanceEarth science simulations:Earth process simulator Assay/Chemistry:Instrument, analytical process
Result
Association:RangeRole:result
The association Range links to the estimate of the property on the feature-of-interest generated by the procedure.
The following terms are used to refer to the Result in other domains:
Earth Observations:observation value, measurement value, observation such as 35 g/mMetrology:Value such as 35 mgEarth science simulations:modelAssay/Chemistry:Analysis
Observation Attributes
The following attributes provide further detail on the observation performed.
Parameter
Datatype:NamedValue
The attributes provided under parameter describe any event-specific parameter of relevance to interpreting the observation. These will typically complement the re-usable (event-neutral) description of the observation procedure. The datatype NamedValue allows for the provision of key/value pairs for the parameter.
Within O&M, any GenericName may be provided as the name, and any data type may be provided for the value. In this document, this attribute as been already used for specific purposes:
See chapter REF _Ref447895394 \w \h \* MERGEFORMAT 7.1.4 REF _Ref447895415 \h \* MERGEFORMAT Procedure esp processParameter requirements
or chapter REF _Ref447895341 \w \h \* MERGEFORMAT 7.1.5 REF _Ref447895268 \h \* MERGEFORMAT Online resource
/rec/inspire-om-core/onlineResourceWhen providing a direct reference to an observation using resolvable HTTP URI (see /rec/inspire-SOS/ObservationURI), one or more gml:metaDataProperty//gml:GenericMetaData/
gmd:CI_OnlineResource elements identifying services that deliver the actual measurements SHOULD be provided.
http://ressource.brgm-rec.fr/service/sosRawPiezo
OGC:SOS-2.0.0
Figure 16 : Providing the online resource delivering the observation
Linking to monitoring facility / network
PhenomenonTime
Datatype:TM_Object
The attribute phenomenonTime shall describe the time that the result applies to the property of the feature-of-interest.
[ISO 19156:2011(E)]
This may be the time when a specimen was collected or the observation procedure was performed on a real-world feature, but may be in the future in the case of forecasts, or in the deep past for archeological or geological observations. The type TM_Object allows for time instants, time periods (where the result is extensive in time such as a temporal coverage), or temporal topologies if this is the most appropriate representation.
ResultQuality
Datatype:DQ_Element
When the Observation result consists of a single value, or a set of values that are all of the same quality, the quality of the result is to be provided here.
However, in the case of complex results (spatial or temporal coverages), the quality may vary across the result values; in this case, the quality should be provided for each value within the result.
A third option not to trigger the machinery of ISO 19157 in simple usecases is to store quality related information in the Parameter attribute.
ResultTime
Datatype:TM_Instant
The attribute resultTime describes the time when the result became available, typically when the procedure associated with the observation was completed. For some observations this is identical to the phenomenonTime. However, there are important cases where they differ.
[ISO 19156:2011(E)]
An example of this is a specimen analyzed in a laboratory, where the PhenomenonTime should correspond to the time the specimen was taken, while the ResultTime is the time when the laboratory analysis was completed.
ValidTime
Datatype:TM_Period
If present, the attribute validTime describes the time period during which the result is intended to be used. This attribute is commonly required in forecasting applications.
[ISO 19156:2011(E)]
featureOfInterest and Sampling / SampledFeature identification
Introduction
In order to understand the meaning of an observation, one must also understand the exact domain of the observation, the feature-of-interest. In some cases, this feature-of-interest can be analysed in its entirety. Some examples for this are:
The weight of a specific animal
The type of crop planted on a specific field
In this case, this domain feature should be directly used as the featureOfInterest of the Observation. In other cases, it is difficult to estimate a property on the entirety of a feature; thus, one usually samples one representative part of this larger feature for analysis purposes. In this case, the feature-of-interest is an artefact of the sampling strategy which in O&M is called the samplingFeature, which refers to the feature it has been taken as a representative of as its sampledFeature. Some examples of this are:
A rock sample taken as a representative for an outcrop.
The measurement of air temperature at a particular location (sampling the atmosphere at a point).
A sample of river water taken as a representative for the river segment sampled from.
The diagram below shows the relation between SamplingFeature and SampledFeature:
Figure SEQ Figure \* ARABIC 27 : Sampling feature vs. sampled feature [ISO 19156:2011, figure 10]
In further cases, a specific specimen is taken and analysed; for this purpose, SF_Specimen has been defined as a specialised form of SF_SamplingFeature.
Figure SEQ Figure \* ARABIC 28 : SF_Specimen overview
SamplingFeature
A samplingFeature is an intermediate feature involved in an observation which allows an estimate of a property value for the ultimate feature of interest to be made; this feature provides the direct context for the specific observation (spatial, specimen). In the case of a spatial sampling feature, which is derived from the SF_SamplingFeature, the spatialSamplingFeature is a point, line, surface or volume which may be co-located with the ultimate FOI. e.g. a point in a river. The result values will vary across the spatialSamplingFeature.
The following terms describe specific samplingFeatures in various domains:
Earth Observations:2-D swath or scene; 3-D sampling spaceEarth science simulations:Section, swath, volume, gridAssay/Chemistry:Polished section, probe spot, pulpGeology field observations:Outcrop; Location of structure observation
Sampled Feature
The sampledFeature is the feature the samplingFeature was sampled from, providing the ultimate context for the observation. An example of sampledFeature would be the river segment a specimen was taken from
The following terms are used to refer to the sampledFeature in other domains:
Earth Observations:Earth surface; media (air, water, ), Global Change Master Directory "Topic"Earth science simulations:Atmosphere, ocean, solid earthGeology field observations:Ore body, Geologic Unit
Specimen
A specimen is a feature sampled from a feature of interest to enable ex-situ observation, such as in a laboratory. Information on how the specimen was acquired, where it is presently stored, and its preparation procedure are provided.
The following terms are used to refer to the Specimen in other domains:
Assay/Chemistry:Sample; Pulp, separationGeology field observations:Rock sample
Sampling Features in SamplingCoverageObservations
Most of the specialised observations described in REF _Ref444272183 \h Annex A (normative): INSPIRE specialised observations are derived from the specialized Observation class called SamplingCoverageObservation, which is defined in Annex D of ISO 19156:2011.
One of the constraints imposed on the SamplingCoverageObservation is that the featureOfInterest must be a SamplingFeature.
A further constraint imposed by use of the SamplingCoverageObservation is that the shape of the sampling feature of interest shall contain the spatial elements of the domain of the coverage result. The intention behind this constraint is explained in detail in Woolf, A. (ed.): Climate Science Modelling Language (CSML): Sampling Coverage Observations for the met/ocean domain (OGC 11-021):
(A) spatial sampling feature may provide a summary description of a sampling geometry more fully specified in the result of a discrete coverage observation. In this sense it may be regarded as playing a role similar to the familiar bounding box of dataset metadata (aiding discovery and spatial querying), but with a richer choice of geometries more suitable for observations. ()
The shape of the spatial sampling feature may be regarded as a projection of the full spatiotemporal sampling geometry onto a spatial subspace . Projection of the full sampling geometry onto the temporal axis defines the time of the observation. Thus, the spatial sampling feature and observation phenomenon time broadly summarise the where and when, respectively, of an observation, with the full geometric sampling complexity available in the domain of the coverage result.
Thus, special care must be taken when defining SamplingFeatures for the use with SamplingCoverageObservations, to make sure that the domain of the result coverage is inside the geometry of the SamplingFeature.
SHAPE \* MERGEFORMAT
Process
Within O&M, the base definition of OM_Process is an empty class. For use within INSPIRE, the following 2 options have been determined:
Process: The Process class defined within INSPIRE allows for the lightweight provision of procedural information. The disadvantage is that it goes away from the base standard and thus must be optional to allow for re-use of domain standards
SensorML: A SensorML overview is provided in chapter REF _Ref451519702 \r \h \* MERGEFORMAT 10.9.3. Using SensorML has the advantage of maintaining compliance with the wider SWE scope. To bring this closer to INSPIRE, we propose a standardized mapping of agreed upon attributes to the SensorML model (see chapter REF _Ref451519767 \r \h \* MERGEFORMAT 10.2.2 REF _Ref451519767 \h \* MERGEFORMAT Process Encoding with SensorML 1.0.1). It is important to keep in mind that SensorML was developed by a team whose main experience was remote sensing, so it may not be suitable for all domains. Much will depend on how SensorML V2.0 is taken into account in SOS revision.
Types of Process Parameters expected
Very different types of information will be supplied via the Process Parameters. At present, the following categories have been identified:
Results of related "observations": not necessarily available in the form of an observation, the information provided are the results of related observations relevant to the current observation. Examples of this are:
the water hardness of the river being sampled from
the width of the river at the measurement point
Temporal information not currently covered by the OM_Observation. This is often necessary in forecasts and modeling. Examples of this are:
Analysis Time
Forecast period
Instrument settings can be stored via process parameters to allow for the reuse of this process instance in various settings. Examples of this are:
sampling rate
minimum & maximum offset
EnsembleMember can be specified as an easy way of providing data from aggregate sensors. In this case, the Process Parameters provide information in which exact sensor was used.
Referencing Process Parameters
For true interoperability, the re-use of Process Parameters stemming from an external source (vocabulary) is necessary.
Result
In many cases, it will be possible to provide the result data using either GML coverages or the result types provided in SWE Common. These allow for the standardized encoding of a wide range of simple and complex result types including spatial and temporal coverages.
The following examples from ISO 19156:2011 illustrate different types of observations with various types of spatial sampling features. They are listed in order to provide help in understanding the different types of results that would be consistent with the spatial sampling feature type in these observations:
Observation class Example Spatial sampling feature Coverage result Profile Expendable bathythermograph observation of seawater temperature SF_SamplingCurve one-dimensional grid at fixed (x,y,t) within four-dimensional (x-y-z-t) CRS
grid axis aligned with CRS z-axis ProfileTimeSeries Radar wind profiler measurement SF_SamplingCurve two-dimensional grid at fixed (x,y) within four-dimensional (x,y,z,t) CRS
grid axes aligned with CRS z- and t-axes Trajectory Pollutant concentration from mobile air quality sensor SF_SamplingCurve one-dimensional grid within four-dimensional (x-y-z-t) CRS Section Vertical profiles of water current measurements taken by an acoustic doppler current profiler towed along a ships track SF_SamplingSurface two-dimensional grid within four-dimensional (x-y-z-t) CRS
one grid axis aligned with CRS z-axis GridTimeSeries Time-series of 3-D velocity field from a finite-difference seismic model SF_SamplingSolid four-dimensional grid within four-dimensional (x-y-z-t) CRS Figure SEQ Figure \* ARABIC 29 : Examples of coverage results for different sampling regimes [ISO 19156:2011, Table D.1]
Facility / Network
While there is no formal facility or station concept within the O&M standard, there is often a requirement to provide information on specialized locations used for the provision of multiple observations. While the O&M standard suggests the modelling of stations, which could be seen as facilities, as a form of SamplingPoint, this causes difficulties when one wishes to include remote sensing within the facility concept. It also doesnt provide support for mobile facilities, and thus cannot be used within the INSPIRE context.
Within INSPIRE, Environmental Monitoring Facilities are their own theme across thematic domains. At the same time, other INSPIRE Themes provide either primary data from Environmental Monitoring Facilities, or processes results based on this primary data.
Thus, an EnvironmentalMonitopringFacility concept is being defined to cover the requirements stemming from all these themes. INSPIRE Environmental Monitoring Facilities can also be grouped together into Environmental Monitoring Networks. For further details please refer to INSPIRE D2.8.III.7 Data Specification on Environmental Monitoring Facilities Technical Guidelines.
As derived coverage results are often calculated from primary measurements stemming from an entire network, this type of observation should be linked to the Network class.
Annex H (informative): Short introduction to SWE
Context
In addition to the use of the Observations and Measurements standard, further elements of the OGC Sensor Web Enablement Suite (SWE) have been identified as useful for the encoding and provision of observational data. While further SWE specifications may be nominated for use in INSPIRE, at the present we have identified the following:
Sensor Observation Service (SOS): service created for the provision of observational data;
SensorML: Standard for the provision of procedural information;
SWE Common: Includes result encoding options.
Please note, that there are more SWE elements and services respectively. However, they are not within the scope of this document. Please see HYPERLINK "http://www.opengeospatial.org/ogc/markets-technologies/swe" http://www.opengeospatial.org/ogc/markets-technologies/swe for a wider view on this topic including sensor tasking, filtering, notifications from sensor measurements, etc.
SOS Overview
The OGC SOS specification is based on the OGC Web Service Common specification, thus, it has shared structures and data types of service requests with the other OGC Web Services. In the case of SOS, the operation signature is constrained by the observation schema, as it defines the response model.
Overview of core operation is provided below, for more detailed information on SOS version 2.0, please refer to the OGC Document provided in chapter REF _Ref447898571 \w \h 3. REF _Ref447898576 \h References.
GetCapabilities
This operation allows clients to retrieve service metadata about a specific service instance, including metadata about the tightly-coupled data served. In addition to more generic capabilities response elements such as filter options, the SOS GetCapabilities returns a list of so called ObservationOffering, which are groupings of available observations described by their feature of interest, procedure, observed property, temporal coverage and the like. This allows the user application to clearly identify the types and quality of data that can be requested from this service.
GetObservation
The GetObservation operation is designed to query a service to retrieve observation data structured according to the Observations and Measurements specification. Within the GetObservation request, the user can provide a filter, including the desired observed property, feature of interest, time interval, observationoffering identifier which determines which observations are to be returned. The response to the GetObservation request is one or more observations encoded as an OM_Observation, as shown in REF _Ref447898762 \h Annex G (informative): Short introduction to O&M.
DescribeSensor
DescribeSensor is designed to request detailed sensor metadata. The response of this operation provides this procedural metadata, encoded using a well-defined format. This provides all information required on how the observation or measurement was obtained. This information should be sufficient to determine if the data from the observations meets ones further processing requirements.
GetFeatureOfInterest
GetFeatureOfInterest returns a feature of interest that is associated with an observation served by the SOS. The features are encoded using a specific GML application schema.
SensorML Overview
Sensor Model Language (SensorML) was created by the sensor community for structuring of information pertaining to sensors. This covers all procedural information as required within O&M, and is often the default procedure format expected by SOS implementations as this is the primary recommendation from SOS 2.0. Of primary interest to these guidelines is the SensorML component class this class was created for the description of measurement components (i.e. individual sensors). For complex properties the system class may be used,
While SensorML was primarily designed by the sensor community, due to its abstract structure it can also be used for data survey process descriptions not using sensors, or very abstract concepts of sensors such as human sensors performing a biodiversity survey.
At present, SensorML is available in versions 1.0.1. and 2.0. SensorML version currently being identified by Sensor Observation Service (SOS) 2.0 (OGC 12-006) is version 1.0.1.
Thus, only that version has been considered within this document.
A mapping between the INSPIRE Process Feature Type and SensorML 1.0.1 is provided in section REF _Ref453579219 \r \h 10.2.2.1 REF _Ref453579219 \h Mapping to SensorML.
For more detailed information on SensorML, please refer to the OGC Document: OGC 07-122r2.
SWE Common Result Encoding
OGC SWE 2.0 provides dedicated result types in the package SWE Common. For an example of the encoding of time series data (in the example given it pertains to air quality measurements), please see Annex A.1 REF _Ref336432861 \h \* MERGEFORMAT SWE Common Results.
Annex I (informative): Observable properties model
This exercise is based on the experience from Climate Science Modelling Language version 3 (OGC Pending Docs 11_021) which extends ISO 19156.
Figure SEQ Figure \* ARABIC 30 : Complex Properties Model
AbstractObservableProperty
The AbstractObservableProperty class is the root of the ObservableProperty model. It is implemented by two specialisations: ObservableProperty and CompositeObservableProperty.
ObservableProperty
At its simplest an ObservableProperty simply carries a reference to a phenomenon definition in a codelist with optional units of measure. However an ObservableProperty definition may be augmented using Constraints and/or Statistical Measures to create a more full definition of the observed property.
Statistical Measures
The StatisticalMeasure is used to describe some statistical grouping of the data. It has an attribute where one can provide the statistical function being applied (i.e. mean). In addition, it provides attributes for the description of what the statistics are being applied to, i.e over what dimension the mean is being taken over.
For the provision of hourly means, one would enter a reference to mean in the statisticalFunction attribute and then provide a duration of an hour in the aggregationTimePeriod attribute. StatisticalMeasures can be aggregated over time, spatial dimensions or any other defined aggregation type. An example of a spatial aggregation would be maximum per km2.
Note that a StatisticalMeasure may be derived from another StatisticalMeasure. For example Mean Monthly Maximum Temperature derived from Mean Daily Maximum Temperature.
Constraints
In order to provide other constraints on ObservableProperties, the type Constraint has been created and can be associated with an ObservableProperty. Constraint types have been provided for scalar, range and category constraints, as well as a generic OtherConstraint data type. The following list provides examples for the constraint types defined:
Scalar Constraint: A numerical scalar constraint on some property e.g. length >= 1m
Range Constraint: A numerical range constraint on some property e.g. wavelength >=300nm and wavelength <=600nm. To be used when data is observed in particular bands or groupings based on a numerical quantity.
Category Constraint: A constraint based on some qualifying category. e.g. colour = 'Red'. The value ('Red') of the constraint ('colour') can be any string, although it may be desirable to constrain this in particular application domains.
Other Constraint: Any other constraint type not easily expressed using the other Constraint types.This type may be specialised or the simple description attribute may be used to provide a free text description of the constraint.
CompositeObservableProperty
Usually, when performing multiple observations on one featureOfInterest, one provides a separate ObservableProperty element for each Phenomenon being observed. However, in certain cases where either a) there is a strong link between the Phenomena or b) the multiple phenomena are clearly observed as part of the same Observation, these Phenomena may be provided together in one Observation. In this case a CompositeObservableProperty can be defined that groups together multiple Phenomena (ObservableProperty) into one CompositeObservableProperty element.
An example of a strongly linked pair of Phenomena is wind speed and wind direction.
Feature catalogue
Feature catalogue metadata
Application SchemaINSPIRE Application Schema Observable PropertiesVersion number2.0Types defined in the feature catalogue
TypePackageStereotypes HYPERLINK "" \l "categoryconstraint" CategoryConstraintObservable PropertiesdataType HYPERLINK "" \l "constraint" ConstraintObservable PropertiesdataType HYPERLINK "" \l "otherconstraint" OtherConstraintObservable PropertiesdataType HYPERLINK "" \l "rangebounds" RangeBoundsObservable PropertiesdataType HYPERLINK "" \l "rangeconstraint" RangeConstraintObservable PropertiesdataType HYPERLINK "" \l "scalarconstraint" ScalarConstraintObservable PropertiesdataTypeData types
CategoryConstraint
CategoryConstraint
Name:
Category Constraint
Subtype of:
Constraint
Definition:
A constraint based on some qualifying category. e..g colour = 'Red'.
Description:
A constraint based on some qualifying category. e..g colour = 'Red'.The value ('Red') of the constraint ('colour') can be any string, although it may be desirable to constrain this in particular application domains.
Stereotypes:
dataType
Attribute: comparison
Name:
comparison
Value type:
ComparisonOperatorValue
Definition:
A comparison operator. In the case of a category constraint it should be 'equalTo' or 'notEqualTo'.
Multiplicity:
1
Attribute: value
Name:
value
Value type:
CharacterString
Definition:
The value of the property that is constrained e.g. 'blue' (if the constrained property is colour)
Multiplicity:
1..*
Constraint
Constraint
Name:
Constraint
Definition:
A constraint on some property e.g. wavelength = 200nm.
Description:
A constraint on some property e.g. wavelength = 200nm. This property is typically not the same property as the base phenomenon of the observed property. e.g. the observed property has a base phenomenon 'radiance'. a constraint is added to say 'wavelength = 200nm'So the overall ObservableProperty which is represented is 'radiance where wavelength = 200nm'The Constraint class is specialised into several specific classes covering Scalar, Range and Categorical constraints
Stereotypes:
dataType
Attribute: constrainedProperty
Name:
constrainedProperty
Value type:
PhenomenonTypeValue
Definition:
The property being constrained. e.g. 'colour' if the constraint is 'colour = blue'
Multiplicity:
0..1
Attribute: label
Name:
description
Value type:
CharacterString
Definition:
A human readable title for the constraint as a whole
Multiplicity:
0..1
OtherConstraint
OtherConstraint
Name:
Other Constraint
Subtype of:
Constraint
Definition:
A constraint, not modelled in a structured way, but may be described using the freetext 'description' attribute.
Stereotypes:
dataType
Attribute: description
Name:
description
Value type:
CharacterString
Definition:
A description of the constraint.
Multiplicity:
1
RangeBounds
RangeBounds
Name:
Range Bounds
Definition:
The start and end bounding values of a numerical range (e.g. start >=50, end <=99)
Stereotypes:
dataType
Attribute: startComparison
Name:
startComparison
Value type:
ComparisonOperatorValue
Definition:
The comparator used for the lower range limit (e.g. greaterThanOrEqualTo)
Multiplicity:
1
Attribute: rangeStart
Name:
rangeStart
Value type:
Real
Definition:
The lower limit of the range.
Multiplicity:
1
Attribute: endComparison
Name:
endComparison
Value type:
ComparisonOperatorValue
Definition:
The comparator used for the upper range limit (e.g. lessThan)
Multiplicity:
1
Attribute: rangeEnd
Name:
rangeEnd
Value type:
Real
Definition:
The upper limit of the range.
Multiplicity:
1
RangeConstraint
RangeConstraint
Name:
Range Constraint
Subtype of:
Constraint
Definition:
A numerical range constraint on some property e.g. wavelength >=300nm and wavelength <=600nm
Description:
A numerical range constraint on some property e.g. wavelength >=300nm and wavelength <=600nme.g. To be used when data is observed in particular bands or groupings based on a numerical quantity.
Stereotypes:
dataType
Attribute: value
Name:
value
Value type:
RangeBounds
Definition:
The numerical value range of the property that is constrained
Multiplicity:
1..*
Attribute: uom
Name:
uom
Value type:
UnitOfMeasure
Definition:
Units of measure used in the constraint
Multiplicity:
0..1
ScalarConstraint
ScalarConstraint
Name:
Scalar Constraint
Subtype of:
Constraint
Definition:
A numerical scalar constraint on some property e.g. length >= 1m
Description:
A scalar constraint on some property e.g. length >= 1m
Stereotypes:
dataType
Attribute: value
Name:
value
Value type:
Real
Definition:
The numerical value of the property that is constrained
Multiplicity:
1..*
Attribute: comparison
Name:
comparison
Value type:
ComparisonOperatorValue
Definition:
The comparator to be used in the constraint e.g. greaterThan
Multiplicity:
1
Attribute: uom
Name:
uom
Value type:
UnitOfMeasure
Definition:
Units of measure used in the constraint
Multiplicity:
0..1
StatisticalMeasure
StatisticalMeasure
Name:
Statistical Measure
Definition:
A descripton of some statistical measure e.g. "daily maximum"
Description:
A descripton of some statistical measure e.g. "daily maximum"The measure is usually some function over some time (e.g. an hour, a day) or space (e.g. a length, area or volume)Other aggregation types can be supported via the 'otherAggregation' extension point.
Stereotypes:
type
Attribute: label
Name:
label
Value type:
CharacterString
Definition:
A human readable title for the statistical measure
Multiplicity:
0..1
Attribute: statisticalFunction
Name:
statisticalFunction
Value type:
StatisticalFunctionTypeValue
Definition:
A statistical function e.g. (mean)
Multiplicity:
0..1
Attribute: aggregationTimePeriod
Name:
aggregationTimePeriod
Value type:
TM_Duration
Definition:
A temporal range over which a statistic is calculated. e.g. A day, An hour.
Multiplicity:
0..1
Attribute: aggregationLength
Name:
aggregationLength
Value type:
Length
Definition:
A one dimensional spatial range over which a statistic is calculated for example 1 metre.
Multiplicity:
0..1
Attribute: aggregationArea
Name:
aggregationArea
Value type:
Area
Definition:
A two dimensional spatial range over which a statistic is calculated for example 1 square metre
Multiplicity:
0..1
Attribute: aggregationVolume
Name:
aggregationVolume
Value type:
Volume
Definition:
A three dimensional spatial range over which a statistic is calculated for example 1 cubic metre
Multiplicity:
0..1
Attribute: otherAggregation
Name:
otherAggregation
Value type:
Any
Definition:
Any other type of aggregation.
Multiplicity:
0..1
Association role: derivedFrom
Name:
derived from
Value type:
StatisticalMeasure
Definition:
One statistical measure may be derived from another. e.g. Monthly Maximum temperatures may be derived from Daily Mean temperatures.
Multiplicity:
0..1
Enumerations
ComparisonOperatorValue
ComparisonOperatorValue
Name:
ComparisonOperatorValue
Definition:
An enumeration of comparison operators (e.g. greater than)
URI:
Value: equalTo
Definition:
Exactly equal to
Value: notEqualTo
Definition:
Not exactly equal to
Value: lessThan
Definition:
Less than
Value: greaterThan
Definition:
Greater Than
Value: lessThanOrEqualTo
Definition:
Less than or exactly equal to
Value: greaterThanOrEqualTo
Definition:
Greater than or exactly equal to
Code lists
PhenomenonTypeValue
PhenomenonTypeValue
Name:
Phenomenon Type Value
Definition:
A code list of phenomena (e.g. temperature, wind speed)
Description:
A code list of phenomena. This code list itself is an empty placeholder and should be extended and specified for any thematic domain.
Extensibility:
open
Identifier:
Values:
The allowed values for this code list comprise the values of the following code lists and additional values at any level defined by data providers:
CFStandardNamesValue (INSPIRE Generic Conceptual Model, version 3.4 [DS-D2.5])
ProfileElementParameterNameValue (INSPIRE Data specification on Soil [DS-D2.8.III.3])
SoilDerivedObjectParameterNameValue (INSPIRE Data specification on Soil [DS-D2.8.III.3])
SoilProfileParameterNameValue (INSPIRE Data specification on Soil [DS-D2.8.III.3])
SoilSiteParameterNameValue (INSPIRE Data specification on Soil [DS-D2.8.III.3])
EU_AirQualityReferenceComponentValue (INSPIRE Data specification on Atmospheric Conditions and Meteorological Geographical Features [DS-D2.8.III.13-14])
BODC_P01ParameterUsageValue (INSPIRE Data specification on Oceanographic Geographical Features [DS-D2.8.III.15])
StatisticalFunctionTypeValue
StatisticalFunctionTypeValue
Name:
Statistical Function Type Value
Definition:
A code list of statistical functions (e.g. maximum, minimum, mean)
Description:
A code list of statistical functions. This code list itself is an empty placeholder and should be extended and specified for any thematic domain.
Extensibility:
any
Identifier:
Values:
The allowed values for this code list comprise any values defined by data providers.
Imported types (informative)
This section lists definitions for feature types, data types, enumerations and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.
Any
Any
Package:
Records and Class Metadata
Reference:
Geographic information -- Conceptual schema language [ISO/TS 19103:2005]
Area
Area
Package:
Units of Measure
Reference:
Geographic information -- Conceptual schema language [ISO/TS 19103:2005]
BODC_P01ParameterUsageValue
BODC_P01ParameterUsageValue
Package:
Oceanographic Geographical Features
Reference:
INSPIRE Data specification on Oceanographic Geographical Features [DS-D2.8.III.15]
Definition:
Definitions of phenomena observed in oceanography.
CFStandardNamesValue
CFStandardNamesValue
Package:
NOT FOUND CFStandardNamesValue
CharacterString
CharacterString
Package:
Text
Reference:
Geographic information -- Conceptual schema language [ISO/TS 19103:2005]
EU_AirQualityReferenceComponentValue
EU_AirQualityReferenceComponentValue
Package:
Atmospheric Conditions and Meteorological Geographical Features
Reference:
INSPIRE Data specification on Atmospheric Conditions and Meteorological Geographical Features [DS-D2.8.III.13-14]
Definition:
Definitions of phenomena regarding air quality in the context of reporting under Union legislation.
Length
Length
Package:
Units of Measure
Reference:
Geographic information -- Conceptual schema language [ISO/TS 19103:2005]
ProfileElementParameterNameValue
ProfileElementParameterNameValue
Package:
Soil
Reference:
INSPIRE Data specification on Soil [DS-D2.8.III.3]
Definition:
list of properties that can be observed to characterize the profile element. The allowed values for this code list comprise a number of pre-defined values and narrower values defined by data providers. This code list is hierarchical.
Description:
Basically these parameters can be divided in several major groups like:
Chemical parameters
Physical parameters
Biological parameters
Real
Real
Package:
Numerics
Reference:
Geographic information -- Conceptual schema language [ISO/TS 19103:2005]
SoilDerivedObjectParameterNameValue
SoilDerivedObjectParameterNameValue
Package:
Soil
Reference:
INSPIRE Data specification on Soil [DS-D2.8.III.3]
Definition:
list of soil related properties that can be derived from soil and other data. The allowed values for this code list comprise a number of pre-defined values and narrower values defined by data providers. This code list is hierarchical.
Description:
Basically these parameters can be divided in several major groups like:
Chemical parameters
Physical parameters
Biological parameters
SoilProfileParameterNameValue
SoilProfileParameterNameValue
Package:
Soil
Reference:
INSPIRE Data specification on Soil [DS-D2.8.III.3]
Definition:
list of properties that can be observed to characterize the soil profile. The allowed values for this code list comprise a number of pre-defined values and narrower values defined by data providers. This code list is hierarchical.
Description:
Basically these parameters can be divided in several major groups like:
Chemical parameters
Physical parameters
Biological parameters
SoilSiteParameterNameValue
SoilSiteParameterNameValue
Package:
Soil
Reference:
INSPIRE Data specification on Soil [DS-D2.8.III.3]
Definition:
List of properties that can be observed to characterize the soil site. The allowed values for this code list comprise a number of pre-defined values and narrower values defined by data providers.
Description:
Basically these parameters can be divided in several major groups like:
Chemical parameters
Physical parameters
Biological parameters
TM_Duration
TM_Duration
Package:
Temporal Objects
Reference:
Geographic information -- Temporal schema [ISO 19108:2002/Cor 1:2006]
UnitOfMeasure
UnitOfMeasure (abstract)
Package:
Units of Measure
Reference:
Geographic information -- Conceptual schema language [ISO/TS 19103:2005]
Volume
Volume
Package:
Units of Measure
Reference:
Geographic information -- Conceptual schema language [ISO/TS 19103:2005]
Annex J (informative): Discussion paper on Out-Of-Band Results
Discussion Paper on
Harmonising the delivery of
gridded data as OM_Observation result
in the INSPIRE Data Specifications
based on the Observations & Measurementsdata model
Version 1.3
21st February 2012
Ilkka Rinne / Spatineo Inc.
on behalf of the Finnish Meteorological Institute
ilkka.rinne@spatineo.com
With review and contributions by
Dominic Lowe / British Atmospheric Data Centre, UK
Science & Technology Facilities Council
dominic.lowe@stfc.ac.uk
Introduction
INSPIRE Data Specification themes like Atmospheric Conditions and Meteorological Geographical Features as well as in Oceanographic Geographical Features have come to a conclusion that for large grid coverage type INSPIRE data sets of those themes, it must be possible to link from GML encoded OM_Observation instances to results of those Observations encoded in external resources encoded using binary data formats.
The version 2.9 of the INSPIRE AC-MF Data Specification summarises the out-of-band result delivery needs as follows:
Due to the very large volumes of items in many AC-MF data sets, the encoding of the the grid coverage result data of these data sets is typically stored in highly optimised binary file formats. Encoding of such data in textual form, like GML, would in most case result in file sizes impractical to produce, transfer over the network or consume by the users.
This kind of linking either the entire value of the GML encoded OM_Observations result properties, or parts of them, to external files providing the actual values, is called here out-of-band result delivery. On the other hand providing the entire OM_Observation, including the value of the result property, using the same encoding, is called here in-band result delivery.
The purpose of this discussion paper is to provide background information on the practical issues for delivering spatial objects based on the data model of the Observations & Measurements (ISO 19156:2011) standard, and listing some in-band and out-of-band techniques for delivering O&M Observations with the grid coverage type results using INSPIRE Download Service. This paper is intended to provide additional information to the delivery and encoding sections of the INSPIRE technical guidance document D2.9 Guidelines for the use of Observations & Measurements and Sensor Web Enablement-related standards in INSPIRE Annex II and III data specification development.
Binding existing grid coverage data sets to OM_Observations
As defined in the Implementing Rules of INSPIRE Download Services, there are two possibilities for implementing an INSPIRE Download Service: offering pre-defined data sets for download or providing a "direct access" download service with query capabilities. In many cases the data sets in the INSPIRE Themes using the O&M based data models are collections of feature instances of class OM_Observation or classes inherited from OM_Observation.
Collections of the OM_Observations served using an INSPIRE Download Service can be either pre-defined using semantic grouping (like all measurement events with all measured properties from a single meteorological observation station within one day), or be created ad-hoc as a result of the given selection criteria for the Get Spatial Objects function of a direct-access Download Service. Its recommended that the encoding and packaging of the OM_Observation instances for both direct access and non-direct access INSPIRE Download Services should as similar as possible. For the end-users perspective accessing an non-direct access Download Service should be like accessing a direct access Download Service with a pre-defined query.
The central idea of the INSPIRE Directive must be kept in mind: the INSPIRE Web Services exist for easy and harmonised access for geospatial information across both national and thematic borders within the EU. Thus the data sets must be harmonised as much as possible within the Data Specifications for each INSPIRE theme. Further considerable financial savings can be made if the data delivery can also be harmonised between scientifically closely related INSPIRE themes like the Atmospheric Conditions & Meteorological Geographical Features and the Oceanographic Geographical Features. The O&M model is very good basis for such harmonisation within the INSPIRE themes dealing with scientific measurement and numerical prediction data sets.
The data models in O&M based INSPIRE themes take an event based perspective on the provided data sets: The main actors in the play are temporal Observation events, and a coverage data is only one of the properties of the Observation instance. In addition to this result property, the properties for the feature of interest, the observed property, the used procedure and other metadata are provided with each OM_Observation instance. On the other hand most existing binary data formats for storing scientific data sets are (grid) coverage oriented: they are designed to efficiently store and access gridded coverage data, and currently provide only limited means of encoding the other OM_Observation properties within their internal data structure. For this reason most of the currently existing scientific binary data formats do not fit very well to encoding the the O&M based INSPIRE data sets using the in-band result delivery. Even if technically possible, modifying large sets of existing data files by embedding the missing OM_Observation properties would be costly or at least impractical.
Returning OM_Observation results in-band or out-of-band
There are several different technical options for encoding the OM_Observation grid valued data. The most straight-forward options are using in-band result delivery methods with GML encoding. This option is also closest to the existing delivery mechanisms for INSPIRE Annex I themes. For large grid coverage data sets the practical limits of the XML encoding considering data transfer and data access efficiency are soon reached with these options.
The other end of the spectrum would be to use pure binary O&M in-band encodings, which would simplify the life of those users capable of decoding those formats, but on the other hand be completely inaccessible for the users only capable of understanding GML encoded data. There is ongoing work at the OGC of defining the CF-NetCDF format and data model for encoding O&M Observation data, but generally such binary data formats are not common.
The out-of-band result delivery can be seen as a middle way approach to this problem: all users capable of understanding GML encoded OM_Observations are able to get a good deal of information for deciding whether the data set is interesting enough for their use cases: the feature of interest and the sampling feature describe the geographical location of the target of the Observation, the observed property gives information on what aspects of the target have been observed, the process and the metadata can be used for finding out the details of the Observation event, and the phenomenonTime property of the OM_Observation places the event at a point in the time axis. After this initial evaluation step the users may decide to proceed with the possibly resource and time consuming operation of downloading the separately available result grid coverage.
This section presents some of the options for encoding the value of grid coverage valued result properties of OM_Observations. Both in-band and out-of-band options are included as the most feasible choice depends on the quality and the quantity of the delivered data sets.
For each example, only the om:result element of the OM_Observation instance if provided for brevity.
Option 1 (in-band): Embed the result using GML Coverage encoding
In this case a gmlcov:ReferenceableGridCoverage is used, but a gml:RectifiedGridCoverage could also be appropriate. The encoding shows an x,y,z t grid coverage
0 0 0
180 359 365
x y t
0 0 0
1 0 0
-90.0 -89.0 -88.0..... 88.0 89.0 90
x y
Linear
0 1 0
-180.0 -179.0 -178.0 .178.0 179.0 180.0
x y
Linear
0 0 1
0 1 2 3 4 5 . 362 363 364
t
Linear
21.2 21.3 20.1 19.3 18.4 21.3 ... etc
For several OM_Observation instances with the same domainSet and rangeType (like periodical new observations), the recurring parts can be re-used using XLink syntax. This makes the om:result element much more compact:
21.2 21.3 20.1 19.3 18.4 21.3 ... etc
Pros:
Uses OGC standard coverage encodings.
The domain, and rangeType are fully encoded.age encodings.
The domain, and rangeType are fully encoded.
Cons:
Encoding the rangeSet inline is not suitable for very large datasets.
Option 2: (out-of-band) XLink the entire om:result
The idea is to use the GML way of linking to an external resource: the XLink.
Example:
Pros:
Very simple to implement.
Cons:
No way to define MIME type or the size of the remote file in advance, client must do "trial-and-error" by making a HTTP HEAD request first for example.
Offers practically no information about the result (e.g. the domain of the coverage), clients unable to represent a geospatial placeholder area or point before downloading the entire binary file.
Option 3 (out-of-band): Define an INSPIRE specific referencing out-of-band result type
This option is semantically just an extended version of the XLink option (3), but with possibility to properly define the service interfaces.
Example:
HYPERLINK "http://data.access.server.org/wcs" http://data.access.server.org/wcs
HYPERLINK "http://www.opengis.net/spec/WCS/2.0" http://www.opengis.net/spec/WCS/2.0
cv-12345
GetCoverage
ftp://ftp.access.server.org
FTP
/pre-defined/cv-12345.nc
RETR
HYPERLINK "http://web.access.server.org" http://web.access.server.org
HTTP
/pre-defined/cv-12345.nc
GET
Pros:
Can be used with no model conflicts for those OM_Observation types that do not restrict the result type.
Possibility to give alternative access methods for a result coverage.
Cons:
Does not comply to the current version of SamplingCoverageObservation (or the EnvironmentalSamplingObservation or what ever it will be called in the final INSPIRE OM model): the om:result OutOfBandResult is not of type DiscreteCoverage, would need to be changed to allow either a DiscreteCoverage or an OutOfBandResult
Mixes the the model content and the network service semantics, but on the other hand, so does any of the proposed out-of-band options.
INSPIRE specific solution, no existing community support.
Offers very little information about the result (e.g. the domain of the coverage).
Option 4 (out-of-band): Link to an external rangeSet using gml:File
This option tries to follow the existing methods in GML for referencing external resources (gml:File), but it also tries to slip in the possibility for knowledgeable clients to use alternative methods for accessing the coverage range data or a subset of it.
Example:
0 0 0
180 359 365
x y t
0 0 0
1 0 0
-90.0 -89.0 -88.0..... 88.0 89.0 90
x y
Linear
0 1 0
-180.0 -179.0 -178.0 .178.0 179.0 180.0
x y
Linear
0 0 1
0 1 2 3 4 5 . 362 363 364
t
Linear
air_temperature
http://web.access.server.org/pre-defined/cv-12345.nc
1.6
application/x-netcdf
The ExternalStorageDescriptor element placed within the gml:rangeParameters element is almost identical to the CSMLStorageDescriptor element. The abstract FileExtractType is however simplified for the out-of-band use by leaving out the mandatory arraySize and fileName properties, as well as the optional uom and numericType properties used for defining embedded numeric data array structures inherited in CSML from the abstract ArrayDescriptorType. The NetCDFExtract element in the example above tells the client that only the air_temperature variable values within the referred NetCDF file form the rangeSet of this coverage.
Besides the NetCDFExtract, there is also a GRIBExtract element defined in CSML. This is also copied to the XML schema of Annex I.
As with option 1, several OM_Observation instances with the same domainSet and rangeType (like periodical new observations), could re-use these elements for more compact encoding:
air_temperature
http://web.access.server.org/pre-defined/cv-12345.nc
1.6
application/x-netcdf
Pros:
We dont break the current model: om:result for the SamplingGridCoverage is of type DiscreteCoverage.
Follows the GML standard GML coverage encoding model.
Even if the clients cannot understand the rangeParameters, they are able to access the entire binary file using the fileReference and mimeType properties (provided that they understand the gml:File).
Cons:
The external binary files typically contain the entire coverage description, not just the rangeSet. Actually we should probably point inside the binary files in gml:File to access the rangeSet directly. This kind of internal references are often file format specific, if they exist at all.
Possibly slight misuse of gml:rangeParameters: the GML schema say it should be used for "semantics of the range set".
Option 5 (out-of-band): gml:File with AlternativeEncodings
This is option is very similar to the option 4, but it adds possibility to provide alternative access methods to retrieve the coverage data. The elements used for this are the same as in option 3, but this time they are provided within the gml:rangeParameters.
Example:
http://data.access.server.org/wcs
http://www.opengis.net/spec/WCS/2.0
cv-12345
GetCoverage
ftp://ftp.access.server.org
FTP
/pre-defined/cv-12345.nc
RETR
http://web.access.server.org
HTTP
/pre-defined/cv-12345.nc
GET+NetCDFExtract
air_temperature
http://web.access.server.org/pre-defined/cv-12345.nc
1.6
application/x-netcdf
Pros:
Follows standard GML coverage encoding
Possibility to give alternative access methods for a result coverage, including service interfaces for returning only part of the entire coverage based on users' requirements.
Cons:
A bit of a hack to provide references to alternative access methods inside the gml:File element: those access methods should really be one level up, but there does not seem to be a an appropriate extension point in GML at that level.
Option 6 (out-of-band): Using SWE Common DataStream & BinaryEncoding
The SWE Common also has means of referring to external, binary encoded data arrays. In the following example the value of the om:result is a swe:DataStream representing a 3000 by 3000 pixel raster image, with colors of each pixel encoded using one unsigned byte for each three components: red, green and blue:
Example:
3000
3000
Radiance measured on band1 usually assigned to red channel
0
255
Radiance measured on band2 usually assigned to green channel
Radiance measured on band3 usually assigned to blue channel
Pros:
SWE Common is an OGC standard and widely used, no need to create an INSPIRE specific solution.
The structure of the referenced data array is well defined in the GML encoding, so the clients know what to expect when downloading the binary encoded part.
Cons:
The om:result does not define a coverage: there is not explicit definition of the spatial and/or temporal locations of the grid points. The result is just an array of data cells. The clients are not able to map the values to a geospatial area and/or on the time axis without added information.
Option 7 CSML Pattern
TBD
XML Schema definitions for the proposed out-of-band result types
.
Annex J (informative): Examples
Authoritative examples will be provided on the webon inspire.europa... subsite ( not ef/om cluster)
SWE Common Results
The following section shows how a single result can be provided via the use of the result types provided by OGC SWE Common. The first example provides a measurement as the result (concentration of ozone in g/m):
2008-09-01T02:00:00+0200
2008-09-01T05:00:00+0200
28.614536
The second example provides a single result; however, in this example the result is not coming from a measurement, but is the result of an observation determining the species of an individual tree.
This biodiversity example illustrates the identification of an individual of a specific species. The featureOfInterest will again be defined as a species occurrence point as introduced in chapter REF _Ref453592201 \r \h 6.2.2.1 REF _Ref453592201 \h PointObservation
The featureOfInterest cannot be modelled as an occurrence of a specific species as this identification is actually an observation on the individual; at a later time it may be determined that this individual is actually of a different species, which can then be provided as an updated observation.
A swe:Category type is used for this type of categorization and additionally provide the codespace this entry was taken from, as well as a human readable description in addition to the GUID uniquely identifying this species within the codespace:
2008-09-01T02:00:00+0200
2008-09-01T05:00:00+0200
'http://someURL'
49.683748 4.715314
Fagus sylvatica L.
68C1AC04-391B-49DF-990A-3DD6A75D05B6
The following section shows how a time series can be provided via the use of the result types provided by OGC SWE Common. In this example the observation pertains to hourly ozone measurements; the time series provided has been truncated to 3 values for brevity:
2008-09-01T02:00:00+0200
2008-09-01T05:00:00+0200
2008-09-01T05:00:00+0200
3
2008-09-01T02:00:00+0200,urn:ogc:object:feature:ait:09:AT0098A,28.614536@@2008-09-01T03:00:00+0200,urn:ogc:object:feature:ait:09:AT0098A,29.157038@@2008-09-01T05:00:00+0200,urn:ogc:object:feature:ait:09:AT0098A,28.495537@@
GML Coverage Results
The following section shows how a GML Coverage can be provided as an Observation result:
2008-09-01T02:00:00+0200
2008-09-01T05:00:00+0200
2008-09-01T05:00:00+0200
654543 76674
654553 76634
654573 76654
654593 76624
654533 76614
stn-001 980000 980000 980000 0 0
stn-002 980000 980000 980000 0 0
stn-003 980000 980000 980000 0 0
stn-004 980000 980000 980000 0 0
stn-005 980000 980000 980000 0 0
HYPERLINK "http://sweet.jpl.nasa.gov/" http://sweet.jpl.nasa.gov/
This pattern was modelled on the approach taken in Climate Science Modelling Language version 3 (OGC Pending Docs 11_021) which extends ISO 19156.
PAGE
INSPIREReference: D2.9 v3.0 draft4MIG sub-group MIWP-7aGuidelines for the use of Observations & Measurements and Sensor Web Enablement-related standards in INSPIRE2016-04-08Page PAGE \* ROMAN \* MERGEFORMAT VI
INSPIREReference: INSPIRE_ DataSpecification_HY_v2.0.pdfTWG-HYData Specification on Hydrography2008-12-18Page PAGE \* ROMAN \* MERGEFORMAT XCII
INSPIREReference: D2.9 v3.0 draft4MIG sub-group MIWP-7aGuidelines for the use of Observations & Measurements and Sensor Web Enablement-related standards in INSPIRE2016-04-08Page PAGE 40
An Observation is an action whose result is an estimate of the value of some property of the feature-of-interest, at a specific point in time, obtained using a specified procedure
after Cox 2008
Example:
A SamplingFeature > B C F G - / 7 K L M N S Y ] ^ _ g p
r
~
úÇyuÇuqfÇÇuÇÇÇ hA2 h/ B*ph h h h$ h hi h/ hA2 h/ 5
h/ 0J
hW 0J hi h<