I.  Abstract

This OGC Testbed 20 Report defines a draft OGC Specification for Geographic High Efficiency Image Format (GeoHEIF). The Report specifies requirements and encoding rules for using the High Efficiency Image File Format (HEIF) for the exchange of georeferenced or geocoded imagery. The GeoHEIF specification defines HEIF properties to include the georeference information in one or more image items. In addition, other HEIF properties are added to define the semantics of dimensions and cell properties that together allow for converting HEIF into a datacube container.

Please note that while the intent is to submit this document to the OGC for consideration as an OGC Standard, this document is internally referred to as an OGC Testbed 20 Report or more simply “this Report” or “this specification”.

III.  Preface

The High Efficiency Image Format (HEIF) format is a multipart data encoding that is defined by Moving Picture Experts Group (MPEG). In addition to camera footage, by adding the georeference information, HEIF can be used to store geospatial imagery. The GeoHEIF (Geographic High Efficiency Image Format) specification defines HEIF properties to include the georeference information in one or more image items. In addition, other HEIF properties are added to define the semantics of dimensions and cell properties that together enable converting HEIF into a datacube container. This Testbed 20 GIMI Report is based on previous experiences gained in the October 2023 London OGC Code Sprint and in Testbed 20 testing. This Report is presented as a standard candidate for consideration by the OGC Technical Committee (TC). The first step in the OGC TC would be the creation of a SWG, then a broader discussion, and then eventually final approval as an OGC Standard. This process is similar to the one used for GeoTIFF, where an external imagery file was with the necessary elements to support geospatial metadata.

1.  Scope

The HEIF format supports the storage and containment of uncompressed and compressed forms of imagery, with supporting metadata. This Testbed 20 Report defines a GeoHEIF (Geographic High Efficiency Image Format) format based on HEIF and ISO base media file format (ISOBMFF) standards that can be used to represent orthorectified, georectified, and unrectified imagery. Images can be geospatially enabled by providing coordinate reference system (CRS) metadata defined in Compact URIs (CURIEs), Well-Known Text version 2 (WKT2), or other OGC approved encodings. Using a raster space to model space transformation matrix, the image becomes georectified. Alternatively, a set of tie-points can be used to make the image georeferenceable. In addition, by adding the definition of the semantics of dimensions and cell properties, the specification supports geospatial datacubes. Both dimensions and cell properties can be continuous, ordinal or categorical. In addition, by adding the definition of the semantics of dimensions and cell properties, geospatial datacubes are supported. Both dimensions and cell properties can take continuous, ordinal, or categorical values.

The scope of this Report includes still and sequence imagery but does not consider motion imagery.

The scope of this Report also includes containment of imagery with a broad range of array sizes, frame rates, one-to-many components (bands), variability in color formats, bit depths and, 2D dimension, or N dimension datacubes:

The draft Specification defined in this Report builds on and leverages existing HEIF and ISOBMFF functionality including advanced codecs, image overviews, image tiling, and metadata. Those capabilities are not separately defined in this Report but can be used along with the geographical capabilities defined in this Report.

2.  Conformance

This draft Specification defines 14 requirements grouped into 7 Requirements Classes.

Requirements for 3 standardization target types are considered:

Conformance class related with HEIF File “Requirements Class HEIF” https://www.opengis.net/spec/GeoHEIF/1.0/req/HEIF is the core of this draft Specification and shall be considered mandatory for all implementations.

Conformance with this draft Specification shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site.

In order to conform to this OGC® interface draft Specification, a software implementation shall choose to implement:

All requirements-classes and conformance-classes described in this document are owned by the draft Specification(s) identified.

3.  Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

ISO/IEC: ISO/IEC 14496-12:2022, Information technology — Coding of audio-visual objects — Part 12: ISO base media file format. International Organization for Standardization, International Electrotechnical Commission, Geneva (2022). https://www.iso.org/standard/83102.html.

ISO/IEC: ISO/IEC 23008-12:2022, Information technology — High efficiency coding and media delivery in heterogeneous environments — Part 12: Image File Format. International Organization for Standardization, International Electrotechnical Commission, Geneva (2022). https://www.iso.org/standard/83650.html.

4.  Terms, definitions and abbreviated terms

This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

