European Commission logo
INSPIRE Community Forum

Inconsistencies/errors found in the INSPIRE TGs on orthoimagery


During the work done to upgrade the GDAL JP2OpenJPEG driver to be able to read/write GMLJP2 files conformant with the TGs, some inconsistencies or errors have been found in INSPIRE_DataSpecification_OI_v3.0.pdf:

  • Page 143: « HEIGHT = domainSet.limits.high[1]- domainSet.limits.low[1] ». Should be « domainSet.limits.high[1]- domainSet.limits.low[1] + 1 » since the « high » element is the coordinate of a pixel, and not a size.
  • Page 143: « WIDTH = domainSet.limits.high[0]- domainSet.limits.low[0] ». Should be « domainSet.limits.high[0]- domainSet.limits.low[0] + 1 » for above mentioned reason
  • Page 144: bpcc condition value is reported as being "x000 0000 to x010 101". Should be « x000 0000 to x0100101 » (missing zero) since binary number 00100101 = 37 = 38 - 1
  • Page 144: Xsiz = domainSet.limits.high[0]. Should be domainSet.limits.high[0] + 1 for above mentioned reason.
  • Page 144: Ysiz = domainSet.limits.high[1]. Should be domainSet.limits.high[1] + 1 for above mentioned reason.
  • Page 146: Potential confusion related to "The place to provide GML within JPEG 2000" being mentionned in front of a top-level xml box, whereas it must be a xml box inside a « asoc » super-box per GMLJP2.

Best regards,

