INSPIRE Community Forum

Can OGC WCS serve as INSPIRE Download service?

39 Views

Dear colleagues,

We - Danish data owner of DEM and Orthoimagary - are looking into implementing INSPIRE download services using WCS 2.0.

If we understand the Technical Guidance Download WCS correctly, the services are required to deliver entire data sets in order to be compliant to IR req. "Get Spatial Data Set".

WCS shall receive a request with an identifier as a parameter (i.e. without any "bounding box" that would limit the response). Notice that the identifier has to be the ID for entire data set - covering the hole member state.

However, the size of our data set makes it practically impossible to return the entire data set. Moreover, we are using MapServer which sets a maximal size for the response.

Our concern is - can WCS be a compliant INSPIRE Download service and support the required operation "Get Spatial Data Set". We cannot find the exact answer in the TG WCS Download - in section 5.1.3 the headline is “Get Spatial Data Set operation” and our hope was that there was recommendations and guidelines for how to distribute an entire data set using WCS operations.

But in example 19 and 20 the GetCoverage requests uses the CoverageID=Glasgow_bron_b which seems to indicate that the respond will be coverage-data for a sub-area (Glasgow).

And there seems not be any subsetting parameters in minimum parameters.

What do you think about this idea: Would it be in accordance with the requirements to serve zoom dependent down-sampled versions of the data set (overviews) as a response to a request with an identifier and no other limiting parameters?

Using orthoimagery as an example, that would give an image of the entire area at the outmost zoom level when only an identifier is used. Requests for more detailed subsets of the data set would require more parameters.

Please advise if this seems to be a feasible approach based on your knowledge of INSPIRE requirements and WCS.

Last an additional question: It would be highly appreciated if you have recommendations regarding GIS clients for testing WCS 2.0 services.

Thanks in advanced and all the best,

Lars

