MIWP-7b: WCS-based download services - Discussion #2680 · MIWP-7b: WCS-based download services - Discussion #2680 ... CEMT Class Condition of Water Facility Fairway Area Ferry Crossing

MIWP-7b: WCS-based download services - Discussion #2680Requirements for download services with respect Spatial Object Types specified in Regulation (EU) No 1089/201001 Feb 2016 05:05 pm - James Passmore

Status: NewPriority: NormalAssignee:Description

For a download service (DLS) that provides direct access to one or more spatial data sets, there is a requirement to provide in additionto the operations specified in the INSPIRE Network Services regulation (INS NS) Annex IV part A, two other operations ~ Get SpatialObject and Describe Spatial Object Type.

Let's take Describe Spatial Object Type, its role is return the description of the Spatial Object types.

In the request you specify a Spatial Object Type parameter which contains thelanguage-neutral name of the Spatial Object Typeas specified in Regulation (EU) No 1089/2010. (INS SDS)

INS SDS tells us

Article 4Types for the Exchange and Classification of Spatial Objects1. Member States shall use the spatial object types and associated data types, enumerations and code lists defined in Annex II for theexchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC.(INSPIRE Directive)

...

If we look at the Spatial Object Types that are defined in INS SDS Annex II

Spatial Object TypesGEOGRAPHICAL NAMES Named PlaceADMINISTRATIVE UNITS Administrative Boundary Administrative Unit Condominium NUTS RegionADDRESSES Address Address Area Name Address Component Administrative Unit Name Postal Descriptor Thoroughfare NameCADASTRAL PARCELS Basic Property Unit Cadastral Boundary Cadastral Parcel Cadastral ZoningTRANSPORT NETWORKS Common Transport Elements Access Restriction Condition Of Facility Maintenance Authority Marker Post

29 Apr 2020 1/16

Owner Authority Restriction for Vehicles Traffic Flow Direction Transport Area Transport Link Transport Link Sequence Transport Link Set Transport Network Transport Node Transport Object Transport Point Transport Property Vertical PositionAir Transport Network Aerodrome Area Aerodrome Category Aerodrome Node Aerodrome Type Air Link Air Link Sequence Air Node Air Route Air Route Link Airspace Area Apron Area Condition of Air Facility Designated Point Element Length Element Width Field Elevation Instrument Approach

Procedure Lower Altitude Limit Navaid Procedure Link Runway Area Runway Centreline Point Standard Instrument Arrival Standard Instrument Departure Surface Composition Taxiway Area Touch Down Lift Off Area Upper Altitude Limit Use RestrictionCable Transport Network Cableway Link Cableway Link Sequence Cableway Link Set Cableway NodeRailway Transport Network Design Speed Nominal Track Gauge Number of Tracks Railway Area Railway Electrification Railway Line

29 Apr 2020 2/16

Railway Link Railway Link Sequence Railway Node Railway Station Area Railway Station Code Railway Station Node Railway Type Railway Use Railway Yard Area Railway Yard NodeRoad Transport Network E-Road Form of Way Functional Road Class Number of Lanes Road Road Area Road Link Road Link Sequence Road Name Road Node Road Service Area Road Service Type Road Surface Category Road Width Speed Limit Vehicle Traffic AreaWater Transport Network Beacon Buoy CEMT Class Condition of Water Facility Fairway Area Ferry Crossing Ferry Use Inland Waterway Marine Waterway Port Area Port Node Restriction for Water Vehicles Traffic Separation Scheme Traffic Separation Scheme

Area Traffic Separation Scheme

Crossing Traffic Separation Scheme

Lane Traffic Separation Scheme

Roundabout Traffic Separation Scheme

Separator Water Link Sequence Water Node Water Traffic Flow Direction Waterway

29 Apr 2020 3/16

Waterway Link Waterway NodeHYDROGRAPHY Hydro - base Hydro ObjectHydro - Network Hydro Node Watercourse Link Watercourse Link Sequence Watercourse Separated