For the purposes of this document, the following additional terms and definitions apply.

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

For the purposes of this document, the following additional terms and definitions apply.

ASCII encoded “four-character code” indicating data formatting requirements. Applications implement the 4CC code as a 32-bit big-endian unsigned integer with the first character in the MSB, last character in the LSB. There is no string termination

[SOURCE: NGA.STND.0076_1.0_GIMI]

In the context of this Report, this is an identifier in the FileTypeBox of a HEIF file that identify a specification to which the file complies

type of variable that represents qualitative characteristics or attributes that can be grouped into distinct categories (examples of categorical variables include land cover classification, gender and business type)

variable measured (or stored) for a cell of the gridded space

variable that can take on any value within a given range i.e., that have an infinite number of possible values between two values (examples include height, time, and temperature)

epoch to which coordinates in a dynamic coordinate reference system are referenced

[SOURCE: OGC 18-005r8, Clause 3.1]

coordinate system that is related to an object by a datum

[SOURCE: OGC 18-005r8, Clause 3.1]

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

[SOURCE: OGC 18-005r8, Clause 3.1]

feature that acts as a function to return values from its range for any direct position within its spatial, temporal, or spatiotemporal domain

[SOURCE: ISO 19123:2005]

multi-dimensional (“n-D”) array of values designed for efficient data analysis and querying. The data is arranged in dimensions that can be coordinates, other continuous variables or even enumerations, e.g., categories

number of measurements or axes needed to describe a position in a coordinate system

[SOURCE: ISO 19123:2005]

ordered list of axes whose lower and upper bounds establish the extent along each axis

[SOURCE: OGC 09-146r6]

two- or three-dimensional coordinate reference system based on a geodetic reference frame and having either a three-dimensional Cartesian or an ellipsoidal or a spherical coordinate system

[SOURCE: OGC 18-005r8, Clause 3.1]

coordinate reference system that has a geodetic reference frame and an ellipsoidal coordinate system

[SOURCE: OGC 18-005r8, Clause 3.1]

grid with regularly spaced cells in a geographic (i.e., latitude/longitude) or map coordinate system defined in a CRS so that any cell in the grid can be geolocated given its grid coordinate and the grid origin, cell spacing, and orientation

[SOURCE: ISO 19115:2003]

grid with irregularly spaced cells in any given geographic/map projection coordinate system, whose individual cells can be geolocated using geolocation information supplied with the data but cannot be geolocated from the grid properties alone

[SOURCE: ISO 19115:2003]

coverage covering of a multi-dimensional region using quadrilateral shapes (in the 2D case) or their n-dimensional generation (in the n-D case) with no overlaps and gaps

[SOURCE: OGC 07-011r2]

fundamental unit that represents a specific location or intersection point within the grid structure and have a value for a concrete property. It is defined by its position along multiple dimensions, typically including spatial coordinates and potentially other extra dimensions such as time or frequency

In the context of this Report, this is data that does not require timed processing, as opposed to sample data, and is described by the boxes contained in a HEIF MetaBox

[SOURCE: ISO/IEC 23008-12:2022]

In the context of this Report, this is descriptive or transformative information about an item as stored in the HEIF item properties array in the ItemPropertyContainerBox

[SOURCE: ISO/IEC 23008-12:2022]

space in a coordinate reference system related to the Earth or a part of the Earth

[SOURCE: OGC 19-008r4]

missing value, invalid value, or inapplicable value for that location that occurs when no data value is stored for the variable in an observation

categorical value with a clear ordering amount the set it belongs. The spacing between values may not be consistent or meaningful (examples include academic grades (A, B, C), clothing sizes (S, M, L, XL), and attitude scales (strongly agree, agree, disagree, strongly disagree))

coordinate reference system derived from a geographic coordinate reference system by applying a map projection

[SOURCE: OGC 18-005r8, Clause 3.1]

rectilinear grid NOTE: The term is also used as an imprecise generic term for imagery and gridded coverage data. NOTE: Historically, the term derives from the scanning lines display pattern on a cathode ray tube.

[SOURCE: OGC 07-011r2]

set of cell property (feature attribute) values associated by a function with the elements of the domain of a coverage

[SOURCE: ISO 19123:2005]

any characteristic, number, or quantity that can be measured or counted

cell in a multidimensional space

