i. Abstract

This OGC GML in JPEG 2000 (GMLJP2) Encoding Standard defines how the OGC/ISO Geography Markup Language (GML) standard is used within JPEG 2000 images and other gridded coverage data for adding geospatial content to imagery. Specifically, this OGC standard defines requirements for the encoding and decoding of JPEG 2000 images and other gridded coverage data that contain XML documents that use GML and GML-based schema.

This document defines the use of GML within the XML boxes of the JP2 and JPX file format for JPEG 2000 (extending the JP2 file format, as specified in [ISO 15444-1] and [ISO 15444-2] in Annexes M and N). Further, an application schema for JPEG 2000 that can be extended to include geometrical feature descriptions and annotations is specified. The document also specifies the encoding and packaging rules for GML use in JPEG 2000.

ii.   Preface

This standard resulted from work in the 2004 OGC GML in JPEG 2000 Interoperability Experiment (IE). A group of OGC member organizations introduced a candidate specification document [OGC 04-045], which was later adopted by OGC as a public Discussion Paper, that became the basis for conducting the Interoperability Experiment.  The Activity Plan for the GML in JPEG 2000 Interoperability Experiment was formally approved by OGC in February 2005.  The resulting version 1.0.0 of this standard [OGC 05-047r3] was published in January of 2006.

Version 2 of the JPEG 2000 (GMLJP2) Encoding Standard was the result of discussions within the GMLJP2 v1.1 SWG during 2007 and 2008. These discussions were motivated by the experiences of those involved with the implementation and use of the 1.0.0 version. However, version 1.0 was not widely implemented due to loosely-specified coverage schema, rules for the georeference mechanism, and conformance clauses. Additionally, at the time it had to compete with the GeoJP2 image format[1]^,[2], which uses standard GeoTIFF metadata tags inside a header (specifically, a uuid) box in the JP2 format. Thus, GeoJP2 images may be thought of roughly as GeoTIFF files with image data stored in a JPEG 2000 format. The quickly developed and easily implementable GeoJP2 image format has been a “de facto” standard[3], which both benefits from and is limited by its use of the mature set of GeoTIFF metadata descriptions that, for example, do not currently support sensor model imagery.

New work on GMLJP2 was formally begun in 2012. The goal was to develop a version that provides a generic application schema for JPEG 2000 coverage while relying on the OGC GML Coverage Application Schema (GMLCOV). GMLCOV was later renamed Coverage Implementation Schema (CIS) version 1.0. The intended target audience for the new GMLJP2 version 2 (then and now) are: developers intending to implement geospatially enabled JPEG 2000 encoders and readers, developers of both WFS and WCS who wish to provide support for JPEG 2000 formats, and developers who wish to use GML to give imagery a geospatial context. This document aims to provide not only a clear and testable set of requirements, but also to supply an overview with useful hints and best practices beyond what would be contained in a purely normative text.

This revision of the GMLJP2 standard is fully conformant to GML 3.2.1 standard and guidelines, to the CIS 1.0 coverage encoding standard, as well as to the ReferenceableGridCoverage Extension standard.

iii.   Document terms and definitions

This document uses the standard terms defined in Sub-clause 5.3 of [OGC 06-121r8], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards.  Please note that the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this standard.

NOTE Occasionally this document capitalizes “SHALL” solely to emphasize a requirement.  No normative, semantic difference between “SHALL” and “shall” is intended.

iv.   Document contributor contact point

The following organizations submitted this document to the Open Geospatial Consortium:

The submitting entities are grateful for the contributions from the following organizations in the development and revisions of this standard:

• EUSC (Raul Alonso Reyes)
• GALDOS Inc. (Darko Androsevic)
• NGA (Steven Rogan)

The submitting entities are also grateful for the contributions of those listed in [OGC 05-047r3] who participated in the creation of version 1.0 of this standard.

All questions regarding this document should be directed to the editors:

• Lucio Colaiacomo, European Union Satellite Center
• Joan Masó Pau, UAB-CREAF
• Emmanuel Devys, Institut National de l’Information Géographique et Forestière (IGN)
• Eric Hirschorn, KeyW Corporation

v.   Changes to the OGC Abstract Specification

The OGC Abstract Specification does not require any changes to accommodate the technical contents of this document.

vi.   Changes since the previous approved version

The previous approved version of this standard is [OGC 08-085r5].  Changes reflected in this document address the following topics:

1. Integration with the ReferenceableGridCoverage Extension [OGC 16-083r2] via a new conformance class gmljp2rgrid.
2. Two requirements have been added to the conformance class core.
3. As the coverage standard GMLCOV has been renamed CIS, this document has been updated accordingly.

vii.   Future work

Further extensions may address image annotations, which are not addressed normatively in this document. Image annotations are discussed in section 12 (informative). Currently, this standard does not provide any concrete annotation schema.

Sensor model encodings for use with the ReferenceableGridCoverage Extension have been developed[4]^,[5]. Work towards the formal adoption of such encodings by OGC is anticipated.

Testing is needed for metadata streaming capabilities in JPIP protocol. GMLJP2 could serve as a key working example for testing out the decomposed XML feature with JPIP (for efficient streaming of metadata associated to the ROI Region of Interest). This could be part of a GMLJP2 extension.

viii.   Security Considerations

No security considerations have been made for this standard.

Foreword

Version 2.x supercedes the original GMLJP2 encoding standard [OGC 05-047r3], due to the extent of the technical revisions.