CrossingHydro - Physical Waters Crossing Dam or Weir Drainage Basin Embankment Falls Fluvial Point Ford Hydro Point of Interest Hydro Power Plant Inundated Land Land-Water Boundary Lock Man-made Object Ocean Region Pipe Pumping Station Rapids River Basin Shore Shoreline Construction Sluice Standing Water Surface Water Watercourse WetlandHydro - Reporting WFD Coastal Water WFD Ground Water Body WFD Lake WFD River WFD River or Lake WFD Surface Water Body WFD Transitional Water WFD Water BodyPROTECTED SITES Protected Site

and that's it

History#1 - 01 Feb 2016 05:44 pm - James Passmore

29 Apr 2020 4/16

The Spatial Data themes addressed in the above table that is GEOGRAPHICAL NAMES, ADMINISTRATIVE UNITS, ADDRESSES, CADASTRALPARCELS, TRANSPORT NETWORKS, HYDROGRAPHY, and PROTECTED SITES are the spatial data themes referred to in articles 6(A), 8(l) and9(A) of the INSPIRE directive and grouped collectively under Annex I of that directive.

But in this exercise of creating Technical Guidance (TG) for how to provide INSPIRE compliant DLS using WCS, we have not identified any Annex Ispatial data themes (and their data specifications) to be in scope, rather we have identified a subset of the Annex II and Annex III data themes asrequiring to provide coverages such as could be done through a WCS.

So it appears that it will be impossible to comply with this requirement, because none of our WCS services will have any of the Spatial Object Typesdefined in Annex II of the INS SDS.

Is that the correct reading?

Similarly for the Get Spatial Object operation, though there are other aspects to the (query) request, one of the requirements for the search criteria isthat it will allow a query on

all relevant key attributes and the relationship between Spatial Objects as set out in Regulation (EU) No 1089/2010;

Could we say that technically there are no relevant key attributes and relationships, so there is no conformance requirement here in that respect?

#2 - 02 Feb 2016 01:10 pm - James Passmore

The reference to No 1089/2010 also implies any subsequent amendments so checking if there have been any changes to the Spatial Object Typeslisted in subsequent amendments.

Amendments Summary[1] COMMISSION REGULATION (EU) No 102/2011 of 4 February 2011 amending Regulation (EU) No 1089/2010 implementing Directive 2007/2/ECof the European Parliament and of the Council as regards interoperability of spatial data sets and services.

Changes to Spatial Objects mentioned in the original regulation but, no new spatial object types defined.

[2] COMMISSION REGULATION (EU) No 1253/2013 of 21 October 2013 amending Regulation (EU) No 1089/2010 implementing Directive 2007/2/ECas regards interoperability of spatial data sets and services

Adds some Spatial Object Types of interest

[3] COMMISSION REGULATION (EU) No 1312/2014 of 10 December 2014 amending Regulation (EU) No 1089/2010 implementing Directive2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data services

No changes to any Spatial Object Types

29 Apr 2020 5/16

Additional Spatial Object Types defined in [2] above

Spatial Object TypesCOVERAGE MODELPackages Spatial Object TypeCoverages (Base) CoverageCoverages (Domain And Range) Coverage (Domain And Range

Representation) Rectified Grid Coverage Referenceable Grid CoverageOBSERVATIONS MODELPackages Spatial Object TypeObservation References Observation SetProcesses ProcessObservable Properties None cited for this packageSpecialised Observations Grid Observation Grid Series Observation Point Observation Point Observation Collection Multi Point Observation Point Time Series Observation Profile Observation Trajectory ObservationACTIVITY COMPLEX MODELPackages Spatial Object TypeActivity Complex Activity Complex


So where does that leave us with the Describe Spatial Object Type operation?

A WCS provides access to Spatial Objects that are of type 'coverage', 'Rectified Grid Coverage' etc, but there isn't a WCS operation that allows us todescribe the Spatial Object Types available.

Also if the requirement for a Direct Access DLS is that it must provide both a Describe Spatial Object Type operation and a Get Spatial Object operation, what are the implications here if we can't supply one of the operations, do we say that a WCS can't be an INSPIRE Direct Access DLS , ordo we ask for the INS NS regulation to be amended?

#4 - 03 Feb 2016 09:14 am - Michael Lutz