5.  Conventions

This section provides details and examples for any conventions used in this Report. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document.

6.  Overview

The requirements defined in this specification build on the work done in GeoTIFF (OGC 19-008r4) and complements OGC Abstract Specification Topic 6: Schema for Coverage Geometry and Functions OGC 07-011r2 and its implementation in the Coverage Implementation Schema (OGC 09-146r6), as well as the work done in GMLJP2 (OGC 08-085r8).

6.2.  Dimensions and Properties: DataCube

The OGC Coverage Implementation Schema (CIS) (OGC 09-146r6) divides the variables involved in the continuous distributions of observed properties into two main concepts.

• Dimensions: are the variables that define the multidimensional gridded space. Every combination of the values of these variables defines a cell in a multidimensional space, sometimes called voxel. Examples include longitude, latitude, time and height.

• Properties: are the variables measured (or stored) in each cell of the gridded space. Examples include temperature, intensity and reflected light.

Ideally, these variables should be defined with a minimum set of common characteristics: A name, a URI to a concept (a.k.a. a definition in a vocabulary) and its units of measure (again with a name, a URI definition and possibly a symbol). The use of the word properties might result confusing as it is used to designate characteristics of objects (in programming languages) or features (in geospatial entities). In fact, the selection of the word properties is done on purpose to help to converge the coverage model with the vector/feature model. In the OGC 07-011r2 “properties” are called “range” and sometimes are also called “attributes” or “bands” in remote sensing. As such, do not get confused with HEIF item properties. In this document, properties that are the variables measured in each cell of the gridded space are called cell properties.

While both types of variables share some commonalities, there are some differences.

