INSPIRE Thematic Clusters

Experiences on encoding of Elevation and Orthoimagery coverages

3198 Views

Most information to be provided by Member States concerning the Elevation and Orthoimagery INSPIRE themes - except few exceptions - shall be expressed using the raster spatial representation type (raster format).

This is modelled within INSPIRE models reusing the concept of ‘coverage’ from ISO 19123 (extended for the purpose). Other INSPIRE themes, such as Geology (GE), Atmospheric conditions & Meteorological geographical features (AC-MF), Oceanographic geographical features (OF), Species distribution (SD), Land cover (LC) or Energy resources (ER), follow the same harmonized approach for raster data.

At implementation level, this means data shall be encoded in GML - completely or partially (several options available: multipart representation, external file encoding, inline encoding).

Existing datasets in Member States are commonly implemented by using well-known image file formats supported by georeferencing capabilities, without being formally compliant to a pure coverage structure.

Encoding of coverages in GML is therefore one of the issues data providers have to tackle in the INSPIRE implementation by using appropriate software transformation tools.

 

Replies

    • Public

    By Lena Hallin-Pihlatie

    Is it really so that all data have to be encoded in GML? In the encoding rules of for example the Data Specification on Orthoimagery the use of GeoTiff is also supported. If data providers decide to share their OI data as atom feeds, isn't it enough to share zipped regular GeoTiff files? 

    • Public

    By Jordi ESCRIU

    Dear Lena,

    The data specification foresees 3 alternative options to provide Orthoimagery data sets:

    OPTION 1: Multipart representation - This is composed of:
    • 1st Part: GML Part (gmlcov:RectifiedGridCoverage) - This is the structure of the coverage in GML, without the values.
    • 2nd Part: The Range Set of the coverage (the values), encoded using a well-known binary format – e.g. TIFF / GeoTIFF (*) - but embedded in the 1st Part.
    OPTION 2: External file encoding - This is composed of:
    • 1st Part: GML Part (gmlcov:RectifiedGridCoverage) - This is the structure of the coverage in GML, without the values.
    • 2nd Part: The Range Set of the coverage (the values), encoded using an external well-known binary format (linking it using gml:File) – e.g. TIFF / GeoTIFF (*).
    OPTION 3: Inline encoding

    The Range Set of the coverage (the values) is encoded within the XML inline (using the "DataBlock" element).

     
    When saying "provide data", I meant that data distributed through an INSPIRE download service shall be encoded using one of these 3 options (probably a WCS service).
     
    Other case is that e.g. Orthoimagery data may also "be shown" by using a WMS serving GeoTIFF files - for visualization purposes.
    • Public

    By Lena Hallin-Pihlatie

    Many thanks Jordi for the clarification!

  • By Julián DELGADO

    Dear colleagues

    I’m involved in the Spanish initiative for adopting INSPIRE in orthoimagery and elevation theme. And from our experience the actual problem raises in the creation of GML for Coverages itself, not for the partition of the information that maybe would like to apply option 1 or 2.

    I would like share with you our steps carried out, in case you are in the same situation or maybe you have just solved:

    1) Following INSPIRE data specifications on OI-EL we should reproduce RectifiedGridCoverages according ISO 19123. That means create special GML for coverages called ‘GMLCOV’ that contains a particular set of <labels/> to store information about rangeset, dominset, rangetype, etc…. But there is no much documentation in how to create GMLCOV in a practical view. Only OGC examples at https://portal.opengeospatial.org/files/?artifact_id=48553, http://www.opengeospatial.org/standards/requests/92.

    2) To create any INSPIRE GML, it is required to use the published XSD at INSPIRE web page. However we detected in some cases possible inconsistences in their xml references to other external schemas (OGC, W3C, etc.)

    3) But the most important point was to select the software able to create GML COV according ISO19123. We tested Safe FME 2014 and Degree, and they couldn’t recognize all <labels/> from the INSPIRE XSD needed for GML COV, but decided to use FME 2014 to be more flexible in the translation. Arising from here appears some added problems, what to do with missing <labels/>? There are some options:

    • a. Adapt the XSD manually before the translation. That solution was unreachable for us because we don’t have sufficient experience in xsd editing.
    • b. Create manually the <labels/> in FME using attributes and lists. We could do it inside FME environment but later when we wrote the GMLs this <labels/> where not recognized because the FME INSPIRE writer needs a XSD template to validate the data (previous INSPIRE XSD). As a result, the new attributes were not written in the GML or bad written with wrong origin schema.

    4) And as last topic, the visualization of the GML in a GIS. Depending axis ordering and final <labels/>, the GMLs can be different viewed.

    My best regards :) How could i upload files in this platform?

    • Public

    By Jordi ESCRIU

    Dear Julian,

    Many thanks for exposing your experience in Spain. I am sure other implementation working groups in Europe may have found similar issues. So there is place here to learn one from the others!

    Concerning Point 2 - This issue was reported in the MIG workshop on WCS-based INSPIRE download services (14-15 October 2014 - JRC, Ispra). The answer was that any examples describing the issue would help in analysing it. Actions will be taken if needed.

    In order to upload files - Please, click on the "Embed content" link, just in the right-top part of the "Reply to this" editor.

    Jordi

    • Public

    By Julián DELGADO

    Dear Jordi, collegues

    I share some pictures about our work on coverages creation:

    We used FME2014, as you can see, but no all XSD attributes were detected and we had to created them manually.

    FME2014_workbench

    Outputs inside FME environment seem sufficient good (no perfect), but if we export them like GMLs there were and redeable <labels\> for other softwares.

    Graphical output Attributes output

    Outputs in GlobalMapper and SnowFlake gml viewer

    Output in GlobalMapper Output in SnowFlake gml viewer

    About the problems with XSD (point 2 in my previous post) we re-check the estability and the validation was good. Sorry for the missunderstanding.

    XSD validation

    At summary, I hope that this examples can guide you; and helps us too to find a solution for this issue, form our side still un-solved.

    Best regards

    Julián

    • Public

    By Jordi ESCRIU

    I want to draw your attention to the following discussion thread, with a specific proposal from Peter Parslow to encode the domain extent of (ISO 19123) INSPIRE coverages using gml:boundedBy

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

    • Public

    By Jordi ESCRIU

    Encoding of coverages in GML is one of the main implementation issues for INSPIRE Elevation and Orthoimagery raster data, as well as raster data from other INSPIRE themes such as Land use and Land cover.

    If you or your organization have implemented or is currently working in the implementation of such kind of data, please share your experience in this discussion thread (transformation process, software used, issues encountered, related questions, etc.).

  • By Kenneth BRAGG

    Hi Julián

    Thanks for posting your experiences. I work for Safe Software the makers of FME and I'd like to follow-up on your point #3: "...they couldn’t recognize all <labels/> from the INSPIRE XSD needed for GML COV". Can you give me a bit more information on this issue. I would like to see if there is anything we can do in FME to solve this problem but I don't think I understand the issue.

    Thanks

    Ken Bragg

    • Public

    By James PASSMORE

    Hi Jordi,

    Here's an example of adding GeoSciML to the DescribeCoverage response for a Geological model surface, using gmlcov:metadata.  WCS version 2.0.1 service is provided by Rasdaman/Petascope.

    http://earthserver.bgs.ac.uk/rasdaman/ows?service=WCS&Request=DescribeCoverage&version=2.0.1&CoverageId=glasgow_bron_b&

    The GetCoverage request gives the same information plus the data  as part of a gml:rangeSet block.  Response time is quick, but you probably wouldn't want to do this on a large coverage.

    http://earthserver.bgs.ac.uk/rasdaman/ows?service=WCS&Request=GetCoverage&version=2.0.1&CoverageId=glasgow_bron_b&

     

     

     

     

     

     

     

This discussion is closed.

This discussion is closed and is not accepting new comments.

Elevation, Orthoimagery, Reference Systems and Geographical Grids Cluster

Elevation, Orthoimagery, Reference Systems and Geographical Grids Cluster

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