Paul Hasenohr

  • Jordi ESCRIU

    Thank you very much Paul,

    I will have a look at the TG later today.

    Does someone else detected any of these potential issues?


  • Jordi ESCRIU

    Hi Paul,

    I am not an expert in GML enconding, but I had a look at the issues you raised:

    • Issues in Page 143 (HEIGHT / WIDTH) and 144 (Xsiz / Ysiz): The gml:limits element contains a single gml:GridEnvelope. The gml:low and gml:high property elements of the envelope are each integerLists, which are coordinate tuples, the coordinates being measured as offsets from the origin of the grid along each grid axis - I guess you propose the value of 1 in order to tranform offset values to sizes (in this case multiples of cell sizes, either height or width). Did I understand it correctly?
    • Issue in Page 144 (bpcc / bits per component condition): As you stated the binary number  00100101 = 37 - If I am not wrong this binary number is related to the number of bits / bit depth per each band in the orthoimage - Could you provide an example with a concrete orthoimage?
    • Issue in Page 146 (potential confusion about XML box element) - Could you explain the issue in more detail? - What I undestood is that this is related to the internal structure of a JP2 file.

    Any other views / opinions on these issues?


  • Even ROUAULT


    • Issues in Page 143 (HEIGHT / WIDTH) and 144 (Xsiz / Ysiz). Yes, if domainSet.limits.low = 0 0 and domainSet.limits.high = 9 19, the width is 9-0+1=10 and the height is 19-0+1=20
    •    Issue in Page 144 (bpcc / bits per component condition): My point was that there was just a typo, a missing zero, in the encoding of 37 as the binary number 00100101
    • Issue in Page 146 (potential confusion about XML box element): Page 146 could be understood as if the GMLJP2 box should be put in a top-level "xml " box, whereas the structure mandated by the GMLJP2 spec is more complicated. The top-level box must be "asoc " box with at least 2 children boxes: one "lbl " with value "" and another "asoc" box with a label "gml.root-instance", and a "xml " with the XML of the gml:FeatureCollection. Cf OGC 05-047r3 Figure 4 page 24.
  • Jordi ESCRIU


    Thanks for the clarifications.

    I will have a look to OGC 05-047r3 Figure 4 (page 24).


  • Julián DELGADO

    By Julián DELGADO

    Dear Paul, Jordi

    I have several doubts in relation with the matter, not from technical aspects beacuse i'm not a expert on it. My doubts are about the necessity to adapt our image formats (TIFF, JP2000) to INSPIRE with the modification of internal labels in the files.

    I see that the annex E of OI specifications, where this subject is explained, is 'normative'. So this means that we shoud follow. But if you read up in the specifications, the annex E is called like a Recommentadion 32. So, i have doubts if we have to proceed with the annex or not.

    Please if you have some hints about the matter will be welcome. Annex E seems complicate to be done for many data providers and not planned effor in the transformation.

    My best regads


  • Jordi ESCRIU

    Dear colleagues,

    In my view, Annex E is focused on the implementation and it can not be imposed to Member States. INSPIRE only defines what must be implemented, but not how to implement it - I guess this is the reason for having the Recommendation 32.

    Having a look to the Annex (normative, as you said), it provides a number of requirements - but using the "TG Requirement" style. Such requirements do not appear in the Implementing Rule of ISDSS, they have to be met just for claming conformance to the specifications.

    This is something that JRC may confirm.

    In any case, the implementation using TIFF and JPEG2000 formats should follow the rules in the Annex. And, in my opinion, they are more requirements due to the own implementation format (that must be fulfilled as well), which few people are used to apply.

    Best regards,


  • Jordi ESCRIU

    Leaving aside the discussion if Annex E shall be followed or not (as introduced by Julián), it is clear to me that:

    - Issues / typos identified by Paul and Even in pages 143 and 144 shall be corrected.

    - From my point of view, having revised OGC 05-047r3 Figure 4 page 24, Issue in page 146 of the OI technical guidelines shall be corrected as well, according to this implementation standard.

    Does anyone in the cluster disagree on this?


  • Michael LUTZ

    Hi Jordi, Paul, all,

    in the data specifications we made the distinction between IR requirements (requirements directly included in the legal acts) and TG requirements (requirements that need to be met, when using a certain proposed solution, in order to meet the related IR requirements).

    For the encoding the IR requirements are stated in Art. 7 of the IRs: there needs to be a publicly available ISO 19118-compliant encoding rule covering all spatial objects included in the data model. Compliant with ISO 19118 means (from clause 9.1 of ISO 19118): 

    An encoding rule shall in general specify the following:
    a) general encoding requirements (9.2):
      1) application schemas and schema language,
      2) order of bits within each byte, and bytes within a word (where applicable), 
      3) character repertoire and encoding,
      4) necessary exchange metadata,
      5) dataset and object identification convention;
    b) input data structure (9.3):
      1) data structure used to pass data according to an application schema (data structures iA and iB in Figure 1) to the encoding service, called the instance model,
      2) how the instance model is related to the application schema;
    c) output data structure used, called the exchange format (9.4);
    d) conversion rules, called the mapping, for converting data in the instance model to the exchange format (9.5):
      1) conversion rules for encoding,
      2) if necessary, conversion rules for decoding;
    e) sufficient examples of abstract data, application of conversion rules and encoded data (9.6).

    This means that for each proposed format (e.g. GeoTIFF), such an encoding needs to be specified, and, like for GML, these rules should be included in the TGs as TG requirements.

    To cut a long story short, recommendation 32 should probably become a TG requirement and be reworded to "... shall...". This would then also make the 'requirements chain' consistent.

    I cannot judge whether something needs to be changed there (the errors reported by Paul) and/or simplified (as hinted at by Julian) since I don't understand the technical details of Annex E. I leave this to the technical experts...

    Hope this helps,  Michael


  • Jordi ESCRIU

    Dear Even & Paul,

    Nobody rejected to the editorial corrections you (both) proposed in this thread, so I want to propose them as corrections for endorsement in the MIG-T Meeting in Rome (may be any of you will be present).

    As I said on 24 July, the issues you spotted shall be corrected - Please, give me an answer about the items in blue below - To confirm the exact changes to be done (those highlighted in red):

    Issues / typos identified in pages 143 and 144 shall be corrected.

    Page 143:

    • 'HEIGHT' box in JP2, maps to 'doimainSet.limits.high[1] - doimainSet.limits.low[1] + 1' in GML.
    • 'WIDTH' box in JP2, maps to 'doimainSet.limits.high[0] - doimainSet.limits.low[0] + 1' in GML.

    Page 142 (not 144, as you spotted - PLEASE CONFIRM if something else is needed in page 144)

    • 'Xsiz' marker in JPEG2000 codestream, maps to 'doimainSet.limits.high[0] + 1' .
    • 'Ysiz' marker in JPEG2000 codestream, maps to 'doimainSet.limits.high[1] + 1' .

    Page 144

    • 'bpc' ('bpcc' type - bits per component) must have the following Condition/Value:

    'x000 0000 to x0100101

    Component sample bit depth = value + 1.
    x=0 (unsigned values)
    x=1 (signed values)

    Issue in page 146 shall be corrected as well (once revised OGC 05-047r3 Figure 4 page 24).

    • 'XML Box' - I guess you are only proposing to explain the "Mapping GML" column better.

    PLEASE PROVIDE ME WITH the exact text to be included i the "Mapping GML" column, OR the exact structure of the table for the XML Box - if you think any other change shall be applied.

    NOTE: I do not have access to ISO 15444-1 (which defines the JP2 format), so I can not evaluate of the current structure of the table is suitable. My impression is that only the "Mapping GML" column has to be edited.

    For the time being, I will leave this discussion topic opened - Mainly for continue discussing if Recommendation 32 in TG OI should be transformed to a TG requirement (as pointed by Michael).


  • Jordi ESCRIU

    I copy here an email received from Even Rouault just some minutes ago...


    I looked at your proposal at bottom of and I'm fine with it.

    Concerning the issue with the xml box at page 146. I suggest replacing the line XML Box with the following one:

    ASOC Box     |     'asoc'     |     "outer" association Box for XML formatted information to a JP2 file.     |     Optional     |     The place to provide GML within JPEG 2000 (see OGC standard05-047r3 paragraph 8.2).





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