European Commission logo
INSPIRE Community Forum

Need more guidance for Elevation encoding and correct example (for ElevationGridCoverage) on the basis of GMLCOV schema

As strongly involved in IGN imagery and gridded data standardisation activity, I tried to evaluate the present INSPIRE EL DS specification, and discovered that guidance is too limited for ensuring correct implementation. I went down to 9.4.1.2. Default encoding(s) for application schema ElevationGridCoverage (coverage data) and discovered that:

- handling of Vertical CRS is specified at an abstract level in 6.2.1.4.1. General mechanism for the identification of the vertical CRS  under Vertical CRS linkage to Elevation grid coverages and Figure 23 (on the basis of ISO 19123). However nothing explains how it should be handled under GMLCOV schema.

- the example provided in 9.4.1.2. is a "copy/paste" of the OI example, addressing Radiance and not Elevation. Consequently it appears as useless in EL specification.

From recent discussion under the OGC, there seem to be some OGC consensus on handling the Vertical CRS description under the rangeType of GMLCOV RectifiedGridCoverage, under the referenceFrame attribute of a swe:Quantity element in the rangeType.

As an example, the following fragment could be considered (for Elevation above MSL):

            <gmlcov:rangeType>
                <swe:DataRecord>
                    <swe:field name="Elevation">
                        <swe:Quantity definition="URI to an Elevation definition resource" referenceFrame="http://www.opengis.net/def/crs/EPSG/0/5714"&gt;
                        <swe:description>Height above mean sea level</swe:description>
                            <swe:uom code="m"/>

This example also illustrates that some Elevation definition resource should be made available, as there is none available under ISO TC211 nor OGC.

The one that I've found on internet are: http://dbpedia.org/ontology/elevation, http://registry.it.csiro.au/sandbox/bom/agwex/elevation-method/digital-elevation-model, http://sweet.jpl.nasa.gov/2.0/spaceExtent.owl#Elevation