COMMISSION REGULATION (EU) No 1253/2013 actually lists quite a few theme-specific coverage types - see a quick search for "coverage" in thefeature concept dictionary (http://inspire.ec.europa.eu/featureconcept). To be double-checked if these are all the types extending the base coveragetypes.

These extended types (adding additional attributes to the "vanilla" coverage types) are the reason for asking for the TG in T2 - to describe how todeliver these types through the WCS.

Feature Concepts

Label Themes StatusSoil Theme Descriptive Coverage - Soil ValidSoil Theme Coverage - Soil Valid

29 Apr 2020 6/16

http://inspire.ec.europa.eu/featureconcept

Risk coverage - Natural risk zones ValidRenewable And Waste Potential Coverage - Energy resources ValidReferenceable Grid Coverage ValidRectified Grid Coverage ValidOrthoimage Coverage - Orthoimagery ValidObserved Event Coverage - Natural risk zones ValidLand Cover Grid Coverage - Land cover ValidHazard Coverage - Natural risk zones ValidExposed Element Coverage - Natural risk zones ValidElevation Grid Coverage - Elevation ValidCoverage (Domain And Range Representation)

Valid

Coverage Valid


Michael Lutz wrote:COMMISSION REGULATION (EU) No 1253/2013 actually lists quite a few theme-specific coverage types -

Thanks, missed that Artcle 4 para 1 was changed to include annexes III and IV

So continuing the complete listing of Spatial Object Types we have:

Annex III Spatial Object TypesELEVATIONElevation – Base Types No Spatial Object Type definedElevation – Grid Coverage Elevation Grid Coverage

(ElevationGridCoverage)Elevation – Vector Elements Elevation Vector Object Spot Elevation Contour Line Breakline Void Area Isolated AreaElevation – TIN Elevation TIN (ElevationTIN)LAND COVERLand Cover Nomenclature No Spatial Object Type definedLand Cover Vector Land Cover Data Set Land Cover UnitLand Cover Raster Land Cover Grid Coverage

(LandCoverGridCoverage)ORTHOIMAGERY Orthoimage Coverage

(OrthoimageCoverage)

29 Apr 2020 7/16

Mosaic Element Single Mosaic Element Aggregated Mosaic ElementGEOLOGY Geology Anthropogenic Geomorphologic

Feature Borehole Fold Geologic Collection Geologic Event Geologic Feature Geologic Structure Geologic Unit Geomorphologic Feature Mapped Feature Mapped Interval Natural Geomorphologic Feature Shear Displacement StructureGeophysics Campaign Geophysical Measurement Geophysical Object Geophysical Object Set Geophysical Profile Geophysical Station Geophysical SwathHydrogeology Active Well Aquiclude Aquifer Aquifer System Aquitard Groundwater Body Hydrogeological Object Man-made Hydrogeological

Object Natural Hydrogeological Object Hydrogeological Unit

and in Annex IV we have:

Annex IV Spatial Object TypesSTATISTICAL UNITSStatistical Units Base Statistical UnitStatistical Units Vector Vector Statistical Unit Area Statistical Unit Statistical Tesselation EvolutionStatistical Units Grid Statistical Grid Cell Statistical GridBUILDINGSBuildings Base Abstract Construction

29 Apr 2020 8/16

Abstract Building Building Building PartBuildings 2D Building Building PartBuildings 3D Building Building PartSOIL Derived Soil Profile Observed Soil Profile Profile Element Soil Body Soil Derived Object Soil Horizon Soil Layer Soil Plot Soil Profile Soil Site Soil Theme Coverage Soil Theme Descriptive CoverageLAND USELand Use Nomenclature No Spatial Object Type is definedExisting land use Existing Land Use Data Set Existing Land Use ObjectGridded (existing) land use Existing Land Use GridSampled (existing) land use Existing Land Use Sample Sampled Existing Land Use Data

SetPlanned land use Official Documentation Spatial Plan Supplementary Regulation Zoning ElementHUMAN HEALTH AND SAFETY Health Statistical Data Biomarker Disease General Health Statistic Health Services Statistic Environmental Health

Determinant Measure Environmental Health

Determinant Statistical DataUTILITY AND GOVERNMENTAL SERVICESCommon Utility Network Elements Utility Network Utility Network Element Utility Link Set Utility Node Utility Node Container Appurtenance Cabinet Cable Duct Manhole

29 Apr 2020 9/16

Pipe Pole TowerElectricity Network Electricity CableOil-Gas-Chemicals Network Oil, Gas and Chemicals PipeSewer Network Sewer PipeThermal Network Thermal PipeWater Network Water PipeEnvironmental Management Facilities

Environmental Management Facility

Administrative And Social Governmental Services

Governmental Service

ENVIRONMENTAL MONITORING FACILITIES Abstract Monitoring Feature Abstract Monitoring Object Environmental Monitoring Activity Environmental Monitoring Facility Environmental Monitoring Network Environmental Monitoring

Programme Observing Capability Operational Activity PeriodPRODUCTION AND INDUSTRIAL FACILITIES Production Facility Production Installation Production Installation Part Production Site Production Plot Production BuildingAGRICULTURAL AND AQUACULTURE FACILITIES Holding SitePOPULATION DISTRIBUTION – DEMOGRAPHY Statistical DistributionAREA MANAGEMENT/RESTRICTION/REGULATION ZONES AND REPORTING UNITS Management Restriction Or

Regulation ZoneNATURAL RISK ZONES Abstract Exposed Element Abstract Hazard Area Abstract Observed Event Abstract Risk Zone Exposed Element Coverage Exposed Element Hazard Area Hazard Coverage Observed Event Coverage Observed Event Risk Coverage Risk Zone (RiskCoverage)ATMOSPHERIC CONDITIONS AND METEOROLOGICAL GEOGRAPHICAL FEATURES

29 Apr 2020 10/16

Atmospheric Conditions and Meteorological Geographical Features

No Spatial Object Types are defined

Specialised ObservationsProcessesObservable PropertiesOCEANOGRAPHIC GEOGRAPHICAL FEATURESOceanographic Geographical Features

No Spatial Object Types are defined

Specialised ObservationsProcessesObservable PropertiesObservation ReferencesSEA REGIONS Sea Area Sea Marine Circulation Zone Intertidal Area Shoreline Shore Segment Coastline Marine Contour Marine Layer Sea Bed Area Sea Surface AreaBIO-GEOGRAPHICAL REGIONS Bio-geographical RegionHABITATS AND BIOTOPES Habitats and Biotopes: HabitatSPECIES DISTRIBUTION Species Distribution Data Set Species Distribution UnitENERGY RESOURCESEnergy Resources Base No Spatial Object Types are

definedEnergy Resources Vector Vector Energy Resource Fossil Fuel Resource Renewable And Waste ResourceEnergy Resources Coverage

Renewable And Waste Potential Coverage(RenewableAndWastePotentialCoverage)MINERAL RESOURCESMineral Resources Earth Resource Mineral Occurrence Commodity Exploration Activity Mining Feature Mining Feature Occurrence Mine

29 Apr 2020 11/16

Mining ActivityGeology MappedFeature

#6 - 03 Feb 2016 02:26 pm - Michael Lutz

Hi James,

I don't quite understand why you want to list all the spatial object types included in the data interoperability IR. I think we should focus on thecoverage-related ones - see my extract from the FCD:

- Soil Theme Descriptive Coverage - Soil Theme Coverage - Risk coverage - Renewable And Waste Potential Coverage - Referenceable Grid Coverage - Rectified Grid Coverage - Orthoimage Coverage - Observed Event Coverage - Land Cover Grid Coverage - Hazard Coverage - Exposed Element Coverage - Elevation Grid Coverage - Coverage (Domain And Range Representation)


So back to the spirit of the original question

Let's take Describe Spatial Object Type, its role is return the description of the Spatial Object types, and the requirements from INS NS tell us

In the request you specify a Spatial Object Type parameter which contains the language-neutral name of the Spatial Object Type as specified inRegulation (EU) No 1089/2010. (INS SDS) (aka INS ISDSS) ~ and (implicitly this also covers) Spatial Object Type as specified in amendments ofRegulation (EU) No 1089/2010.

The Describe Spatial Object type response parameter shall be the description of the spatial object type, in conformity with Regulation (EU) No1089/2010.

A pseudo request might look like:

http://my.wcs.service/ows?service=WCS&version=2.0.0&request=DescribeSpatialObjectType&typnename=RenewableAndWastePotentialCoverage&

In such a request the required response is a description of the RenewableAndWastePotentialCoverage spatial object type provided by the service. Theresponse is not a coverage of type RenewableAndWastePotentialCoverage

or a pseudo request might look like:

29 Apr 2020 12/16

http://my.wcs.service/ows

http://my.wcs.service/ows?service=WCS&version=2.0.0&request=DescribeSpatialObjectType&

In such a request the required response is a description of the ALL spatial object types provided by the service. The response is not a coverage of anytype.

As I understand it the purpose of such an operation is to lay the foundation for a Get Spatial Object operation, that is, first you discover what SpatialObject types are available and what properties are supported/included, then you can construct a (search) query using those object types andproperties.

However at the moment there is no such WCS operation DescribeSpatialObjectType, (or anything that can act like this operation) though suchinformation might be extracted using some XPath expression of coverage metadata, so the original question still stands.

... what are the implications here if we can't supply one of the operations, do we say that a WCS can't be an INSPIRE Direct Access DLS or do weask for the INS NS regulation to be amended?


Michael Lutz wrote:Hi James, I don't quite understand why you want to list all the spatial object types included in the data interoperability IR. I think we should focus onthe coverage-related ones - see my extract from the FCD: Soil Theme Descriptive Coverage Soil Theme Coverage Risk coverage Renewable And Waste Potential Coverage Referenceable Grid Coverage Rectified Grid Coverage Orthoimage Coverage Observed EventCoverage Land Cover Grid Coverage Hazard Coverage Exposed Element Coverage Elevation Grid Coverage Coverage (Domain And RangeRepresentation)

I think others might potentially be in scope of being delivered through a WCS, so just doing it for completeness.


Michael Lutz wrote:These extended types (adding additional attributes to the "vanilla" coverage types) are the reason for asking for the TG in T2 - to describe how todeliver these types through the WCS.

So if these coverage types are strictly sub-types of coverages as defined by GMLCOV, there should be no reason why they can't be delivered througha WCS 2.0 and 2.1 when it comes in the near future. The WCS interface standard is not that prescriptive really in what can be delivered.

If we look at the mandatory operations as defined by INS NS (the so called pre-defined data set operations) they apply to ALL download services. Inthese operations the queries are partially or wholly constrained depending on the implementation, there is no requirement in these mandatoryoperations to discover anything about the Spatial Object Types supported, or any ability to query relationships of the coverages in respect to the theirspatial object type, those operations are conditional on there being an INSPIRE compliant direct access DLS.

If we say that a WCS can't be an INSPIRE compliant direct access DLS, because it can't do one of the required operations, that doesn't mean that wecan't supply INSPIRE compliant data as part of a WCS, just that we can't query the Spatial Objects. So the T2 document will become a little smaller.

29 Apr 2020 13/16

http://my.wcs.service/ows

#10 - 03 Feb 2016 05:18 pm - Michael Lutz

So if these coverage types are strictly sub-types of coverages as defined by GMLCOV, there should be no reason why they can't be deliveredthrough a WCS 2.0 and 2.1 when it comes in the near future. The WCS interface standard is not that prescriptive really in what can be delivered.

True. But my understanding from the Ispra WCS workshop was that all currently known implementations can only provide "vanilla" GMLCOV. That'swhere the whole discussion started about thinking an alternative way of encoding the INSPIRE coverage type that would use GMLCOV as it is andencodes the additional INSPIRE attributes in some other way (than GMLCOV sub-types).

If we look at the mandatory operations as defined by INS NS (the so called pre-defined data set operations) they apply to ALL download services. In these operations the queries are partially or wholly constrained depending on the implementation, there is no requirement in these mandatoryoperations to discover anything about the Spatial Object Types supported, or any ability to query relationships of the coverages in respect to thetheir spatial object type, those operations are conditional on there being an INSPIRE compliant direct access DLS.

If we say that a WCS can't be an INSPIRE compliant direct access DLS, because it can't do one of the required operations, that doesn't meanthat we can't supply INSPIRE compliant data as part of a WCS, just that we can't query the Spatial Objects. So the T2 document will become alittle smaller.

This is correct. If we cannot find a way to map the Describe Spatial Object Type operation to WCS, possibly because the concept of "spatial object"does not fit well with coverage concept (see also #2681), than we just limit ourselves to the mandatory operations. You would then still be able to dosub-setting as is supported by the GetCoverage operation.


Michael Lutz wrote:This is correct. If we cannot find a way to map the Describe Spatial Object Type operation to WCS,

But could one option be that we provide some other service (or operation) that provides the required introspection of Spatial Object Types, so we havea hybrid solution? That is, that the Describe Spatial Object Type operation is provided by one non-WCS 2.0 operation, and the Get Spatial Objectoperation is provided by a WCS operation?


Michael Lutz wrote: my understanding from the Ispra WCS workshop was that all currently known implementations can only provide "vanilla" GMLCOV. That's wherethe whole discussion started about thinking an alternative way of encoding the INSPIRE coverage type that would use GMLCOV as it is andencodes the additional INSPIRE attributes in some other way (than GMLCOV sub-types).

A WCS 2.0 GetCoverage response is a multi-part response, part one is an XML description of the bounding box, metadata, domain type, range type(exactly the same as the DesrcribeCoverage response), and part two is the coverage data the (range set), which can be provided as inline XML, or canbe provided as a separate XML file, or can be provided as a GeoTiff image, or can be provided as a NetCDF file etc.

In the gmlcov:metadata you can put in almost anything, so for example we put in a full GeoSciML response describing the contact for a number ofgeological surfaces in one of our WCS services.

29 Apr 2020 14/16

If we are looking at some way of querying the spatial objects types and properties available in a WCS then we should be discussing how to addrequired information in this metadata section. We had an application that did just this, querying the GeoSciML to return coverages that fitted a certainset of criteria for example.

If we look at the RenewableAndWastePotentialCoverage Spatial Object Type definition in INS SDS (aka INS ISDSS) we can see that some of theattrbutes appear to be metadata, some to be domain set information, some to be range type information, and we have additional information that tellsus about the range set itself; so it all appears that this abstract type could be converted into coverage data that can be served through a WCS. (Ihaven't looked at how the ENERGY data spec actually attempted to map it, but conceptually it is mappable to a coverage data set that can be providedthrough a WCS).

I would interpret the subset nature here as saying that a coverage data set which is of Spatial Object Type RenewableAndWastePotentialCoverage is asubset because it tells us that it is a RectifiedGridCoverage in which the range set values shall be energy potential values of type measure (as opposedto a RectifiedGridCoverage where no constraints are applied to range set or range type).

#13 - 04 Feb 2016 05:32 pm - Peter Baumann

Just adding my 2 cents:

indeed, metadata is always a "safe" location for extension. While type derivation facilities exist in XML Schema, implementations will be done in someprogramming language like Java, not in XML - hence, human programmers will look at the XML Schema code and reimplement what they see (andnot the complete XML type model).

For example, we have a RectifiedGridCoverage type. This is reflected on type level (ie, in the tag name), not in the instance (ie, some elementcontents). From a rigorous viewpoint, a WCS should be able to deliver a subtype, say, OrthoImageCoverage (which then would have a different rootelement). Would be interesting to know how implementations behave.

In EO-WCS, a CoverageSubtype element was used in the capabilities, eg:

someEOCoverage RectifiedDataset

29 Apr 2020 15/16

...

I suggest to look into EO-WCS (10-140) how much such an approach might help here. As said, I have no straightforward solution either.

On the other hand, what is the _intent_ behind? feature types like lines and points need to be distinguished, but can you do that to any level, such asdifferentiating highways from streets, channels from rivers? Maybe the distinction between regular and irregular grid is sufficient?

29 Apr 2020 16/16

Documents

MIWP-7b: WCS-based download services - Discussion #2680 · MIWP-7b: WCS-based download services - Discussion #2680 ... CEMT Class Condition of Water Facility Fairway Area Ferry Crossing