• Dimensions: Spatial dimensions comes in “pairs” (e.g., longitude, latitude) and they are defined “together” in a single URI (e.g., https://www.opengis.net/def/crs/OGC/1.3/CRS84) along with Units of Measure (UoM), and axis order. They can only take discrete values (quantized) and have regular, irregular or even categorical values.

• Properties: Apart from the common characteristics, in some cases the values may not exist in some cell and there is a need for being able to specify a “nilValue.” Values can be continuous, discrete or categorical. Another characteristic defines if the value in the cell covers the whole pixel or is in the center. In GeoTIFF (OGC 19-008r4) this characteristic is defined as GTRasterTypeGeoKey (RasterPixelIsArea and RasterPixelIsPoint).

URI to a concept can define many characteristics. For example, some “bands” require more than a name such as polarization, etc. Normally there should be a URI that represents all those characteristics. If you need to express “characteristics” you can always link concepts together in a more precise concept. One example of how this can be done is provided by the InteroperAble Descriptions of Observable Property Terminology (I-ADOPT) Working Group (https://i-adopt.github.io/).

 

Figure 1 — Examples of DataCubes: (1) extra dimension: Time, property type: Digital numbers; (2) extra dimension: Altitude, property type: Temperature; (3) extra dimension: Species, property type: Occurrences; (4) extra dimension: Observed or modeled, property type: NO₂ concentration

When dealing with 2D images (a.k.a. slices), the image axes (i and j) need to be assigned to 2 dimensions and the other dimensions are constant values for an image. Each image describes only one or more properties. Only image encodings supporting multiple components are able to represent more than one property per image.

The ISO Base Media File Format (ISOBMFF) defined in ISO/IEC 14496-12:2022 and the ISO High Efficiency Image File Format (HEIF) defined in ISO/IEC 23008-12:2022 can be used to encode images and videos. However, there is no provision on how to georeference the images. A brief introduction of the ISOBMFF and HEIF format structure can be found in Annex D.

This Report specifies extensions to the ISO Base Media File Format (ISOBMFF) defined in ISO/IEC 14496-12:2022 and extended in ISO/IEC 23008-12:2022 to define the following geo related properties to be include in ItemPropertyContainerBox ipco that are parts of ItemPropertyBox iprp in the MetaBox.

• CRSs (specified in a mcrs property in ItemPropertyContainerBox) that includes the definition of the first “2D” dimensions

• Models to assign two dimensions of the model to image axes (i and j): A affine transformation matrix (specified in a mtxf in ItemPropertyContainerBox) or tie points (specified in a tiep in ItemPropertyContainerBox).

• Extra-dimensions (specified in a edim in ItemPropertyContainerBox): including the quantized values that can be implicit in a regular grid or a direct list of values for irregular or categorical dimensions

• Cell property types (specified in a pcel in ItemPropertyContainerBox): including the name, definition, units of measure, if the measure represent the central point or the cell area, the minimum and maximum values in the datacube, and the nilValue and what the nilValue represents.

In addition to that another small property is also included:

• Constant values for the zero or more (N-2) extra-dimensions not included in the CRSs (specified in a edvl item property container box).

The specification defined in this report also extends the image concept by relating it to the cell properties introduced before in cell property types. The images themselves are stored in ImageItemData in the MediaDataBox mdat and remain unaltered. The actual relation to the cell properties is done independently in the ItemPropertyAssociationBox that relates the ItemPropertyContainerBox to the ImageItemData.

In fact, for each image there is an association to:

• A reference to one CRS;

• A reference to one model to assign the two dimensions of the model defined in the CRS to image axes (i and j): In the case of affine transformation matrix and tie points, and using nCol and nRow of the image, the bounding box (BBOX) and the cell size in CRS units can be obtained;

• Reference to zero or more (N-2) extra-dimensions;

• Reference to zero or more values the (N-2) extra-dimensions; and

• Reference to one or more properties (one for each channel in an image).

The requirements classes defined in this report are structured as follows:

• A requirements class defining the properties to be include in ItemPropertyContainerBox; and

• A requirements class defining how to associate the properties to the images.

This approach solves the datacube problem and the imagery problem in a single format.

7.  ISO Base Media File Format extensions

aligned(8) class CoordinateReferenceSystemProperty
extends ItemFullProperty('mcrs', version=0, flags) {
    unsigned int(32) crsEncoding;
    utf8string crs;
    if (flags & 1) {
        float(32) epoch;
    }
}

PROJCRS["WGS 84 / UTM zone 55S",
    BASEGEOGCRS["WGS 84",
        ENSEMBLE["World Geodetic System 1984 ensemble",
            MEMBER["World Geodetic System 1984 (Transit)"],
            MEMBER["World Geodetic System 1984 (G730)"],
            MEMBER["World Geodetic System 1984 (G873)"],
            MEMBER["World Geodetic System 1984 (G1150)"],
            MEMBER["World Geodetic System 1984 (G1674)"],
            MEMBER["World Geodetic System 1984 (G1762)"],
            MEMBER["World Geodetic System 1984 (G2139)"],
            ELLIPSOID["WGS 84",6378137,298.257223563,
                LENGTHUNIT["metre",1]],
            ENSEMBLEACCURACY[2.0]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]],
        ID["EPSG",4326]],
    CONVERSION["UTM zone 55S",
        METHOD["Transverse Mercator",
            ID["EPSG",9807]],
        PARAMETER["Latitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",147,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["Scale factor at natural origin",0.9996,
            SCALEUNIT["unity",1],
            ID["EPSG",8805]],
        PARAMETER["False easting",500000,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",10000000,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["(E)",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["(N)",north,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    USAGE[
        SCOPE["Navigation and medium accuracy spatial referencing."],
        AREA["Between 144°E and 150°E, southern hemisphere between 80°S and equator, onshore and offshore. Australia. Papua New Guinea."],
        BBOX[-80,144,0,150]],
    ID["EPSG",32755]]

aligned(8) class ModelTransformationProperty
extends ItemFullProperty('mtxf', version=0, flags) {
      if (flags & 0x01) {
            // 2D case
            float(64) m00;
            float(64) m01;
            float(64) m03;
            float(64) m10;
            float(64) m11;
            float(64) m13;
      } else {
            // 3D case
            float(64) m00;
            float(64) m01;
            float(64) m02;
            float(64) m03;
            float(64) m10;
            float(64) m11;
            float(64) m12;
            float(64) m13;
            float(64) m20;
            float(64) m21;
            float(64) m22;
            float(64) m23;
      }
}

aligned(8) class ModelTiepointProperty
extends ItemFullProperty('tiep', version=0, flags) {
    unsigned int(16) tie_points_count;
    for (n = 0; n < tie_points_count; n++) {
        if (flags & 0x01) {
            // 2D case
            unsigned int(32) i[n];
            unsigned int(32) j[n];
            float(64) x[n];
            float(64) y[n];
        } else {
            // 3D case
            unsigned int(32) i[n];
            unsigned int(32) j[n];
            float(64) x[n];
            float(64) y[n];
            float(64) z[n];
        }
    }
}

aligned(8) class ExtraDimensionProperty
extends ItemFullProperty('edim', version=0, flags=0) {
    unsigned int(32) extradimensions_count;
    for (i = 0; i < extradimensions_count; i++) {
        utf8string name[i];
        utf8string definition[i];

        unsigned int(8) extradimension_type[i];
        if (extradimension_type[i] == 0) {
            double minimum[i];
            double maximum[i];
            double resolution[i];

            utf8string unit[i];
            utf8string unit_lang[i];
        }
        else if (extradimension_type[i] == 1) {
            unsigned int(32) extradimension_value_count[i];
            for (j = 0; j < extradimension_value_count[i]; j++) {
                double value[i][j];
                utf8string value_definition[i][j];
            }
            utf8string unit[i];
            utf8string unit_lang[i];
        }
        else if (extradimension_type[i] == 2) {
            unsigned int(32) extradimension_value_count[i];
            for (j = 0; j < extradimension_value_count[i]; j++) {
                utf8string category_name[i][j];
                utf8string value_definition[i][j];
            }
        }
    }
}

aligned(8) class ExtraDimensionValueProperty
extends ItemFullProperty('edvl', version=0, flags=0) {
    unsigned int(32) extradimensions_count;
    for (i = 0; i < extradimensions_count; i++){
        unsigned int(32) extradimension_value_index[i];
    }
}

aligned(8) class CellPropertyTypeProperty
extends ItemFullProperty('pcel', version=0, flags=0) {
    unsigned int(32) component_count;
    for (i = 0; i < component_count; i++) {
        utf8string name[i];
        utf8string definition[i];
        utf8string unit[i];
        utf8string unit_lang[i];

        boolean measure_is_point[i];

        unsigned int (8) component_bit_depth_minus_one[i];
        unsigned int (8) component_format[i];

        if (component_format[i] == 0) {
            unsigned int (component_bit_depth_minus_one[i] + 1) minimum[i];
            unsigned int (component_bit_depth_minus_one[i] + 1) maximum[i];
        } else if (component_format[i] == 1) {
            float (component_bit_depth_minus_one[i] + 1) minimum[i];
            float (component_bit_depth_minus_one[i] + 1) maximum[i];
        } else if (component_format[i] == 2) {
            float ((component_bit_depth_minus_one[i] + 1)/2) minimum_real[i];
            float ((component_bit_depth_minus_one[i] + 1)/2) minimum_imaginary[i];
            float ((component_bit_depth_minus_one[i] + 1)/2) maximum_real[i];
            float ((component_bit_depth_minus_one[i] + 1)/2) maximum_imaginary[i];
        } else if (component_format[i] == 3) {
            int (component_bit_depth_minus_one[i] + 1) minimum[i];
            int (component_bit_depth_minus_one[i] + 1) maximum[i];
        }

        unsigned int(8) nil_value_count[i];
        for (j = 0; j < nil_value_count[i]; j++) {
            if (component_format[i] == 0) {
                unsigned int (component_bit_depth_minus_one[i] + 1) nil_value[i][j];
            } else if (component_format[i] == 1) {
                float (component_bit_depth_minus_one[i] + 1) nil_value[i][j];
            } else if (component_format[i] == 2) {
                float ((component_bit_depth_minus_one[i] + 1)/2) nil_valueReal[i][j]
                float ((component_bit_depth_minus_one[i] + 1)/2) nil_valueImaginary[i][j];
            } else if (component_format[i] == 3) {
                int (component_bit_depth_minus_one[i] + 1) nil_value[i][j];
            }
            utf8string nil_value_reason[i][j];
        }
    }
}

aligned(8) class CellPropertyCategoriesProperty
extends ItemFullProperty('pcat', version=0, flags=0) {
    unsigned int(32) component_count;
    for (i = 0; i < component_count; i++) {
        unsigned int(32) category_count;
        unsigned int (8) component_bit_depth_minus_one;
        unsigned int (8) component_format;

        for (c = 0; c < category_count; c++) {
            if (component_format == 0)
                unsigned int (component_bit_depth_minus_one + 1) value;
            else if (component_format == 3)
                int (component_bit_depth_minus_one + 1) value;
            utf8string name;
            utf8string description;
            utf8string definition;
        }
    }
}

8.  Media Types for any data encoding(s)

Bibliography

[1]  Roger Lott: OGC 18-005r8, Topic 2 — Referencing by coordinates (Including corrigendum 1 and corrigendum2). Open Geospatial Consortium (2023). http://www.opengis.net/doc/AS/topic-2/6.0.

[2]  Roger Lott: OGC 18-010r11, Geographic information — Well-known text representation of coordinate reference systems. Open Geospatial Consortium (2023). http://www.opengis.net/doc/is/crs-wkt/2.1.11.

[3]  Peter Baumann: OGC 07-011r2, Topic 6.1 — Schema for Coverage Geometry and Functions – Part 1: Fundamentals. Open Geospatial Consortium (2024). http://www.opengis.net/doc/AS/Topic-6.1/2.0.

[4]  John Herring: OGC 06-103r4, OpenGIS Implementation Specification for Geographic information — Simple feature access — Part 1: Common architecture. Open Geospatial Consortium (2011). http://www.opengis.net/doc/is/sfa/1.2.1.

[5]  Peter Baumann, Eric Hirschorn, Joan Masó: OGC 09-146r6, OGC Coverage Implementation Schema. Open Geospatial Consortium (2017). http://www.opengis.net/doc/IS/cis/1.1.0.

[6]  Emmanuel Devys, Ted Habermann, Chuck Heazel, Roger Lott, Even Rouault: OGC 19-008r4, OGC GeoTIFF Standard. Open Geospatial Consortium (2019). http://www.opengis.net/doc/IS/GeoTIFF/1.1.0.

[7]  Michael Leedahl: OGC 23-028, OGC Testbed 19 Extraterrestrial GeoTIFF Engineering Report. Open Geospatial Consortium (2024). http://www.opengis.net/doc/PER/T19-D002.

[8]  Arliss Whiteside, Jim Greenwood: OGC 06-121r9, OGC Web Service Common Implementation Specification. Open Geospatial Consortium (2010). https://portal.ogc.org/files/?artifact_id=38867.

[9]  Lucio Colaiacomo, Joan Masó, Emmanuel Devys, Eric Hirschorn: OGC 08-085r8, OGC® GML in JPEG 2000 (GMLJP2) Encoding Standard. Open Geospatial Consortium (2018). http://www.opengis.net/doc/IS/GMLJP2/2.1.0.

[10]  R. Gellens, D. Singer, P. Frojdh: IETF RFC 6381, The ‘Codecs’ and ‘Profiles’ Parameters for “Bucket” Media Types. RFC Publisher (2011). https://www.rfc-editor.org/info/rfc6381.

[11]  ISO/IEC: ISO/IEC 15444-16:2021, Information technology — JPEG 2000 image coding system — Part 16: Encapsulation of JPEG 2000 images into ISO/IEC 23008-12. International Organization for Standardization, International Electrotechnical Commission, Geneva (2021). https://www.iso.org/standard/80620.html.

[12]  ISO: ISO 19115:2003, Geographic information — Metadata. International Organization for Standardization, Geneva (2003). https://www.iso.org/standard/26020.html.

[13]  ISO: ISO 19123:2005, Geographic information — Schema for coverage geometry and functions. International Organization for Standardization, Geneva (2005). https://www.iso.org/standard/40121.html.

[14]  ISO/IEC: ISO/IEC 23001-17:2024, Information technology — MPEG systems technologies — Part 17: Carriage of uncompressed video and images in ISO base media file format. International Organization for Standardization, International Electrotechnical Commission, Geneva (2024). https://www.iso.org/standard/82528.html.

[15]  OGC OWS-9 OWS Innovations GMLJP2 for National Imagery Transmission Format (NITF) Engineering Report

[16]  AV1 Image File Format (AVIF) v1.1.0

[17]  OGC: OGC Testbed 12 Annex B: Architecture (2015).

[18]  GEOINT Imagery Media for ISR (GIMI) Profile of ISOBMFF & HEIF