European Commission logo
INSPIRE Community Forum

Clarify the structure of coverage encoding-related sections in the TGs - "Default encoding(s)" and "Alternative encoding(s)"

There is a need to propose a clearer structure for sections “Default encoding(s)” (e.g. 9.4.1.2 in the Elevation TG) and “Alternative encoding(s)” (e.g. 9.4.2.1 in the Elevation TG).

It would need to be aligned with the different options foreseen to deliver coverages (those explained in section 9.3 in the Elevation TG), in order to avoid readers to make their own interpretations. 

This need is also applicable to the Orthoimagery TG, and probably to the TGs from other INSPIRE themes dealing with coverage data.

 

  • Jordi ESCRIU

    The proposal to improve these sections of the TGs is originated from the following email.

    [James Passmore wrote on 28.08.2015]


    9.4.1.2. Default encoding(s) for application schema ElevationGridCoverage (coverage data) - From INSPIRE Technical Guidelines on Elevation v3.0.
     
    This section is a little messy because it deals with/mentions four named paragraphs, but doesn't deal with any interrelationships, so we have (my numbering):
     
    (i) Name: ElevationGridCoverage GML Application Schema
    (e.g. the schema you referenced)
     
    (ii) Name: GML Application Schema for Coverages (for the coverage domain)
     
    (iii) Name: TIFF (for the coverage range)
     
    (iv) Name: GML Application Schema for Coverages (for the coverage domain and range)
     
    As I understand it (ii) + (iii) would be one representation of a multipart WCS 2.0 service output, and are mutually exclusive from (iv) which is another representation of a multipart WCS 2.0 service output; mutually exclusive in the respect that for any single WCS GetCoverage request you would have one or the other (you could substitute any other binary format for Tiff in iii) in any single request.  However  you could have both representations in the same service for the same coverage through different requests if desired.  Which leaves (i), without an explanation as to where this is meant to fit in; I think though that it probably (or better logically) is meant to be as part of (iv) to help describe the range, but unhelpfully the example doesn't actually show this either in the rangeType or the rangeSet, so it's a bit of a mystery.

    If we look at '9.4.2.1. Alternative encoding for application schema ElevationGridCoverage', we have only two named paragraphs:
     
    Name: GML Application Schema for Coverages (for the coverage domain)
     
    and
     
    Name: Bathymetric Attributed Grid Object (BAG) (for the coverage range)
     
    So that's no mention of the ElevationGridCoverage GML Application Schema at all, and this fits in with my interpretation above, which in summary is that there is no requirement for a multi-part WCS GMLCOV + Binary to mention or conform to the XML schema.


     

  • Jordi ESCRIU

    And the following answer.

    [Michael Lutz wrote on 07.09.2015]


    I agree that the encoding sections in the EL data specification is not entirely clear. It should read:

    1. GML multipart representation (as defined in section 9.3)
      1. ElevationGridCoverage GML Application Schema (for the coverage domain)
      2. TIFF (for the coverage range)
    2. GML Application Schema for Coverages (for the coverage domain and range)

    i.e. the multipart message should use the "extended" GMLcov schema as the wrapper, including the additional attributes defined for the ElevationGridCoverage class.

    This is also what is proposed in the data specification document template.

    The recommended encodings should use the same format as the default encodings, i.e. also here the ElevationGridCoverage schema should be used instead of the the plain GMLcov schema. Alternatively, if the GMLCov schema is used, it needs to be specified how to map the attributes in the model (e.g. inspireId, surfaceType, propertyType, ...) to the encoding.


     

  • Jordi ESCRIU

    Do you agree with the proposal from Michael to update these sections of the Technical Guidelines?

    Please provide your input to improve them!

    Jordi

  • Jordi ESCRIU

    In my view, the update proposed by Michael is just a clarification of the structure of the TG documents - at least TGs on Elevation and Orthoimagery - according the different options allowed for encoding coverage data, rather than a change of content.

    Hence, I will be proposing it as a change request to the TGs in the next MIG-T meeting in Rome.

    The proposal is stated in the following page:

    https://themes.jrc.ec.europa.eu/pages/view/54815/clarify-structure-of-coverage-encoding-related-sections-in-tgs-default-encodings-and-alternative-encodings

    Please, indicate me here if you disagree on this decision.

    Jordi

  • Jordi ESCRIU

    Dear colleagues,

    Since there is no comment againts this proposal (already forwarded to MIG-T), I proceed to close this discussion topic.

    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