European Commission logo
INSPIRE Community Forum

EL GridCoverage Model - CV_Grid:extent or CV_Grid:limits

Hi everybody,

I am rather new to the Coverages subject and am right now working on transforming Elevation data into the INSPIRE Elevation GridCoverage model.

I have a question concerning the domainSet-attribute of the ElevationGridCoverage-FeatureType: The Data Specification (section 5.5.1.2.2.) mentions the attribute CV_RectifiedGrid:extent (which it inherits from CV_Grid according to the UML diagram of OI https://inspire.ec.europa.eu/data-model/approved/r4618-ir/html/index.htm?goto=2:2:4:1:1:7835 - this association is not diaplayed in the UML diagram of EL, which is why I am reffering to OI here). In contrast to that, "extent" cannot be found in the corresponding xsd (http://schemas.opengis.net/gml/3.2.1/grids.xsd#0:0). It seems that it has been replaced by CV_Grid:limit?.

I could not find any part in the Data Specification or any thread in this Cluster, that explains, why that is the case. Could someone help me out and explain to me, why the xsd differs from the model representation?

 

Thank you in advance and all the best

Johanna

  • Johanna Ott

    Hi Kathi, hi Peter,

    Thank you for your replies.

    @Kathi: Yes, you understand the encoding idea right. I don't know if there are client applications that can cope with it. For now, I am mainly interested in fulfilling INSPIRE compliant data delivery for that dataset. I hope we will be able to change that to WCS once the specifications allow to do so.

    Concerning the concrete data handling in my current approach, I still have some open points though. There are two main questions for me:

    • about the content of domainSet:RectifiedGrid and domainExtent: Do I have to enter origin- and limits-values (in the RecitifiedGrid) and the domainExtent of that one partial/smaller area I am describing with one specific ElevationGridCoverage object (that is how I would interpret section 5.5.1.1.1 of the Data Specification) or do I have to enter x times the origin- and limits-values (in the RectifiedGrid) and the domainExtent of the whole WCS in general (that is how I would interpret the sections 5.2.9 and 5.5.1.1.2 of the Data Specification)?
    • about the CRSs in use: Do you think it would be a problem if the information of the ElevationGridCoverage object itself would be in a different CRS than the WCS GetCoverage request (if they describe the same BBOX of course)? From my understanding, that would not really matter as the WCS request would deliver a result in the right extent whereas from the ElevationGridCoverage information, the user would know where to locate it.

    I would be great, if you could help me with that - once this is clarified, I can go on mapping for this approach and will see if I am running into more open points and questions.

     

    @Peter: I pick WFS because (if I did not misunderstand all discussions I read during the last months), there is currently no INSPIRE WCS specification that allows creating INSPIRE compliant WCS with standard software. Please let me know if I got that wrong - that would safe a lot of work and unsatisfying results that I am currently creating.

     

    All the best

    Johanna

  • Katharina SCHLEIDT

    By Katharina SCHLEIDT

    Hi Johanna,

    I'm trying to reconstruct your example in my brain, to my memory you're providing individual INSPIRE Coverage Features via WFS (whereby you've split it down to smaller chunks at the feature level for handling), then are providing an xlink to the paired WCS for the coverage range.

    To your first question, I would expect the same domainSet in the INSPIRE Coverage Feature being served by WFS as is provided by the corresponding WCS; thus my pragmatic recommendation would be to query the domainSet off of your WCS and provide the same origin/offset structure for consistency

    As for the CRS, I do not see this as an issue as alternate CRS can be requested from the service types utilized. However, I don't quite understand the reasoning behind using different CRS - is this due to the grid being utilized, or is there some other underlying reason?

    In the meantime, I continue to hope that our revised schemas for coverage models that we'll be presenting next week at the Helsinki Event find the commissions approval, so we can get on with a more sane coverage approach

    :)

    Kathi

  • Peter BAUMANN

    Hi Johanna,

    WCS Core allows retrieval in the Native CRS of the coverage (implementations should be able to do something simple while still being a WCS - in other words: reduce implementation barrier). What you request, retrieval in some different CRS, requires the WCS CRS extension to be implemented. Here is more overview and background material: http://myogc.org/go/coveragesDWG .

    WFS does not understand the structure of coverages, it can just offer them as black boxes; all coverage specific functionality is concentrated in the WCS.

    As you mention implementations: actually, rasdaman (OGC reference implementation) does support INSPIRE WCS. As Kathi mentioned, this will be demonstrated at the Helsinki INSPIRE workshop. Current discussions are more or less centering around INSPIRE metadata representation.

    HTH,

    Peter

     

  • Johanna Ott

    Hi Kathi, hi Peter,

    Thank you for the input.

    @Kathi: The reasoning behind having different CRSs is that the tiles I am using to create the smaller Coverage Features have BBOX coordinates I can easily use to create the WCS requests. But these coordinates are not in an INSPIRE compliant CRS. So I need to reproject the individual Coverage Features when exporting the data into an INSPIRE compliant CRS but can keep the coordinates given in my source data to create the WCS requests.

    @Peter: I know that delivering the WCS data in a WFS is limiting the functionality, but I currently don't see an alternative for me. I will inform my colleague responsible for it about the rasdaman implementation. I hope the Helsinki event will bring some more clarification to the coverage handling subject.

    I will get back to you here if any more questions occur during my implementation or if I have an updated version of the GML :)

    All the best

    Johanna

  • Johanna Ott

    Hi everybody,


    After the next iteration of implementing the described combined WCS-WFS workaround, I still have one more rather basic question on how this can be realized in an INSPIRE-interoperable way.


    As described before, the plan is to use a dataset with regular tiles for the area the WCS covers and to create one ElevationGridCoverage object per tile which contains the tiles' geometries as domainSet and a WCS GetCoverage request with a subset parameter for the respective tile area as rangeSet.File.fileReference.


    The issue I am currently facing is the following: The source WCS as well as the tile dataset are delivered in a country-specific CRS which is not part of INSPIRE. If the tiles' geometries get converted to an INSPIRE-compliant CRS, the GetCoverage subsets probably won't fit the geometry exactly anymore.


    Is it possible that in this case it would be valid to deliver the ElevationGridCoverage in the country-specific CRS as only that fits the WCS subsets exactly? Or are there any other ideas on how this combination could be implemented in order to implement a valid INSPIRE endpoint?


    All the best


    Johanna

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