Replies

    • Public

    By Jordi ESCRIU

    Dear Lars,

    In my view Table 6 from the TG (in Section 4.1.1) is only establishing the conceptual mapping between the mandatory “Get Spatial Data Set” operation defined in the INSPIRE Network Services Implementing rule (INSPIRE NS) to the “GetCoverage” request implemented in an OGC WCS 2.0 service.

    See below:

    It is true that “shall” is used in the “Get Spatial Data Set Response” row at the botton of the table, but it is also true that it is included in the “Recommended WCS-based implementation” section of this table.

    Let’s say that MS are obliged to implement the “Get Spatial Data Set” operation of the INSPIRE NS, and this TG establish the recommended mapping to an OGC WCS operation in order to implement it.

    Perhaps, no considerations about the WCS service efficiency were taken into account when writing the mapping. In my opinion it is more than reasonable (or even necessary) to limit the size of data that users may retrieve from the service in a single query.

    Additionally, not that it is open the option to request a subset of the coverage - i.e. user may request an specific bounding box that will limit the coverage offered by the WCS in the response.

    The possibility to serve a down-sample when this situation occurs is definitively very interesting, but seems an option just when visualizing the data (coverages). 

    @Lars - Please, let me know what you think.

    Hope we may count with the expert opinion of James Passmore, who worked as editor of this TG.

    Jordi

    • Public

    By James PASSMORE

    But in example 19 and 20 the GetCoverage requests uses the CoverageID=Glasgow_bron_b which seems to indicate that the respond will be coverage-data for a sub-area (Glasgow).

    In this example (Glasgow_bron_b) is a full coverage, not a subset, it is one surface ( the base of the Bridgeton sand member) in geological model of the Glasgow area.

     

    • Public

    By James PASSMORE

    In my view Table 6 from the TG (in Section 4.1.1) is only establishing the conceptual mapping between the mandatory “Get Spatial Data Set” operation defined in the INSPIRE Network Services Implementing rule (INSPIRE NS) to the “GetCoverage” request implemented in an OGC WCS 2.0 service.

    Yes, that's correct ~ the regulation says what must be supported, the technical guidance maps the legal requirements to the operations of a WCS.

    Perhaps, no considerations about the WCS service efficiency were taken into account when writing the mapping. In my opinion it is more than reasonable (or even necessary) to limit the size of data that users may retrieve from the service in a single query.

    Well to some degree that is true (no considerations about the WCS service efficiency were taken into account), because the task was, as above, to map the requirement to the operation, not to say whether this was an efficient method. 

    I agree though that requesting a single coverage in a single request might not be very efficient (or even possible, depending on the nature of the coverage).   The technical guidance doesn't say that subsetting isn't allowed though, nor does it preclude you from offering up other solutions, such as using coverage collections, or WCPS, or even WPS as part of some hybrid solution.

     

     

     

     

    • Public

    By Iurie MAXIM

    Hi,

    In a separate tread https://themes.jrc.ec.europa.eu/discussion/view/207594/habitatsandbiotopes-in-wcs we arrived to the conclusion that with current XSD schemas, a WCS is not able serve any INSPIRE data theme that has a rectified grid coverage element.

    The OGC WCS can serve as Inspire download service, but first of all the INSPIRE XSD schemas should be changed in order to allow the WCS server to provide the INSPIRE data. Data encoded according to existing XSD schemas cant be served by any OGC WCS server.

    If INSPIRE community chose to keep the the actual XSD schemas, then we should develop our own extensions for the WCS servers in order to allow them firstly to serve the data. Then we should develop our own WCS extensions for Desktop aplications in order to be able to consume/read such data.

    If we chose to change the XSD schemas in order to allow the WCS servers to serve the INSPIRE data, then we should develop our own extensions for desktop applications only if we want to filter the data based on those attributes that are added by INSPIRE. But to ask to the question, for retrieving the dataset or even a subset of it we should not develop any extension.

    Therefore the first step in order to be able to use WCS as an INSPIRE Download service is to require JRC to change the XSD schemas (that contain coverages elements) and I would add that CIS 1.1 should be adopted instead of GMLCOV/CIS 1.0 for O&M.

    Iurie

    • Public

    By Peter BAUMANN

    Iurie-

    cannot agree more to your statement and conclusion. Please do approach JRC - as officially as possible - requesting the change you propose up there.

    Another comment on "efficiency": any service interface would have the same data volume problem - this is why a WCS (as opposed to WFS etc) offers subsetting, and that is what you normally would want to do as a user: request an area of interest. INSPIRE is somehow confusing as it sees subsetting as a corner case, rather than the rule (while download of a complete coverage is a corner case).

    On automatic zooming (ie, reduction of resolution): I'd not do that. It is against the WCS standard, and it would confuse. For scaling there is a specific WCS functionality.

    Rather, use some quota. This is tentatively not part of the WCS standard as (i) WCS is a functionality interface defining parameters, and what user would provide a quota parameter? ;-) ... and (ii) security, volume quota etc are not specific to coverages - all OGC services should allow a separate parameter for doing that.

    Hence, quota could be a server config parameter, for example. Just as an idea.

     

    -Peter

     

    • Public

    By Jordi ESCRIU

    Thank James for all your clarifications.

    According your words, the TG is not stating that the Get Spatial Data Set Operation shall request an entire coverage, i.e. subsetting is allowed. And better explaining my words ("no considerations about the WCS service efficiency were taken into account") - As you pointed out, this was not the objective of the TG. 

    @Iurie - Thanks for your input. It is reminding us a more general and complex issue, broader in scope than the original (specific) question post by Lars - Clearly It would deserve a dedicated post!

    Since this is really one of the conclusions that could be derived from the Webinar "Implementation of INSPIRE Coverages" we hold in November 2017... I propose to open a dedicated thread after the INSPIRE Conference in Antwerp (next September), where we have scheduled a dedicated workshop: Practicing INSPIRE coverages - Enhancing your data cube implementation assets!. Hopefully then, we will have a more coherent and clear picture on how to solve the issue about the xsd schemas. 

    With respect to @Peter words - I also agree that the response of a WCS shall not serve a downsampled coverage different than the one requested by the user. In fact, is is a service providing direct-access to data, i.e. it shall preserve the original data values. Maybe it is an option just when visualizing the raster file (i.e. via WMS, WMTS) corresponding to the coverage.

    @Lars - I proceed to close the discussion topic, since your original question seems answered. Feel free to contact me through the platform in case of remaining questions.

    Jordi

     

This discussion is closed.

This discussion is closed and is not accepting new comments.

Elevation, Ortho & Grids

Elevation, Ortho & Grids

INSPIRE Thematic Cluster Elevation, Orthoimagery, Reference systems, Geographical grids - Join this group to share your knowkledge, learn and collaborate in solving issues related to the Elevation, Orthoimagery, Reference systems and Geographical grids themes