[Requests] Some comments for GMLJP2 2.0 standard document

Piero Campalani cmppri at unife.it
Fri Mar 14 11:50:44 EDT 2014


1. Evaluator:
PIERO CAMPALANI (JACOBS UNIVERSITY BREMEN)

2. Submission: [OpenGIS Project Document Number, Name]
OGC 08-085r2,
OGC GML in JPEG 2000 (GMLJP2) Encoding StandardPart 1: Core


========================================================
1. Requirement: GENERAL

2. Implementation Specification Section number: GENERAL

3. Criticality: EDITORIAL

4. Comments/justifications for changes:
Proof read needed, several typos and English errors (eg. examplified, 
accomodate), missing words (``GMLJP2 instance data associated [?] shall 
be stored in XML boxes''), missing or repetead punctuation (eg dots at 
the end of a period), non-englishwords (igual) :) .
Additional in-text style formatting to put in evidence URIs (eg italic 
or blue/underlined), XML labels (eg fixed-space font), could make it 
more readable too.
========================================================
========================================================
1. Requirement: GENERAL

2. Implementation Specification Section number: GENERAL

3. Criticality: XML FRAGMENTS

4. Comments/justifications for changes:
Give a caption + internal sequential ID (eg ``Listing N'') to each XML 
fragment in the document? Like tables, figs, etc.
I see several URNs in the fragments too: I believe they are deprecated 
now, and that they should be replaced with URIs.
Regarding specific XML/GML fragments:
  ...

    i. Sec.21 and others: I would explain the use of this
       rangeParameters element which is used throughout the document:

        <rangeParameters>
          <QuantityList uom="urn:ogc:def:uom:EPSG::9001"/>
        </rangeParameters>

       In the same fragment, the domainSet (RectifiedGrid) is not
       complete. ?

   ii. Sec.31: is this a valid fragment? It shows a "road" embedded in a
       NULL GMLJP2RectifiedGridCoverage, which makes it a little
       awkward.. I am not sure you can have "blank" grids in GML: is
       it legal to have *blank* domainSet/rangeSet/rangeType?

       In the same fragment there is an invalid reference to a
       codestream: ``gmljp2://codestream'' ?
       Or is the reference for the ``collection'' stream?

  iii. Sec.35: the fragment declared upper-left origin, but then the
       offset vector along latitude does not point south.

   iv. Sec.37: RectifiedGrid `RG_CodeStream0' has incomplete domainSet ?


Have all the blank/incomplete parts been removed for readability or is 
it because they are readable in .. JP2 header or somewhere else?
========================================================
========================================================
1. Requirement: #1

2. Implementation Specification Section number: #11

3. Criticality: Major

4. Comments/justifications for changes:
Figure 1 shows the GMLCOV collection and coverages, but I think it is 
misleading since as far as I understood from Req.1 and from the schema 
definitions, it is about GMLJP2 collection and GMLJP2 coverages: I 
actually cannot put a gmlcov:RectifiedGridCoverage as feature member of 
a collection, right?
========================================================
========================================================
1. Requirement: #6

2. Implementation Specification Section number: #16

3. Criticality: Major

4. Comments/justifications for changes:
Why is there a requirement for rectified-grid coverages, and not for 
referenceable ones?
========================================================
========================================================
1. Requirement: #8

2. Implementation Specification Section number: #18

3. Criticality: Minor

4. Comments/justifications for changes:
A reference to the UCUM specification here would be useful.
www.opengis.net/def/uom/* automatically redirects to the UCUM spec page, 
and they are the reference standard for UoM codes. I would add that UCUM 
codes or opengis-URI of UCUM codes are preferred or recommended.
========================================================
========================================================
1. Requirement: #11

2. Implementation Specification Section number: #21

3. Criticality: Minor

4. Comments/justifications for changes:
I would spend some more words clarifying this sentence:

   ``The sub-elements gml:domainSet, the gml:rangeSet and the
     gmlcov:rangeType shall be left as blank as possible.''
========================================================
========================================================
1. Requirement: GENERAL

2. Implementation Specification Section number: #22

3. Criticality: Major

4. Comments/justifications for changes:

   ``GMLCOV defines the associated JPEG 2000 file as a geographic
     image''

Is an image here intended to be a 2D raster? If it can be of type 
gmlcov:AbstractCoverageType but limited to 2D, that should be specified. 
I would otherwise replace the term /image/ with /coverage/ ?
Same in Sec.34:

   ``A single JPEG 2000 codestream is used to represent a single
     geographic image.''
========================================================
========================================================
1. Requirement: #22

2. Implementation Specification Section number: #26

3. Criticality: Minor

4. Comments/justifications for changes:
I would clarify that CRS/UoM/XML-schemas fragments can be also 
internally stored, even though not in the /gml.root-instance/ box.

  ``XML schemas, CRS dictionaries or units of measure dictionaries can
    be stored as external XML files and referenced form the GMLJP2 file''

It can be misleading: Fig.6 `Packaging of GML Boxes for CRS 
dictionaries, XML schemas, and units of measure dictionaries' then shows 
such elements internally to a JP2 file: I would add at least "[...] can 
/also/ be stored as external [...]" in the sentence above, and also put 
some more meaningful label in the pic.
========================================================
========================================================
1. Requirement: #23

2. Implementation Specification Section number: #28

3. Criticality: Major

4. Comments/justifications for changes:

   ``When used in JPEG 2000 files, the schemaLocation attribute is
     mandatory''

Some words seems to be missing here, because ``if the schemaLocation is 
used then it is mandatory'' does not really make sense. Is the 
requirement meaning ``When XML schema definitions are embedded in a 
JPEG200 file, then schemaLocation attribute is mandatory'' ?
========================================================
========================================================
1. Requirement: #24

2. Implementation Specification Section number: #29

3. Criticality: Minor

4. Comments/justifications for changes:

   ``Note that the relative reference meaning has been changed from
     previous versions of this standard''

I suggest to explain this change right after this sentence.
========================================================
========================================================
1. Requirement: #27

2. Implementation Specification Section number: #32

3. Criticality: Minor

4. Comments/justifications for changes:

   ``NOTE:  Care must be taken to preserve the integrity of such
     numerical codestream references when restructuring or rewriting the
     JPEG 2000 file in such a way that codestreams could get added,
     removed, or reordered.''

I suggest to explain it a little more: does it mean the stream IDs 
should always be in a strictly increasing order starting from 0?
========================================================



More information about the Requests mailing list