Thanks in advance for comments, and consider an action in order to clarify specification in order to ensure interoperability of GMLCOV encodings (at least fro Rectified Grids) and facilitate implementation

  • Jordi ESCRIU

    Dear Emmanuel,

    Thanks for your post.

    I agree that more guidance is needed as for the encoding of coverages is concerned, not only for the INSPIRE Elevation domain but also in the orthoimagery one, and other domains which have to deal with GML coverages - as already highlighted in the following threads:

    https://themes.jrc.ec.europa.eu/discussion/view/2843/encoding-of-elevation-and-orthoimagery-coverages

    https://themes.jrc.ec.europa.eu/discussion/view/12901/domainextent-vs-gmlboundedby-el-oi-coverages-encoding

    https://themes.jrc.ec.europa.eu/discussion/view/32920/inconsistencieserrors-found-in-the-inspire-tgs-on-orthoimagery

    https://themes.jrc.ec.europa.eu/discussion/view/23508/example-data-in-accordance-with-oi-application-schema-for-copernicus-guidelines

    The collaborative work of the TWGs that developed the data specifications was more focused on the conceptual level, and unfortunately there was limited time and experience to develop the implementation level as desirable.

    Specifically, delivery chapters of the data specifications on the main themes dealing with coverage data were developed in collaboration between TWGs in order to tacke these issues. Hence, the existence of common contents.

    Regarding your findings:

    - agree that the general mechanism for the identification of the vertical CRS in Section 6.2.1.4.1 of the EL specs is totally at conceptual level. This should be accompanied of clear rules in the delivery chapter on how to declare the vertical CRS within the implemented GML COV. Let's have a look at the resources you provided.

    - the example provided in 9.4.1.2 is in fact a "copy paste" (in both, the EL and OI data specifications) from an example in Section 6.7 of OGC 09-146r2 GML Application Schema - Coverages. Nevertheless, I admit that the radiance example taken from the standard is more acceptable in the case of the OI data specs rather than in the EL ones. Hence, your example is really welcome.

    Facilitate the implementation is the main objective of the Thematic Clusters

    smiley 

  • Julián DELGADO

    By Julián DELGADO

    Dear Emmanuel, Jordi

    During last days I spent time working with GMLs for elevations. As Emmanuel pointed I didn't find a online reference for the elevation concept. I used a fictitious one to continue working, but should be updated. Proposed links from dbpedia and nasa seems good because they are refered to 'elevation' or 'altitude' concept, however links from opengis and csriso are related with the definition of the reference system, different things from my point of view.

    Althoght the most interesting fact that I propose with my GML example is how I encoded the range type data (=pixel values). I proved to do it using a WCS service instead attached images files like ISO or INSPIRE propose. Below I put the foundamental XML labels, in ordet to share it and obtaing advices from the rest of the community. Would it be well done? any idea on it? As you see I used a getCoverage request.

     

       <gml:rangeSet>
        <gml:File>
         <gml:rangeParameters xlink:href="http://www.ign.es/wcs/mdt?service=WCS&request=GetCoverage&version=1.0.0&coverage=mdt:Elevacion25830_25&CRS=EPSG:25830&bbox=484387.5,4778987.5,512212.5,4798212.5&WIDTH=1113&HEIGHT=769&FORMAT=geotiff" xlink:role="http://www.opengis.net/spec/WCS_coverageencoding_geotiff/1.0/" xlink:arcrole="fileReference"/>
         <gml:fileReference>geoserver-GetCoverage.tiff</gml:fileReference>
         <gml:fileStructure/>
         <gml:mimeType>image/tiff</gml:mimeType>
         <!-- This encoding way is a proposal, required to be shared and validated with other encoding examples for coverages using WCS. Native CRS is used for data providing -->
         <!-- WCS provides the coverage in the native reference systems (EPSG:25830 and national altimetric system) -->
        </gml:File>

    Example of EL GML encoding

     My best regards

  • Jordi ESCRIU

    Dear Julian,

    Thank you for your example!

    I think it would be a good idea to develop here an Elevation Grid Coverage example to update section 9.4.1.2 of the EL TG (replacing the radiance example from the OGC standard) - We may reuse the your proposal.

    Having taken a quick look at your example, a question comes to my mind:

    Should not the WCS request be included within the "gml:fileReference" element, whereas the "gml:rangeParameters" should contain a description of the range according to some standard (e.g. description of the variable/band represented, applicable CRS, uom, etc)?

    I am just intruducing myself in the topic - Reading Section 19 of OGC 07-036 (GML Encoding Standard).

    Jordi

  • Jordi ESCRIU

    Please, use this thread for discusing EL specific matters concerning implementation of Elevation Grid Coverages using GMLCOV (e.g. for the collaborative development of an EL coverage example).

    And the following (already existing) thread for discussing general coverage implementation aspects (i.e. applicable to EL and OI coverages, and even also to other themes dealing with coverage data).

    https://themes.jrc.ec.europa.eu/discussion/view/2843/encoding-of-elevation-and-orthoimagery-coverages?offset=10

    Jordi

  • Jordi ESCRIU

    Dear Julian & All,

    After analysing the relevant encoding standards I have come up with a GMLCOV example related to Elevation, based on the last file provided by Julián - See attached.

    Example - ICGC DTM to INSPIRE ElevationGridCoverage

    To be discussed in the INSPIRE-KEN coverage tranformation workshop next week.

    Jordi

  • Emmanuel DEVYS

    By Emmanuel DEVYS

    Dear Jordi, and all

    sorry about my lack of reactivity (unfortunately I have no time available to participate to this work, but in close contact with my colleague Dominique Laurent).

    I come back to your suggestion on 2Sept "Should not the WCS request be included within the "gml:fileReference" element, whereas the "gml:rangeParameters" should contain a description of the range according to some standard (e.g. description of the variable/band represented, applicable CRS, uom, etc)?".

    My answer (as a Coverage expert and as far as I know the EL ElevationGridCoverage model) is NO. the rangeType element of the Coverage is supposed to address this. An attempt to do this - as shown by the example you provided - would not validate with the schema. see my comments on your example, and proposed corrected example, which validates with the EL:ElevationCoverage schema.

    I wish you fruitful discussions in the INSPIRE workshop next week, and shall try to check messages, if there are any.

    Emmanuel

  • Jordi ESCRIU

    Dear Emmanuel,

    Thank you very much for your expertise and input. I do not have any validation tool available yet - Just for discussion:

    I agree with you that the aim of rangeType is exactly to describe the range set values (uom, type of variable, nul values utilized in there, etc.).

    But the element "rangeParameters" (as proposed in OGC 07-036 GML for the 'gml:File' and 'gml:DataBlock' elements) is also intended to describe the variable, probably in a more generic way - See examples in pages 208, 208-209, 210 and 211 of OGC 07-036.

    According GML provisions, the 'fileReference' element is intended for referencing the range set values -  Not 'rangeParameters', as in the first example from Julián.

    GML Application Schema Coverages (OGC 09-146r2) was drafted and approved after OGC 07-036 GML, to describe coverages in a more flexible and standardized way. OGC 09-146r2 introduced the 'rangeType' element, so probably the purposes of 'rangeParameters' and 'rangeType' elements overlap somehow.

    If this overlap is confirmed, clear guidelines to encode coverages in GML (taking into account both documents) should be drafted, while a new version of GML comes up and clarifies all the provisions. In this case, I would agree that 'rangeType' shall be used (according OGC 09-146r2), but there is nothing preventing now the use of 'rangeParameters' according OGC 07-036 GML (at least, I have not found it).

    See also my reply on:

    https://themes.jrc.ec.europa.eu/file/view/43679/example-icgc-dtm-to-inspire-elevationgridcoverage

    Jordi

  • Julián DELGADO

    By Julián DELGADO

    Dear Emmanuel, many thanks for you clarifications

    I hope you can tell us recomendations for dealing with WCS and ISO coverages in the INSPIRE meeting of tomorrow in Barcelona.

    As national data provider of grid datasets, I would like to know a efficient way to provide big volume of grid data according INSPIRE (for example our complete OI dataset has a size around 20 Tb)

    My best rgards

  • Emmanuel DEVYS

    By Emmanuel DEVYS

    Dear Julian

    I am sorry but I shall not be in the Barcelona workshop, but my colleague Dominique Laurent from IGN will be there.

    I am not in a position to provide recommendations for dealing with ISO Coverages, WCS2.0 and GMLCOV for Elevation data (and tentative example that IGN developed for evaluation).

    If you need further information from IGN, please contact her, as I am not the best point of contact for INSPIRE implementation in IGN.

    Best regards

    Emmanuel

  • Jordi ESCRIU

    Find attached the file with the corrections proposed by Emmanuel.

    Elevation grid coverage - GMLCOV Example implementation (ICGC) v4

    We will discuss both examples during the workshop.

    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