This document refers to OGC 12-108 GML Application Schema Coverages JPEG 2000 Coverage Encoding Extension (cf. http://docs.opengeospatial.org/is/12-108/12-108.html).

Version 2.1 addresses both rectified grid coverages, supported by the previous version 2.0 that was superseded by the corrigendum 2.0.1 (both with title Part 1: Core), and referenceable grid coverages, providing additional capabilities for this standard such as support for a wide range of sensor models described with GML 3.2 or SensorML 2.0.

The short form of the name of this OGC standard shall be GMLJP2.

GMLJP2 is normatively based on, and thus compliant with, the OGC Coverage Implementation Schema (CIS).  In this document, the acronym CIS specified without a version number refers specifically[6] to CIS version 1.0.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

Introduction

The OGC Geography Markup Language (GML) standard is an XML grammar for the encoding of geospatial information including geographic features, coverages, observations, topology, geometry, coordinate reference systems, units of measure, time, and value objects. A coverage is, loosely speaking, the digital representation of a spatio-temporally varying phenomenon. The formal definition of coverage in ISO 19123:2003 (also OGC Abstract Topic 6) defines coverages formally as the collection of direct positions in a coordinate space that may be defined in terms of up to three spatial dimensions as well as a temporal dimension.

Examples of coverages include rasters, triangulated irregular networks, point coverages and polygon coverages. Coverages are the prevailing data structures in many application areas, such as remote sensing, meteorology and mapping of bathymetry, elevation, soil, and vegetation. The Coverage Implementation Schema (CIS) version 1.0 (previously known as GMLCOV), utilized by GMLJP2, uses GML version 3.2 Coverages, together with SWE Common, to provide a common implementation schema that is used to describe coverage instances.

The ISO JPEG 2000 standard is a wavelet-based encoding for imagery that provides the ability to include XML data for description of the image within the JPEG 2000 data file.

The JPEG 2000 standard does not, however, describe any means for including ancillary geospatial information within the image, such as the geographic coordinates of the image, annotations, or references to features.

This GMLJP2 standard includes the following items.

• How CIS coverage descriptions and GML within JPEG 2000 standard data are used with an extendable GML application schema. This includes a georeferencing capability that is based on GML, thus inline with the OGC and TC211 standard for the encoding of geospatial data.
• Packaging mechanisms that allow for inclusion of CIS coverage descriptions and GML within JPEG 2000 data files. These include setting up the “Brand field in the File type” and “Reader Requirements” boxes with values required to signal the presence of GMLJP2 XML and a JPX file data, respectively.
• Support for the geo-referenceable type of grid coverage based on adopted extensions of GML, namely the ReferenceableGridCoverage Extension [OGC 16-083r2], has been added.  With newly added support for geo-referenceable systems, GMLJP2 transitions from an imagery format focused on rectified “map” images to a more general format with a potentially much wider set of capabilities with respect to grid coverages, for example, sensor model imagery.
• Annotations, meaning associations between regions of interest and video, graphics, text, etc. and how can be expressed in several XML encodings, including but not limited to: KML, SVG, or some GML application schema. The visualization of the coverage can also make use of KML.
• ISO metadata, Earth Observation profile metadata, and other profiles and examples for imagery metadata.

1.    Scope

This document defines a means for encoding and packaging of CIS rectified and referenceable grid coverages and supporting structures within the XML boxes of the header of the JPEG 2000 data format.

Thus, this document provides a way to georeference the data associated with the range sets of the coverage: that is, imagery and other gridded data contained in a JPEG 2000 file.  

The document in addition provides guidelines for the packaging of single as well as multiple codestreams, where each codestream represents a separate image or other gridded data.

Further, this document provides guidelines for the enhancement of the following supporting structures and other data associated with CIS grid coverage domain sets: metadata, features, annotations, styles, coordinate reference systems, and units of measure.

Finally, this document provides as a concrete implementation of this encoding standard an associated application schema that can be extended to include geometrical feature descriptions and annotations.

2.    Conformance

Standardization target of this document are concrete GMLJP2 2.1 instance documents that are headers of JPEG 2000 images, as generated and read by JPEG 2000 encoders and decoders, respectively.

This document establishes two conformance classes:

• core, URI http://www.opengis.net/spec/GMLJP2/2.1/req/core, with a single pertaining conformance class, core, of URI http://www.opengis.net/spec/GMLJP2/2.1/conf/core.  The normative sections (that is, the set of clauses) providing the requirements for class core are sections 7 through 10.
• gmljp2rgrid, URI http://www.opengis.net/spec/GMLJP2/2.1/req/gmljp2rgrid, with a single pertaining conformance class, gmljp2rgrid, URI http://www.opengis.net/spec/GMLJP2/2.1/conf/gmljp2rgrid.  Class gmljp2rgrid establishes a referenceable grid coverage type that is tied to the ReferenceableGridCoverage Extension [OGC 16-083r2]. The sole clause providing the requirements for class gmljp2rgrid is section 11.

Requirements and conformance test URIs defined in this document are relative to http://www.opengis.net/spec/GMLJP2/2.1/

Compliance with this standard shall be checked using all the relevant tests specified in Annex A of this document (normative).

3.    Normative references

The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to or revisions of any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

[RFC 2396]              IETF: IETF RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax, 1998

[ISO 15444-1]          ISO: ISO/IEC 15444-1:2004, JPEG 2000 image coding system: Core coding system, 2004

[ISO 15444-2]          ISO: ISO/IEC 15444-2:2004, JPEG 2000 image coding system: Extensions, 2004

[ISO 15444-4]          ISO: ISO/IEC 15444-4:2004, JPEG 2000 image coding system: Conformance testing, 2004

[ISO 19105]             ISO: ISO 19105:2000, Geographic information – Conformance and Testing, 2000

[ISO N2887]           ISO: ISO/IEC JTC 1/SC 29/WG1 N2887 (Klaus Jung), Including GML data based on the OpenGIS standard in JPEG 2000 family files, 2003

OGC [07-036]          OGC: OGC 07-036, Geography Markup Language V3.2.1, 2007. http://portal.opengeospatial.org/files/?artifact_id=20509

OGC [06-121r3]       OGC: OGC 06-121r3, OWS Web Services Common Specification, 2007. http://portal.opengeospatial.org/files/?artifact_id=20040

OGC [09-046r2]       OGC: OGC 09-046r2, OGC Naming Authority – Procedures, 2010. http://portal.opengeospatial.org/files/?artifact_id=37800

OGC [11-135]          OGC: OGC 11-135, Name Type Specification for Coordinate Reference Systems, 2011. http://portal.opengeospatial.org/files/?artifact_id=46361

OGC [10-157r4]      OGC: OGC 10-157r4, Earth Observation Metadata profile of Observation & Measurements, 2016. http://docs.opengeospatial.org/is/10-157r4/10-157r4.html

OGC [09-146r2]       OGC: OGC 09-146r2, OGC Coverage Implementation Schema, version 1.0.1, 2012. http://portal.opengeospatial.org/files/?artifact_id=48553

OGC [12-108]          OGC: OGC 12-108, GML Application Schema - JPEG 2000 Coverage Encoding Extension, 2015. http://docs.opengeospatial.org/is/12-108/12-108.html

OGC [16-083r2]       OGC: OGC 16-083r2, OGC Coverage Implementation Schema - ReferenceableGridCoverage Extension, 2017. http://docs.opengeospatial.org/is/16-083r2/16-083r2.html

In addition to this document, this standard includes several normative XML Schema Document files as specified in the Annexes.

4.    Terms and definitions

In addition to the following, this document uses the standard terms and definitions given in Clause 4 of [OGC 06-121r3].

4.1      annotation

A marking on illustrative material for clarification.

[ISO 19117]

NOTE:    For example, this can be an association between an annotation entity (e.g. a text label) and an image or some geometric “region” within the image. [OGC 05-047r3]

4.2           codestream 

A collection of one or more bitstreams and the main header, tile-part headers, and the EOC required for their decoding and expansion into image data.

[ISO/IEC 15444-1]

NOTE:   This is the image data in a compressed form with all the signaling needed to decode

4.3          coordinate 

One of a sequence of n numbers designating the position of a point in n-dimensional space.

[ISO 19111]

NOTE:    In a coordinate reference system, the coordinate numbers are qualified by units.

4.4       coordinate reference system 

A coordinate system that is related to an object by a datum.

[ISO 19111]

NOTE: For geodetic and vertical datums, the object will be the Earth.

4.5       coordinate system 

A set of mathematical rules for specifying how coordinates are to be assigned to points.

[ISO 19111]

4.6       coverage 

A feature that acts as a function to return values from its range for any direct position within its spatiotemporal domain.

[ISO 19123]

NOTE: A coverage is a representation of continuous geographic phenomena, which vary over space and have no specific extent (e.g. imagery or elevation data). A coverage associates a position within its domain to a record of values of defined data types. (ISO 19123)

4.7       curve 

A 1-dimensional geometric-primitive, representing the continuous image of a line.

[ISO 19107]

4.8       datum 

A parameter or set of parameters that define the position of the origin, the scale, and the orientation of a coordinate system.

[ISO 19111]

NOTE: A datum may be a geodetic datum, a vertical datum, an engineering datum, an image datum, or a temporal datum.

4.9       domain 

A well-defined set.

[ISO/TS 19103]

NOTE 1:      A mathematical function may be defined on this set, i.e. in a function f:A→B, A is the domain of function f.

NOTE 2:      A domain as in domain of discourse refers to a subject or area of interest.

4.10      elevation 

Synonym for height (pending future revision of the definition from OGC TC).

4.11      feature 

An abstraction of real-world phenomena.

[ISO 19101]

NOTE: A feature may occur as a type or an instance. “Feature type” or “feature instance” are to be used when only one is meant. A coverage is a type of feature, but feature data generally refers to geometric primitives (points, lines, surfaces, solids) that represent discrete real-world phenomena (i.e. objects with well-defined boundaries).

4.12      function 

A rule that associates each element from a domain (source, or domain of the function) to a unique element in another domain (target, co-domain, or range).

[ISO 19107]

4.13      grid 

A network composed of two or more sets of curves in which the members of each set intersect the members of the other sets in an algorithmic way.

[ISO 19123]

NOTE: The curves partition a space into grid cells

4.14      height 

Distance of a point from a chosen reference surface measured upward along a line perpendicular to that surface.

[ISO 19111]

NOTE: A height below the reference surface will have a negative value, applying to both gravity-related and ellipsoidal heights.

4.15      map 

A pictorial representation of geographic data.

4.16      object 

An entity with a well-defined boundary and identity that encapsulates state and behavior.

[ISO 19107]

NOTE:    A GML object is an XML element of a type derived from AbstractGMLType.

4.17      pixel 

Smallest element of a digital image to which attributes are assigned.

[ISO 19101-2]

NOTE 1:   This term originated as a contraction of “picture element”

NOTE 2:   Related to the concept of a grid cell

4.18      point 

A 0-dimensional geometric primitive, representing a position.

[ISO 19107]

NOTE:       The boundary of a point is the empty set.

4.19      range 

A set of all values a function f can take as its arguments vary over its domain

4.20      rectified grid 

A grid for which there is an affine transformation between the grid coordinates and the coordinates of an external coordinate reference system.

[ISO 19123]

4.21      referenceable grid 

A grid associated with a transformation that can be used to convert grid coordinate values to values of coordinates referenced to an external coordinate reference system.

[ISO 19123]

4.22      set 

An unordered collection of related items (objects or values) with no repetition.

[ISO 19107]

5.    Conventions

5.1  Abbreviated terms

ASOC                Association

CIS                     Coverage Implementation Schema

EOP                   Earth Observation Profile

EPSG                 European Petroleum Survey Group[7] (changed to the International Association of Oil and Gas Producers)

FLIR                  Forward Looking Infrared

GeoXACML     Geospatial eXtensible Access Control Markup Language

GML                  Geography Markup Language

IETF                   Internet Engineering Task Force

JP2                     JPEG 2000 File format, cf. 15444 Part I Annex I

JPEG                 Joint Photographic Experts Group

JPX                    JPEG 2000 Extended File format, cf. 15444 Part II Annex M

RFC                   Request for Comments

SAR                   Synthetic Aperature Radar

URI                    Uniform Resource Identifier

WCS                  Web Coverage Service

WMS                 Web Map Service

XML                  Extensible Markup Language

5.2  Namespace prefix conventions

The namespace abbreviated prefixes used in this document are not normative and are merely chosen for convenience; they may appear in examples without being formally declared and have no semantic significance. The namespaces to which the prefixes correspond are normative.

6.    Roles of GML in JPEG 2000 for geographic imagery (informative)

6.1  Introduction

The description of the roles played by CIS and GMLJP2 imagery provide the context for the supporting mechanisms described in Clause 7.  When encoding information according to one of the types described in this section, the corresponding encoding mechanism specified in Clause 7 is to be used.

The role of CIS in relation to JPEG 2000 is to provide an XML encoding of the coverage metadata necessary to turn a JPEG 2000 document into either a georeferenced or georeferenceable image.  Using the CIS coverage encoding standard, this is accomplished by providing the description of the image geometry and radiometry. In addition, GML data can be used for the encoding of geographic features, annotations, annotation and feature styling, and supporting components for coordinate reference systems (CRS) and unit of measure (UoM) definitions.

The CIS and GML data are stored within the JPEG 2000 file using the XML Box mechanisms provided by the JPEG 2000 standard and the encodings described in Clause 8 of this document.

6.2  Use-cases

GMLJP2 is intended to handle a variety of imaging use cases including the following.

1.     Georeferencing of a single image, in which a coverage collection (collection or set of coverages) is used to encapsulate CIS elements to describe the geometry and the radiometry of the data. Examples include JPEG 2000 encoding of simple imagery, or JPEG 2000 responses to WMS or WCS requests.

2.     Same as 1, but for multiple images of the same type. A coverage collection is used to encapsulate CIS elements to describe the geometry and the radiometry of the constituent images. Examples include a single JPEG 2000 file that contains stereo photographic pair data, a triangulation block of images, or a collection of image tiles making up an image mosaic.

3.     Same as 2, but for images of different types. A coverage collection is used to encapsulate CIS elements to describe the geometry and the radiometry of the constituent images. Examples include a single JPEG 2000 file that contains a combination of images relating to the identification of a target and its environs, such an optical image, a FLIR dataset, and one or more SAR images.

4.     Rectified images with or without associated digital elevation models. CIS can be used to provide the geometry and, optionally, elevation information.

5.     “Referenceable” images, such as those collected by remote sensing systems, with or without associated digital elevation models. The ReferenceableGridCoverage type of CIS together with its RefererenceableGridCoverage Extension can be used to provide the geometry and, optionally, elevation information.

6.     Images that correspond to elevation data and associated metadata

7.     Images that require annotations, such as for explanatory text or simple vector graphics to communicate additional information about what the image is portraying.

8.     Images that are required to be accompanied by arbitrary feature data.  An example of this would be the replacing of a pair of files, one a GeoTIFF image and the other a Shapefile containing vector feature layer data, by a single GMLJP2 file. That a GMLJP2 file can be packaged with both kinds of data makes the example possible.

9.     Same as 1, but with additional coverage provided to indicate the semantic meaning of specific pixel (sample) values, e.g. for “no-data” or high-saturation indicators.

10.  Images that require an associated sensor model for analysis and geopositioning.  Sensor model imagery is particularly well suited to be supported by the GMLJP2ReferenceableGridCoverage type. The RefererenceableGridCoverage Extension provides a connection from the domain set of a GMLJP2ReferenceableGridCoverage to SensorML via the ReferenceableGridBySensorModel subtype.

11.  Images that require associated access rights. OGC GeoXACML is a general-purpose policy language to declare and enforce access control rights, e.g., a condition where the user can access all features inside or outside a specified geographical area.

12.  Multiple codestream encoding enables multiple images of the same or different type (different geometry, different radiometry) to be packaged in a single JPEG 2000 file. Multiple ASOC boxes within the “outer” association box labeled gml.data may refer to the different codestreams with various coverage range types, e.g., pressure and temperature, as separate codestreams with associated schemas.

13.  Images coming out from radar sensors (after SLC) .

14.  Large mosaic dataset (>10GB up to 40 GB in one single GMLJP2 file).

7.    JPEG 2000 Coverage description requirements

Clauses 7 and 8 describe the use of the CIS to describe both a coverage collection and the individual coverages for its usage in a JPEG 2000 encoding format. A Coverage collection is needed because a GMLJP2 file (dataset) may contain:

1. A single codestream (raster) associated with a single coverage with a XML encoding of the metadata necessary to make the JPEG 2000 document a georeferenced or georeferenceable image;

2. A sequence (collection) of codestreams with a sequence of corresponding coverages;

3. A single codestream associated with a single coverage, and associated features and annotations, together with styling information; or

4. A sequence (collection) of codestreams with a sequence of corresponding coverages, each coverage being associated with its features and annotations, together with styling information.

Geographic metadata may be associated to the coverage collection (the whole GMLJP2 file). This metadata is at the “aggregate” level, aggregate here being any structure of elements corresponding to cases 2 to 4. The result is a GML document providing the information of the coverage(s) and associated features, annotations and styling (if any).

Clause 7 describes details for the use of CIS to encode different aspects of the coverage data, while Clause 8 describes the complete structure of a GMLJP2 XML encoding.

Requirements class core establishes how representations of coverages, metadata, GML features, and annotations can be embedded in the JPEG 2000 encoding format. Its identifying URL is http://www.opengis.net/spec/gmljp2/2.1/req/core.

This standard depends on OGC 09-146r2, OGC Coverage Implementation Schema (February 2012) version 1.0.1 and on OGC 12-108, GML Application Schema - Coverages - JPEG 2000 Coverage Encoding Extension, for support of GMLJP2 grid coverage elements:

• gmljp2: GMLJP2GridCoverage;
• gmljp2: GMLJP2RectifiedGridCoverage; and
• gmljp2: GMLJP2ReferenceableGridCoverage.

Finally, requirements class gmljp2rgrid establishes GMLJP2ReferenceableGridCoverage as a referenceable grid coverage type that is tied to the ReferenceableGridCoverage Extension [OGC 16-083r2]. The sole clause providing the requirements for class gmljp2rgrid is section 11.

7.1  Coverage metadata

This clause describes the use of CIS to encode data associated with geographic images. This approach considers three different types of such “metadata:”

1.     “Traditional” metadata, e.g. ISO 19139 [2], in Earth Observation profile, etc.;

2.     CIS information, from the GML Coverage; and

3.     Image information, from the JPEG 2000 image header.

Some metadata can be at the coverage collection level and other metadata at the coverage level. Some metadata origins can be redundant, and the requirements provided here specify precedence.

At the coverage collection level, the JPEG 2000 header metadata provides information about the number of codestreams. At the individual coverage level, JPEG 2000 header metadata provides information about the number of rows and columns, the number of resolution levels, and eventually an internal tiling schema. CIS provides a metadata property, gmlcov:metadata, that can be attached to any CIS object and can be used to encode metadata about the coverage. The GML metadata property, gml:metaDataProperty, can be attached to any GML object and is only intended for metadata about extra elements that the GMLJP2 encodes such as GML features or annotations.

Both gmlcov:metadata and gml:metaDataProperty can either point (via xlink:href) to a metadata property package expressed via a GML metadata application schema, or enclose a bundle of such metadata properties in-line. This can be an ISO19139 document, an EOP XML description, or a custom supported, user-defined metadata schema. Some elements can be redundant in more than one description.  It is the responsibility of the data provider to avoid redundant information.

Note:   gml:metaDataProperty is intended for metadata about extra GML features, annotations, etc.

It is possible to include metadata in the coverage information in several formats. One possibility is to use ebRIM:RegistryObject as the first class element. Another is to include an ISO19139 metadata description in XML. Table 2 summarizes the different alternatives that are directly possible using the XML schema provided (see Annex D for examples).

The following instance illustrates how to embed ISO19115/19139 metadata:

<?xml version=“1.0” encoding=“UTF-8”?>
<gmljp2:GMLJP2CoverageCollection gml:id="JPEG 2000_0">
  <gmljp2:featureMember>
   <gmljp2:GMLJP2RectifiedGridCoverage gml:id="CodeStream0">
   …
    <gmlcov:metadata>
      <gmljp2:Metadata>
       <gmljp2:isoMetadata>
         <gmd:MD_Metadata>
          <gmd:fileIdentifier/>
          <gmd:characterSet/>
          <gmd:parentIdentifier/>
          <gmd:hierarchyLevelName/>
          <gmd:contact/>
          <gmd:dateStamp/>
          <gmd:identificationInfo>
           <gmd:MD_DataIdentification>
             <gmd:citation>
              <gmd:CI_Citation>
                <gmd:title/>
                <gmd:alternateTitle/>
                <gmd:date/>
              </gmd:CI_Citation>
             </gmd:citation>
             <gmd:abstract/>
             <gmd:resourceFormat/>
             <gmd:language/>
             <gmd:extent>
              <gmd:EX_Extent/>
             </gmd:extent>
           </gmd:MD_DataIdentification>
          </gmd:identificationInfo>
         </gmd:MD_Metadata>
       </gmljp2:isoMetadata>
      </gmljp2:Metadata>
    </gmlcov:metadata>
   </gmljp2:GMLJP2RectifiedGridCoverage>
  </gmljp2:featureMember>
</gmljp2:GMLJP2CoverageCollection>

Earth Observation data products are generally managed within logical collections that are usually structured to contain data items derived from sensors onboard a satellite or series of satellites. The key characteristics differentiating products within the collections are date of acquisition, location, as well as characteristics depending on the type of sensor. For example, key characteristics for optical imagery are the possible presence of cloud, haze, smoke, or other atmospheric or on-ground phenomena obscuring the image.

The common metadata used to distinguish Earth Observation (EO) products types are presented in this document for generic and thematic EO products (i.e., optical, radar, atmospheric, altimetry, limb-looking, and synthesis and systematic products). This can be done with the Earth Observation profile metadata.

An example on how to embed EO profile metadata is Annex D.2.

Annex D provides more examples of how metadata (including ISO19115 and Earth Observation Profile) can be embedded in an XML file.

7.2  Image annotation

An image’s annotation can be defined as an association between an annotation entity (e.g., a text label) and an image or some geometric “region” within the image. Annotations can be provided in image coordinates (pixels), or in a CRS coordinates defined by the CIS reference part (e.g. GML), or in a common CRS in case it would be different from the CRS defined by the CIS coverage. Annotations provide an association between geometric “regions” (0-d, 1-d, 2-d, etc.) in an image and annotation text, imagery, video, and feature references. Annotations are deeply linked to styles for visual presentation. An annotation can be thought of as drawing attention to some “region” of an image.

See section 12 for a more complete (informative) reference to annotation approaches.  Note that section 12 is not normative.

7.3  Geographic features

Geographic features, e.g. features obtained from an image by image interpretation, can be packaged inside the JPEG 2000 image. Such features may be directly associated with a particular image in the JPEG 2000 file or may be independent of the image altogether.

Encoding of features need an associated GML application schema.

7.4  Feature styling

Geographic features in GML express geographic content. Visual presentation of such geographic features requires a styling mechanism to interpret and transform the GML features into graphical objects (e.g. SVG or OGC KML).

For example, styling rules can be expressed using the following approaches:

•  OGC Styled Layer Descriptors / Symbology Encoding

•  OGC GML default styling

•  OGC KML fragments

7.5  Coordinate reference systems

For coverage geometries, the geometric properties of GML features and annotations include coordinates which are interpreted within the context of a coordinate reference system (CRS). According to the GML encoding rules, the coordinate reference system is specified via URI. This URI may identify the CRS by reference to an authority and an authority-maintained code. Alternatively, these URI may identify the physical location of a CRS definition.

References to Coordinate Reference Systems (CRS) may take one of the following forms:

· For reference to an authority and authority-maintained code, as documented in OGC 11-135, see http://www.opengis.net/def/crs/ for the OGC defined CRSs; or

· Reference to CRS definition.

In those cases where an actual CRS definition is required, GML provides a grammar for encoding such coordinate reference systems. The coordinate reference system definitions encoded in GML can then be packaged with the JPEG 2000 data (as for features, etc.) and referenced from the coverage description or features or can exist externally. This enables both network-centric and standalone implementations of GML and JPEG 2000 to be deployed.

Some coordinate reference systems may require use of a GML coordinate reference system application schema. Mechanisms for referencing and/or transporting GML application schemas are discussed in Clause 9.

There is no default CRS. There is only one CRS for each RectifiedGridCoverage, which is expressed using the gml:RectifiedGrid element (in srsName) in the domainSet. Other sub-elements may also duplicate this srsName definition.

Note: GMLJP2 rectified grids follow the recommendation in GML 3.2.1 [OGC 07-036] subclause 19.2.2.  This corresponds with the pixelInCell value of ImageCRS set to “Cell center” as specified in ISO 19111. This can be interpreted as the origin of the RectifiedGrid is the center point of the first image pixel.

7.6  Units of measure

Coverage values, properties of GML features, and annotations may employ references to units of measure (UoM). According to the GML rules, references to Units of Measure may take one of the following two forms:

· For reference to an authority and authority-maintained code, in a similar way as for CRSs, as documented in OGC 11-135, see http://www.opengis.net/def/uom/; some of them are also defined in:

http://schemas.opengis.net/definitions/1.1.0/unitsDictionaryv1.xml; or

· A reference to a UOM definition (see Subclause 7.7).

7.7  Reference to UOM definition

Coverage value units are defined in gmlcov:rangeType/swe:DataRecord/swe:uom.

Recommendation: The use of the unitless “unity” unit of measure is recommended (instead of “unknown”) for values without unit of measure, when the swe:uom element is mandatory:

<swe:uom code=“unity”/>         <!– Unity for value without unit of measures –>

Informatively, the definitions of some units of measure and the equivalent URIs are listed in Table 3. Many units can be also specified using EPSG URIs.

Units of Measure definitions may be optionally included as dictionary entries in an XML box (see Clause 8) within the JPEG 2000 file. In those cases where an actual UOM definition is required, GML provides a grammar for the encoding of such units of measure. The units of measure definitions encoded in GML can then be packaged with the JPEG 2000 data (as for features, etc.) and referenced from the coverage description or features or can exist externally. This enables both network-centric and standalone implementations of GML and JPEG 2000 to be deployed. Mechanisms for referencing and/or transporting GML application schemas are discussed in Clause 10.

7.8  Nil values

The semantic intent for sample values in a coverage dataset, such as for “nodata” pixels or samples (nil values), whose values were invalid, not acquired, or were clipped due to high or low saturation, should be specified. Possible reasons for NIL values can be seen in Table 4, which are taken from http://www.opengis.net/def/nil/OGC/0/, while others are defined in OGC 07-036 section 8.2.3.1 on gml:NilReasonType.

Although it is the client’s job to interpret such special values, this standard does not require that a client be able to interpret those values.  Informatively, the definitions of some reasons and the equivalent URIs are listed in Table 4.

8.    Encoding rules for GML in JPEG 2000

8.1  Introduction

This clause specifies the requirements that shall be followed when encoding XML data for use within JPEG 2000 files. The primary role of GML in relation to JPEG 2000 is to provide a geographic context to the imagery placed in JPEG 2000 files. This is accomplished by providing a CIS description of the image geometry (domainSet) and radiometry (rangeType). In addition, GML data can be used, as described in this clause, for the encoding of metadata, geographic features, annotations, annotation and feature styling, and supporting components for coordinate reference systems and unit of measure definitions.

<gml:domainSet nilReason="inapplicable"/>
 <gml:rangeSet>
      <gml:DataBlock>
         <gml:rangeParameters nilReason="inapplicable"/>
         <gml:doubleOrNilReasonTupleList>inapplicable</gml:doubleOrNilReasonTupleList>
      </gml:DataBlock>
 </gml:rangeSet>
 <gmlcov:rangeType>
      <swe:DataRecord>
         <swe:field name="Collection"> </swe:field>
      </swe:DataRecord>
 </gmlcov:rangeType>

Child elements of GMLJP2CoverageCollection are described in Tables 5 and 6 and in the following text. The structure of the GMLJP2 data types is represented as a UML diagram in the Annex B.

Note: For a very large GML document, we strongly recommended using the GML xlink.href mechanism to link to the GML document instead of embedding the data inline.

Future extensions of this standard may define concrete GML application schemas to describe features for specific applications.

Future extensions of this standard may define specific encoding for transporting annotations for specific applications (see section 12).

For example, the gmljp2:style element can include an SLD as a style layer description that describes styles of the gmljp2:feature element.

Extensions of this standard may further define other child elements of the gmljp2:GMLJP2CoverageType in the future.

A schema defining GMLJP2 XML usage is provided in this standard that includes CIS 1.0, GML 3.2, ISO metadata, DC (Dublin Core) metadata, and EOP (Earth Observation Profile) metadata.

All child elements in the gmljp2:GMLJP2CoverageType are derived from gml:AssociationAttributeGroup and as such can be described either in-line or by reference (via xlink:href).

The following example begins with the GMLJP2CoverageCollection root element that contains one or more coverage subelements.  A GMLJP2CoverageCollection also supports metadata and feature data, which may be included either inline or referenced via xlink:href.  In the example, a single GMLJP2RectifiedGridCoverage instance as well as metadata and feature data descriptions are provided inline:

<gmljp2:GMLJP2CoverageCollection gml:id="JPEG 2000_0"
 xsi:schemaLocation="http://www.opengis.net/gmljp2/2.1 gmlJP2.xsd"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:gmlcov="http://www.opengis.net/gmlcov/1.0"
xmlns:gmljp2="http://www.opengis.net/gmljp2/2.1"
xmlns:gmd="http://www.isotc211.org/2005/gmd"
xmlns:gco="http://www.isotc211.org/2005/gco"
xmlns:swe="http://www.opengis.net/swe/2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <gml:domainSet nilReason=“inapplicable”/>
 <gml:rangeSet>
   <gml:DataBlock>
    <gml:rangeParameters nilReason=“inapplicable”/>
    <gml:doubleOrNilReasonTupleList>inapplicable</gml:doubleOrNilReasonTupleList>
   </gml:DataBlock>
 </gml:rangeSet>
 <gmlcov:rangeType>
   <swe:DataRecord>
    <swe:field name="Collection"> </swe:field>
   </swe:DataRecord>
 </gmlcov:rangeType>
  <gmljp2:featureMember>
   <gmljp2:GMLJP2RectifiedGridCoverage gml:id="ID_1">
   <gml:boundedBy>
    <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326"
       axisLabels="Lat Long" uomLabels="deg deg" srsDimension="2">
      <gml:lowerCorner>9.9 9.9</gml:lowerCorner>
      <gml:upperCorner>14.9 12.9</gml:upperCorner>
    </gml:Envelope>
   </gml:boundedBy>
   <gml:domainSet>
      <gml:RectifiedGrid gml:id="rg0001_C0002" dimension="2"
           srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
       <gml:limits>
         <gml:GridEnvelope>
          <gml:low>1 1</gml:low>
          <gml:high>3 10</gml:high>
         </gml:GridEnvelope>
       </gml:limits>
       <gml:axisLabels>Lat Long</gml:axisLabels>
       <gml:origin>
         <gml:Point gml:id="P0001">
          <gml:pos>9.9 9.9</gml:pos>
         </gml:Point>
       </gml:origin>
       <gml:offsetVector>0 3.71e-005</gml:offsetVector>
       <gml:offsetVector>-3.71e-005 0</gml:offsetVector>
      </gml:RectifiedGrid>
    </gml:domainSet>
    <gml:rangeSet>
      <gml:File>
       <gml:rangeParameters/>
       <gml:fileName>gmljp2://codestream/0</gml:fileName>
       <gml:fileStructure>inapplicable</gml:fileStructure>
      </gml:File>
    </gml:rangeSet>
    <gmlcov:rangeType>
      <swe:DataRecord>
       <swe:field name=“Panchromatic”>
         <swe:Quantity definition=“http://www.opengis.net/def/ogc-eo/opt/SpectralMode/PANCHROMATIC”>
          <swe:description>Panchromatic Channel</swe:description>
          <swe:uom code=“unity”/>
          <!– Unity for value without unit of measures –>
         </swe:Quantity>
       </swe:field>
      </swe:DataRecord>
    </gmlcov:rangeType>   
    <gmlcov:metadata>
      <gmljp2:Metadata>
       <gmljp2:isoMetadata>
         <gmd:MD_Metadata>
          <gmd:fileIdentifier/>
          <gmd:characterSet/>
          <gmd:parentIdentifier/>
          <gmd:hierarchyLevelName/>
          <gmd:contact/>
          <gmd:dateStamp/>
          <gmd:identificationInfo>
           <gmd:MD_DataIdentification>
             <gmd:citation>
              <gmd:CI_Citation>
                <gmd:title/>
                <gmd:alternateTitle/>
                <gmd:date/>
              </gmd:CI_Citation>
             </gmd:citation>
             <gmd:abstract/>
             <gmd:resourceFormat/>
             <gmd:language/>
             <gmd:extent>
              <gmd:EX_Extent/>
             </gmd:extent>
           </gmd:MD_DataIdentification>
          </gmd:identificationInfo>
         </gmd:MD_Metadata>
       </gmljp2:isoMetadata>
      </gmljp2:Metadata>
    </gmlcov:metadata>
   </gmljp2:GMLJP2RectifiedGridCoverage>
  </gmljp2:featureMember>
   <gmljp2:featureMember>
   <gmljp2:GMLJP2Features gml:id="ID_FE_2">
    <gmljp2:feature>
      <gml:FeatureCollection gml:id="ID_07">
       <gml:featureMember>
         <gml:Observation gml:id="ID_08">
          <gml:validTime/>
          <gml:resultOf/>
         </gml:Observation>
       </gml:featureMember>
      </gml:FeatureCollection>
    </gmljp2:feature>
   </gmljp2:GMLJP2Features>
  </gmljp2:featureMember>
</gmljp2:GMLJP2CoverageCollection>

8.2  CIS for JPEG 2000

CIS defines the associated JPEG 2000 file as a geospatial 2d coverage.

Such coverage descriptions are based directly on the CIS namespace gmlcov and do not require the definition of a specific application schema for each JPEG 2000 instance. There can be only ONE element of the gmlcov:AbstractCoverageType per codestream even though the CIS element can describe more than one field (band) if the codestream also describes more than one field or band. Clause 9 provides details on the mapping of coverage description instances and codestreams in the multiple codestream case.

The following sketches a valid CIS XML file that describes a single field (one band) embedded in a JPEG 2000 XML box. Please note the use of fileName and fileStructure:

<gmljp2:GMLJP2CoverageCollection gml:id="CCID1"
 xmlns:gml="http://www.opengis.net/gml/3.2"
 xmlns:gmlcov="http://www.opengis.net/gmlcov/1.0"
 xmlns:gmljp2="http://www.opengis.net/gmljp2/2.1"
 xmlns:swe="http://www.opengis.net/swe/2.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.opengis.net/gmljp2/2.1 
 http://schemas.opengis.net/gmljp2/2.1/gmljp2.xsd">
   <!– Note: The Coverage container defines a collection grid limited to a single point
 whose value is set to 0; its domainSet is defined by a .Grid restricted to a single point
 whose value is 0 (in order to fulfil Requirement 11), whose rangeType field name is “Collection” –>
 <gml:domainSet nilReason=“inapplicable”/>
 <gml:rangeSet>
   <gml:DataBlock>
    <gml:rangeParameters nilReason=“inapplicable”/>
  <gml:doubleOrNilReasonTupleList>inapplicable</gml:doubleOrNilReasonTupleList>
   </gml:DataBlock>
 </gml:rangeSet>
 <gmlcov:rangeType>
   <swe:DataRecord>
    <swe:field name="Collection"> </swe:field>
   </swe:DataRecord>
 </gmlcov:rangeType>
   <gmljp2:featureMember>
      <gmljp2:GMLJP2RectifiedGridCoverage gml:id="RGC01_CCID1">
         <gml:boundedBy>
                 <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326"
                    axisLabels="Lat Long" uomLabels="deg deg" srsDimension="2">
              <gml:lowerCorner>1.0 1.0</gml:lowerCorner>
              <gml:upperCorner>3.0 10.0</gml:upperCorner>
           </gml:Envelope>
         </gml:boundedBy>
         <gml:domainSet>
           <gml:RectifiedGrid gml:id="RG_RGC01_CCID1"
               dimension="2" srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
              <gml:limits>
                 <gml:GridEnvelope>
                    <gml:low>0 0</gml:low>
                    <gml:high>99 29</gml:high>
                 </gml:GridEnvelope>
              </gml:limits>
              <gml:axisLabels>Lat Long</gml:axisLabels>
              <gml:origin>
                 <gml:Point gml:id="P0001_RGC01_CCID1">
                    <!– “Upper-left” image origin –>
                    <gml:pos>2.95 1.05</gml:pos>
                 </gml:Point>
              </gml:origin>
              <gml:offsetVector>0 0.1</gml:offsetVector>
              <gml:offsetVector>-0.1 0</gml:offsetVector>
           </gml:RectifiedGrid>
         </gml:domainSet>
         <gml:rangeSet>
           <gml:File>
              <gml:rangeParameters/>
              <gml:fileName>gmljp2://codestream/0</gml:fileName>
              <gml:fileStructure>Record Interleaved</gml:fileStructure>
           </gml:File>
         </gml:rangeSet>
         <gmlcov:rangeType>
           <swe:DataRecord>
              <swe:field name="Panchromatic">
                 <swe:Quantity definition="http://www.opengis.net/def/ogc-eo/opt/SpectralMode/PANCHROMATIC">
                    <swe:description>Panchromatic Channel</swe:description>
                    <swe:uom code="unity"/>
                    <!– Unity for value without unit of measures –>
                 </swe:Quantity>
              </swe:field>
           </swe:DataRecord>
         </gmlcov:rangeType>
      </gmljp2:GMLJP2RectifiedGridCoverage>
   </gmljp2:featureMember>
</gmljp2:GMLJP2CoverageCollection>

9.    Packaging GML in JPEG 2000

9.1  Introduction

This clause describes the mechanisms for packaging coverage information data and eventual GML application schemas inside JPEG 2000 data files. It also provides rules for encoding references between GML instances and GML application schemas, and between GML instances. Finally, it provides the rules for associating coverage descriptions (see Clauses 6 and 7) and JPEG 2000 codestreams.

9.2  Use of JPEG 2000 boxes

The JPEG 2000 file format is defined as a contiguous set of boxes, where a box is defined as an abstract data structure used to hold arbitrary data. Different types of boxes are defined to contain different kinds of data: for example, the codestream and XML box types are used to contain, respectively, wavelet-encoded image data and XML data.  Additionally, certain types of boxes known as super-boxes may contain other boxes.

This standard requires the use of three types of boxes in order to store and reference GML data in the JPEG 2000 file.

•  The ASOC (Association) super-box contains at least two child boxes and is used to declare a relationship between the first child box and the remaining children.

•  The LBL (Label) box is used to contain a short string, typically serving as an identifier.

•  The XML box is used to contain XML data, e.g. GMLJP2 instances.

All GML instance, schema, and dictionary data are stored in XML boxes or will be linked to external files. An example JPEG 2000 file with an association box structure is shown in Figure 4.

For convenience, M6.2 of ISO 15444-2 is repeated here:

“- M.6.2 Expression representation

The expressions of the requirements to fully understand all aspects, and to display the file as desired are stored in the Reader Requirements box, which is a mandatory feature of a JPX file format. If the Reader Requirements box is not present, the File Type box describes the full functionality of the file.”

In Table M.13 of ISO 15444-2, the Reader Requirements box is identified as Required.

•  However, in case of absence, “If the Reader Requirements box is not present, the File Type box describes the full functionality of the file.”

•  use of “Brand field in File type box:” The brand field shall always be “jpx040” for JPX files.

According to Subclause 3.2 of [ISO N2887], the presence of GML data in a JPX file can be signaled using the Reader Requirements box (defined in Annex M of [ISO 15444-2]) with a value of 67 (XMLGISMetaData) as the SF (standard flag) in paragraph M.11.1, meaning that the file contains GML data based on the OGC GML standard. The data is then packaged in XML data which is annotated with JPX labels, where the annotation works via the “association” (ASOC) box of part 2. The topmost ASOC box will contain an LBL box whose content is "gml.data" and several additional ASOC boxes, of which each of them contains an LBL box giving a name to the data, and an XML box containing the actual GML payload data.

The Reader Requirements box should respect the required field structure as defined in the ISO 15444-2 standard. The FUAM field should be correctly set to interpret the standard flag value for the GML content.

9.3  Use of JPEG 2000 Part I and Part II extensions

It is recommended using the JPEG 2000 Part I (ISO 15444-1) that is widely implemented, defines the core JPEG 2000, and includes the syntax of the JPEG 2000 codestream.

Because the association and label boxes are defined by Part II of the JPEG 2000 standard, all GMLJP2 files SHALL implement the JPX file format as defined in [ISO 15444-2], to the extent required to support those box types.

NOTE:   These two box types are the only Part II extensions used by the GMLJP2 standard.

Note: GML instance data can be composed by a coverage description, metadata instances, annotation instances and feature instances and future extended elements.

The minimal structure case for the XML box packaging for a single codestream and for a multiple codestream is the same as shown in figure 5.

XML schemas, CRS dictionaries or units of measure dictionaries can be stored as external XML files and referenced from the GMLJP2 file. In case that there is a need for storing them in the file, any number of association boxes may follow the gml.root-instance box as containers for them.

This label is used in references to the XML box content using the mechanism described in Subclause 10.6.

Note: the above boxes can also be stored as external XML files and referenced from the GMLJP2 file.

10. XML references in a JPEG 2000 package

This clause describes the GMLJP2 URI syntax, a URI structure for references to schemas (xsi:schemaLocation) and instance elements or dictionary instance boxes, other XML data, or non-XML data through the use of URI references, e.g., xlink:href, gml:uom, gml:srsName, gml:resultOf.  These can reside either externally or within the JPEG 2000 file.

10.1  References to XML schemas

GML instance data may reference a supporting XML schema (specifically, a GML application schema) through the XML schema location attribute (xsi:schemaLocation) whose value is a list of URI pairs (namespace, schemaLocation).

This standard has been crafted in such a way that common uses (such as geographical georeferencing or including ISO metadata) do not require using new or pre-existing application schema(s) for each JPEG 2000 instance. Therefore, using or referencing elements from the official OGC or ISO schemas is usually sufficient. Nevertheless, it is possible that one may need to define schema describing one’s own GML feature types and feature collections, or perhaps one’s own metadata set.  Such application schema may be accessed via the web, using xlink:href, or located within a different XML box within the same image file.

For convenience, these rules are repeated here:

Given a namespace name (or none) and (optionally) a URI reference from xsi:schemaLocation or xsi:noNamespaceSchemaLocation, schema-aware processors may implement any combination of the following strategies, in any order:

1.   Do nothing, for instance because a schema containing components for the given namespace name is already known to be available, or because it is known in advance that no efforts to locate schema documents will be successful (for example in embedded systems);

2.   Based on the location URI, identify an existing schema document, either as a resource which is an XML document or a <schema> element information item, in some local schema repository;

3.   Based on the namespace name, identify an existing schema document, either as a resource which is an XML document or a <schema> element information item, in some local schema repository;

4.   Attempt to resolve the location URI, to locate a resource on the web which is or contains or references a <schema> element; or

5.   Attempt to resolve the namespace name to locate such a resource.

Whenever possible, configuration and/or invocation options for selecting and/or ordering the implemented strategies are to be provided.

10.2  External references

References to external application schemas are possible and recommended for the common general schemas.

Note that the relative reference meaning has been changed from the original version 1.0 of this standard. In version 1.0, the reference to the schemaLocation was done by URI using the GMLJP2 URI convention, with such references referring to schemas within the JPEG 2000 file.

10.3  Internal references within a JPEG 2000 file.

NOTE 1:     For resource.type with xml codestream values for resource.id, the xml codestream values depend upon the value of resource.type, as explained below.

NOTE 2:     For resource.type with values for fragment-id, the values for fragment-id depend on the value of resource.type.

10.4  Internal references to XML boxes within a JPEG 2000 file

Note: label text is arbitrary and is constrained only by the syntactical restrictions of the URI [IETF 2396] and of the label box in JPEG 2000 [ISO 15444-2].

GML instance documents may use URIs of this form to import schema, dictionary entries, or other XML data stored in the gml.data box.

EXAMPLE 1 gmljp2://xml/myschema.xsd

Identifies a schema in the XML box labelled myschema.xsd.

EXAMPLE 2 gmljp2://xml/uom.xml

Identifies a UOM dictionary in the XML box labelled uom.xml.

EXAMPLE 3 gmljp2://xml/uom.xml#meter

Identifies the meter entry in the UOM dictionary in the XML box labelled uom.xml.

Note that instances, e.g. GML elements, can only be referenced within labeled boxes.

This is an example of a notation that follows the above requirements:

<gmljp2:GMLJP2CoverageCollection gml:id="CCID1"
 xmlns:gml="http://www.opengis.net/gml/3.2"
 xmlns:gmlcov="http://www.opengis.net/gmlcov/1.0"
 xmlns:gmljp2="http://www.opengis.net/gmljp2/2.1"
 xmlns:swe="http://www.opengis.net/swe/2.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.opengis.net/gmljp2/2.1 
 http://schemas.opengis.net/gmljp2/2.1/gmljp2.xsd">
<gml:domainSet nilReason=“inapplicable”/>
 <gml:rangeSet>
   <gml:DataBlock>
    <gml:rangeParameters nilReason=“inapplicable”/>
    <gml:doubleOrNilReasonTupleList>inapplicable</gml:doubleOrNilReasonTupleList>
   </gml:DataBlock>
 </gml:rangeSet>
 <gmlcov:rangeType>
   <swe:DataRecord>
    <swe:field name="Collection"> </swe:field>
   </swe:DataRecord>
 </gmlcov:rangeType>
   <gmljp2:featureMember>
      <gmljp2:GMLJP2RectifiedGridCoverage gml:id="RGC01_CCID1">
         <gml:boundedBy>
           <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326"
                axisLabels="Lat Long" uomLabels="deg deg" srsDimension="2">
              <gml:lowerCorner>1.0 1.0</gml:lowerCorner>
              <gml:upperCorner>3.0 10.0</gml:upperCorner>
           </gml:Envelope>
         </gml:boundedBy>
         <gml:domainSet>
           <gml:RectifiedGrid gml:id="RG_RGC01_CCID1" dimension="2"
                srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
              <gml:limits>
                 <gml:GridEnvelope>
                    <gml:low>0 0</gml:low>
                    <gml:high>99 29</gml:high>
                 </gml:GridEnvelope>
              </gml:limits>
              <gml:axisLabels>Lat Long</gml:axisLabels>
              <gml:origin>
                 <gml:Point gml:id="P0001_RGC01_CCID1">
                    <!– “Upper-left” image origin –>
                    <gml:pos>2.95 1.05</gml:pos>
                 </gml:Point>
              </gml:origin>
              <gml:offsetVector>0 0.1</gml:offsetVector>
              <gml:offsetVector>-0.1 0</gml:offsetVector>
           </gml:RectifiedGrid>
         </gml:domainSet>
         <gml:rangeSet>
           <gml:File>
              <gml:rangeParameters/>
              <gml:fileName>gmljp2://codestream/0</gml:fileName>
              <gml:fileStructure>Record Interleaved</gml:fileStructure>
           </gml:File>
         </gml:rangeSet>
         <gmlcov:rangeType>
           <swe:DataRecord>
              <swe:field name="Panchromatic">
                 <swe:Quantity definition="http://www.opengis.net/def/ogc-eo/opt/SpectralMode/PANCHROMATIC">
                    <swe:description>Panchromatic Channel</swe:description>
                    <swe:uom code="unity"/>
                    <!– Unity for value without unit of measures –>
                 </swe:Quantity>
              </swe:field>
           </swe:DataRecord>
         </gmlcov:rangeType>
      </gmljp2:GMLJP2RectifiedGridCoverage>
   </gmljp2:featureMember>
</gmljp2:GMLJP2CoverageCollection>

10.5  Internal references to codestream within a JPEG 2000 file

where [codestream-number] is an integer, greater than or equal to 0, that identifies a particular codestream in the JPEG 2000 file.  By convention, codestreams are to be numbered in lexical order of their appearance in the file.

GML instance documents may use URIs of this form to refer to particular codestreams in the file.

EXAMPLE 1 gmljp2://codestream/0

Identifies the first codestream in the file.

EXAMPLE 2 gmljp2://codestream/1

Identifies the second codestream in the file.

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; in other words, the codestream IDs are always in a strictly increasing order starting from 0.

10.6   Codestream references

10.6.1   Single codestream case

A single JPEG 2000 codestream is used to represent a single geospatial 2D coverage. The GML data (instance data, schemas) associated within this codestream are contained in an association box as discussed in Clause 9.

10.6.2   Minimal instance example for a single codestream

At a minimum GML data consists of a root gmljp2:GMLJP2CoverageCollection that is a collection of codestream-specific coverage information, which in turn contains a concrete CIS gmlcov:AbstractCoverage member instance. This simple RectifiedGridCoverage example given below demonstrates the CIS portion of the encoding of a georectified image as a CIS coverage.

<gmljp2:GMLJP2CoverageCollection gml:id="CCID1"
 xmlns:gml="http://www.opengis.net/gml/3.2"
 xmlns:gmlcov="http://www.opengis.net/gmlcov/1.0"
 xmlns:gmljp2="http://www.opengis.net/gmljp2/2.1"
 xmlns:swe="http://www.opengis.net/swe/2.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.opengis.net/gmljp2/2.1 
http://schemas.opengis.net/gmljp2/2.1/gmljp2.xsd">
 <gml:domainSet nilReason=“inapplicable”/>
 <gml:rangeSet>
   <gml:DataBlock>
    <gml:rangeParameters nilReason=“inapplicable”/>
  <gml:doubleOrNilReasonTupleList>inapplicable</gml:doubleOrNilReasonTupleList>
   </gml:DataBlock>
 </gml:rangeSet>
 <gmlcov:rangeType>
   <swe:DataRecord>
    <swe:field name="Collection"> </swe:field>
   </swe:DataRecord>
 </gmlcov:rangeType>
   <gmljp2:featureMember>
      <gmljp2:GMLJP2RectifiedGridCoverage gml:id="RGC01_CCID1">
         <gml:boundedBy>
           <!– Note: This boundedBy element for each Coverage member is recommended. –>
           <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326"
             axisLabels="Lat Long" uomLabels="deg deg" srsDimension="2">
              <gml:lowerCorner>1.0 1.0</gml:lowerCorner>
              <gml:upperCorner>3.0 10.0</gml:upperCorner>
           </gml:Envelope>
         </gml:boundedBy>
         <gml:domainSet>
           <gml:RectifiedGrid gml:id="RG_RGC01_CCID1" dimension="2"
               srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
              <gml:limits>
                 <gml:GridEnvelope>
                    <gml:low>0 0</gml:low>
                    <gml:high>99 29</gml:high>
                 </gml:GridEnvelope>
              </gml:limits>
              <gml:axisLabels>Lat Long</gml:axisLabels>
              <gml:origin>
                 <gml:Point gml:id="P0001_RGC01_CCID1">
                    <!– “Upper-left” image origin –>
                    <gml:pos>2.95 1.05</gml:pos>
                 </gml:Point>
              </gml:origin>
              <gml:offsetVector>0 0.1</gml:offsetVector>
              <gml:offsetVector>-0.1 0</gml:offsetVector>
           </gml:RectifiedGrid>
         </gml:domainSet>
         <gml:rangeSet>
           <gml:File>
              <gml:rangeParameters/>
              <gml:fileName>gmljp2://codestream/0</gml:fileName>
              <gml:fileStructure>Record Interleaved</gml:fileStructure>
           </gml:File>
         </gml:rangeSet>
         <gmlcov:rangeType>
           <swe:DataRecord>
              <swe:field name="Panchromatic">
                 <swe:Quantity definition="http://www.opengis.net/def/ogc-eo/opt/SpectralMode/PANCHROMATIC">
                    <swe:description>Panchromatic Channel</swe:description>
                    <swe:uom code="unity"/>
                    <!– Unity for value without unit of measures –>
                 </swe:Quantity>
              </swe:field>
           </swe:DataRecord>
         </gmlcov:rangeType>
      </gmljp2:GMLJP2RectifiedGridCoverage>
   </gmljp2:featureMember>
</gmljp2:GMLJP2CoverageCollection>

Note that, as GMLJP2RectifiedGridCoverage is based on gmlcov:RectifiedGridCoverage of CIS, it is necessary that rangeSet be defined in the GMLJP2RectifiedGridCoverage instance. However, for GMLJP2 the range data is actually stored within the codestream in the JPEG 2000 file: there is no “file structure” to be specified.  The rangeSet members are therefore set to “inapplicable” except fileName that is set to gmljp2://codestream/{codestream_number}.

10.6.3    Multiple codestreams case

The multiple codestream encoding enables multiple images of the same or different type (different geometry, different radiometry) to be packaged in a single JPEG 2000 file. Stereo image pairs, triangulation blocks, orthoimagery with associated digital elevation models, and multi-source image assessment are examples of the use of multiple codestreams.

Note: The order of the gmljp2:GMLJP2RectifiedGridCoverage and gmljp2:GMLJP2ReferenceableGridCoverage elements will usually be the same as their respective codestreams, but the actual association of a gmljp2:GMLJP2Coverage element with its codestream is done by the fileName element in the rangeSet.

Some parts of the GMLJP2 XML could be repeated in the description of several codestreams. In this case, the use of gml:id and xlink:href general GML mechanism can be used to reference elements and avoid duplication.

The root element GMLJP2CoverageCollection can describe a collection of codestreams.  The first codestream is described by the 1^st sub-elements of the collection and the next ones by further GMLJP2Coverage elements. The nested coverage collection description is shown in the example.

10.6.4    Minimal instance example for multiple codestreams

The GML data, at the minimum, consists of a root gmljp2:GMLJP2RectifiedGridCoverage for each codestream.

<gmljp2:GMLJP2CoverageCollection gml:id="CCID1"
 xmlns:gml="http://www.opengis.net/gml/3.2"
 xmlns:gmlcov="http://www.opengis.net/gmlcov/1.0"
 xmlns:gmljp2="http://www.opengis.net/gmljp2/2.1"
 xmlns:swe="http://www.opengis.net/swe/2.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.opengis.net/gmljp2/2.1 
 http://schemas.opengis.net/gmljp2/2.1/gmljp2.xsd">
 <gml:domainSet nilReason=“inapplicable”/>
 <gml:rangeSet>
   <gml:DataBlock>
    <gml:rangeParameters nilReason=“inapplicable”/>
  <gml:doubleOrNilReasonTupleList>inapplicable</gml:doubleOrNilReasonTupleList>
   </gml:DataBlock>
 </gml:rangeSet>
 <gmlcov:rangeType>
   <swe:DataRecord>
    <swe:field name="Collection"> </swe:field>
   </swe:DataRecord>
 </gmlcov:rangeType>
   <gmljp2:featureMember>
      <gmljp2:GMLJP2RectifiedGridCoverage gml:id="RGC01_CCID1">
         <gml:boundedBy>
           <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326"
                axisLabels="Lat Long" uomLabels="deg deg" srsDimension="2">
              <gml:lowerCorner>1.0 1.0</gml:lowerCorner>
              <gml:upperCorner>3.0 10.0</gml:upperCorner>
           </gml:Envelope>
         </gml:boundedBy>
         <gml:domainSet>
           <gml:RectifiedGrid gml:id="RG_RGC01_CCID1" dimension="2"
                  srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
              <gml:limits>
                 <gml:GridEnvelope>
                    <gml:low>0 0</gml:low>
                    <gml:high>99 29</gml:high>
                 </gml:GridEnvelope>
              </gml:limits>
              <gml:axisLabels>Lat Long</gml:axisLabels>
              <gml:origin>
                 <gml:Point gml:id="P0001_RGC01_CCID1">
                    <!– “Upper-left” image origin –>
                    <gml:pos>2.95 1.05</gml:pos>
                 </gml:Point>
              </gml:origin>
              <gml:offsetVector>0 0.1</gml:offsetVector>
              <gml:offsetVector>-0.1 0</gml:offsetVector>
           </gml:RectifiedGrid>
         </gml:domainSet>
         <gml:rangeSet>
           <gml:File>
              <gml:rangeParameters/>
              <gml:fileName>gmljp2://codestream/0</gml:fileName>
              <gml:fileStructure>Record Interleaved</gml:fileStructure>
           </gml:File>
         </gml:rangeSet>
         <gmlcov:rangeType>
           <swe:DataRecord>
              <swe:field name="Panchromatic">
                 <swe:Quantity definition="http://www.opengis.net/def/ogc-eo/opt/SpectralMode/PANCHROMATIC">
                    <swe:description>Panchromatic Channel</swe:description>
                    <swe:uom code="unity"/>
                    <!– Unity for value without unit of measures –>
                 </swe:Quantity>
              </swe:field>
           </swe:DataRecord>
         </gmlcov:rangeType>
      </gmljp2:GMLJP2RectifiedGridCoverage>
   </gmljp2:featureMember>
   <gmljp2:featureMember>
    <gmljp2:GMLJP2RectifiedGridCoverage gml:id="CodeStream1">
     <gml:domainSet>
      <gml:RectifiedGrid gml:id="RG_CodeStream1" dimension="2"
           srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
       <gml:limits>
         <gml:GridEnvelope>
          <gml:low>0 0</gml:low>
          <gml:high>8718 7812</gml:high>
         </gml:GridEnvelope>
       </gml:limits>
       <gml:axisLabels>Lat Long</gml:axisLabels>
       <gml:origin/>
       <gml:offsetVector/>
      </gml:RectifiedGrid>
    </gml:domainSet>
    <gml:rangeSet>
      <gml:File>
       <gml:rangeParameters/>
       <gml:fileName>gmljp2://codestream/1</gml:fileName>
       <gml:fileStructure>inapplicable</gml:fileStructure>
      </gml:File>
    </gml:rangeSet>
    <gmlcov:rangeType>
      <swe:DataRecord>
       <swe:field name=“Panchromatic”>
         <swe:Quantity definition=“http://www.opengis.net/def/ogc-eo/opt/SpectralMode/PANCHROMATIC”>
          <swe:description>Panchromatic Channel</swe:description>
          <swe:uom code=“unity”/>
          <!– Unity for value without unit of measures –>
         </swe:Quantity>
       </swe:field>
      </swe:DataRecord>
    </gmlcov:rangeType>  
   </gmljp2:GMLJP2RectifiedGridCoverage>
  </gmljp2:featureMember>
  <gmljp2:featureMember>
   <gmljp2:GMLJP2RectifiedGridCoverage gml:id="CodeStream2">
   <gml:domainSet>
      <gml:RectifiedGrid gml:id="RG_CodeStream2" dimension="2"
           srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
       <gml:limits>
         <gml:GridEnvelope>
          <gml:low>0 0</gml:low>
          <gml:high>8718 7812</gml:high>
         </gml:GridEnvelope>
       </gml:limits>
       <gml:axisLabels>Lat Long</gml:axisLabels>
       <gml:origin/>
       <gml:offsetVector/>
      </gml:RectifiedGrid>
    </gml:domainSet>
    <gml:rangeSet>
      <gml:File>
       <gml:rangeParameters/>
       <gml:fileName>gmljp2://codestream/2</gml:fileName>
       <gml:fileStructure>inapplicable</gml:fileStructure>
      </gml:File>
    </gml:rangeSet>
    <gmlcov:rangeType>
      <swe:DataRecord>
       <swe:field name=“Panchromatic”>
         <swe:Quantity definition=“http://www.opengis.net/def/ogc-eo/opt/SpectralMode/PANCHROMATIC”>
          <swe:description>Panchromatic Channel</swe:description>
          <swe:uom code=“unity”/>
          <!– Unity for value without unit of measures –>
         </swe:Quantity>
       </swe:field>
      </swe:DataRecord>
    </gmlcov:rangeType> 
   </gmljp2:GMLJP2RectifiedGridCoverage>
  </gmljp2:featureMember>
</gmljp2:GMLJP2CoverageCollection>

11. A Coverage Type on the Georeferenceable Grid for JPEG 2000

Class gmljp2rgrid lays the foundation for a ReferenceableGridCoverage type of the GMLJP2 standard to be used with the extension standard GMLCOVRGRID of CIS.  Every compliant coverage instance of this type must conform to the requirements stated here in Clause 11.

The GMLJP2ReferenceableGridCoverage coverage type is a fully conformant derived type of ReferenceableGridCoverage of CIS.  Figure 7 shows the expected type structure of GMLJP2ReferenceableGridCoverage, which must conform to Requirement 1 of the ReferenceableGridCoverage Extension.

Each GMLJP2ReferenceableGridCoverage has an external CRS that applies to the domain set only after it has been transformed by an associated transformation specified by a concrete instance of AbstractReferenceableGrid.  As there is no default external CRS, there is instead a single external CRS carried in the domain set, via srsName.

In addition, a GMLJP2ReferenceableGridCoverage will conditionally have an internal CRS that applies to the domain set prior to the application of the transformation.  An example of an internal CRS is that of the local imaging plane of an electro-optical sensor grid of a camera, while the corresponding external CRS is that of the imaged ground coordinates, which would typically be described with a ProjectedCRS or GeodeticCRS.  An optional support element “gridCRS” is available to some AbstractReferenceableGrid types (e.g. ReferenceableGridByTransformation and ReferenceableGridBySensorModel) for specifying a sequence of CRS definitions in GML.  It is recommended that for such AbstractReferenceableGrid types, the first CRS definition of the gridCRS be specified as an ImageCRS that represents the internal CRS, while any subsequent CRS definitions represent any additional CRSs that may be required by the specific referenceable grid transformation.  It is also recommended that none of these additional CRSs after the first be an ImageCRS.

Note: The ImageDatum[8] of the ImageCRS determines the origin of the image coordinate system (CD_PixelinCell), which may be specified to be located at either the center or corner of the first image pixel, i.e. with the gml:pixelInCell subelement of the gml:ImageDatum set to “Cell center” or “Cell corner”, respectively.  This choice may be decided based either on the policy associated with a specific implementation of a referenceable grid transformation or on the details of the initial image collection and subsequent processing, issues that are beyond the scope of this document.  If no ImageCRS is specified for the gridCRS, CD_PixelinCell is assumed to be set to “Cell center”.

12.Image annotation (informative)

12.1  Introduction

In the general case not limited to imagery, an annotation is a combination of a feature of interest (FOI) in the real world, a styled label that annotates the feature (such as a text label, an image, a video, graphics, and possibly including audio), and an association between the FOI and the label such as an abstract or a graphically explicit representation, e.g. a line or an arrow (see Figure 8). As annotations are intended for visualization, they are dependent on visualization styles.

In this standard, an annotation is more restricted to be an association between a label that annotates a JPEG 2000 image or some geometric feature of interest (FOI) within the JPEG 2000 image.  The geometric properties of the FOI may be defined by a GML geometry, which can be e.g. a point or line string in the same CRS coordinates as the image. If no geometric region is defined, the annotation applies to the entire image that is contained in the JPEG 2000 codestream. Labels associated to FOIs may be defined using different encodings, depending of the software that generates them.

As an illustrative example, this standard supports the use of a combination of GML and KML, to complement their individual limitations. Regions of Interest and embedded geographic features (typed objects) are best expressed in GML, since GML has a precise notion of feature types while KML does not, and GML supports arbitrary CRS descriptions, while current versions of KML only support 3d geographic coordinates (i.e., unprojected latitude, longitude, and altitude). While HTML provides symbology for labels, the current version of GML does not provide a recognized symbology mechanism. Note that support for SVG was introduced in GML 3.0, which would have provided such a mechanism, but which has been deprecated in more recent versions. Thus, for the FOI, the GMLJP2 standard recommends the use of GML. The application should portray the FOIs in a way, unfortunately without any symbology support from GML, that ensures that the user will be able to recognize the symbols drawn on the image. To describe the label to annotate the FOI, KML is recommended. The application that renders the labels will be required to dynamically reproject the KML data (in geographic coordinates) into the JPEG 2000 CRS before presenting it. In addition, it would be helpful if an explicit graphical association between the ROI and the label (e.g. a line or a curve) were provided by the application.

An alternative way of achieving the mapping of the GML (feature types) is to make use of the OGC Styled Layer Descriptor (SLD) Profile [OGC 05-078r4] and the OGC Symbology Encoding (SE) Implementation Specification [OGC 05-077r4], which together define encodings that extend the WMS Encoding Standard for comprehensive symbology support. An SLD/SE symbolization can be packaged in a GMLJP2 that would fulfill requirements for both standalone or networked systems. The KML label could then be generated on the fly from the GML together with the SDL/SE definitions. In the future, the use of SLD/SE may enable the creation of a Portrayal Registry in which symbols, styles, and other definitions are stored, enabling reuse by a set of JPEG 2000 images.

12.2  Use-cases

GMLJP2 is intended to handle a variety of annotation use cases including the following.

Example 1: Creating a GMLJP2 annotated image:

• Capture any object types (e.g. building – classify the building etc.) (GML)
• Apply a style to generate a symbolization (KML)
• Write the GML, KML and style (SLD/SE) into the GMLJP2 package

Example 2: Viewing a GMLJP2 annotated image

• Retrieve the symbolization (KML) from the GMLJP2 and visualize as image overlay

Example 3: Apply user specified style to annotation in a GMLJP2 image

• Retrieve the object type (GML) from the GMLJP2 and apply User style to generate KML (or SVG etc) and then visualize as image overlay.

Example 4: Apply default style to annotations in a GMLJP2 image

• Retrieve the object type (GML), SLD/SE from the GMLJP2 and apply the SLD/SE to generate KML and then visualize as image overlay.