I. Executive Summary
With the growing number of space assets and missions, the space industry needs a way to locate extra-terrestrial objects within the captured imagery. The current GeoTIFF Standard provides the location of terrestrial objects using TIFF tags. However, objects in space are relative to the observer and the distance of the objects in the imagery are often at great distances from the observer. Multiple objects can exist within the imagery which are at different spacetime locations in four dimensions. To further complicate the definition of the location, from a planar perspective, the edges of the image fade into infinity. With the use of spherical and gridded coordinates an image can tag pixels along the edge of a sphere or the camera location. The Testbed 19 Engineering Report (ER) extends GeoTIFF to work for all images including both terrestrial and non-terrestrial observations within the image.
This ER documents issues such as:
the specification of registries;
referencing the celestial body;
aliasing parameters;
defining spherical coordinate reference systems; and
defining engineering coordinate systems.
II. Keywords
The following are keywords to be used by search engines and document catalogues.
hackathon, testbed, geotiff, extraterrestrial
III. Contributors
All questions regarding this document should be directed to the editor or the contributor.
| Name | Organization | Role |
|---|---|---|
| Martin Desruisseaux | GEOMATYS | Contributor |
| Michael Leedahl | Maxar | Editor |
1. Introduction
GeoTIFF currently specifies the European Petroleum Survey Group (EPSG)1 coordinate systems and the location of the upper left corner of the image in the image header metadata tags. For an Earth-defined coordinate system in the EPSG coding system, this defines a location for the image relative to a location on the Earth. However, the Earth is not the only planet or space object that concerns the imagery community. This ER is relevant to those who maintain or track objects in space or are exploring objects or planets. Many readers are looking for a way to reference locations in images for images that display non-terrestrial settings. The ER explores the issues with locating something in space and on other planetary objects. The report documents experiments designed to solve these issues.
2. Terms and definitions
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 ER examines what extension the GeoTIFF Standard needs in order to overcome several issues. The following terms come from the GeoTIFF standard.
A coordinate reference system is a coordinate system that is related to an object by a datum (Clause 2.3).
[SOURCE: ISO 19111, Clause 3.1.9]
A coordinate system is a set of mathematical rules for specifying how coordinates are to be assigned to points.
[SOURCE: ISO 19111, Clause 3.1.11]
A datum is a parameter or set of parameters that realize the position of the origin, the scale, and the orientation of a coordinate system (Clause 2.2).
[SOURCE: ISO 19111, Clause 3.1.15]
A GeoKey is equivalent in function to a Tagged Image File Format (TIFF) tag with a different storage mechanism.
[SOURCE: OGC 19-008r4]
In TIFF format, a tag is packet of numerical or ASCII values which have a numerical “Tag” ID indicating their information content.
[SOURCE: OGC 19-008r4]
3. Issues of locating non-terrestrial objects
This report examines two use cases for defining a location. The first use case, similar to images on the Earth, deals with imagery from an orbital or overhead shot on another planet. The second use case deals with observers and targets that are at great distances from one another. This section explores the main issues with each use case.
When capturing an image using orbital or airborne sensors above a planet, one must use a datum and reference system for which to locate the corners of the image. This is similar to the capture of imagery for locations on the Earth. The EPSG registry for datums and coordinate system contain the definitions for Earth. The current GeoTIFF standard assumes that the datum and coordinate reference systems are defined in the EPSG registry and allows for tags to specify both. In addition, the standard assumes that the imagery is of the Earth.
This Earth centric view limits the use of the GeoTIFF Standard for defining locations on other celestial bodies. The underlying TIFF format does not care about location and an image is just an image. A sensor may create a TIFF image of any celestial body. The problem comes in defining the location and identifying the celestial body in the image. The GeoTIFF Standard may support other celestial bodies by adding support for tags dealing with new registries and the name of a celestial body.
By extending the charter of the ESPG to include Non-Earth parameters, the current GeoTIFF standards continue to work. However, this is unlikely to be the case and other organizations such as the National Geospatial-Intelligence Agency (NGA) are already working on datums for other planets. Therefore, other organizations are likely to create registries for reference systems on other planets and celestial objects. The Testbed 19 participants recommend adding tags to the GeoTIFF Standard for specifying a registry and celestial body that will help define a location for the first use case.
Another issue with both use cases stems from problems in the naming of identifier values for datum, ellipsoid, prime meridian, or unit of measurement. These parameter tags specify identifiers that change over time. This happens more frequently when dealing with newly discovered planets or other non-terrestrial objects. Consider the WGS 1984 datum: the datum is referred to as ‘World Geodetic System 1984 ensemble’ or ‘D_WGS_1984.’ Allowing an application to specify more than one value for a tag, will help users of the imagery understand what the identifier refers to. One value may be human-readable where another value may be machine-readable, etc. Each additional value is an alias for the first value.
The second use case deals with objects and observers that move and are at some distance apart. Since an observer can potentially see more than one object and each object can be at different space-time coordinates, defining a datum and coordinate system for the objects is not possible or practical. The GeoTIFF Standards needs an engineering datum and coordinate system. An engineering datum allows the plane of the sensor to act as the location of the image. Since the sensor is moving in space-time and the object being observed is also moving in space-time, the location is one that is relative to the sensors location at the time the sensor captures the image. Since there could be multiple things in the image and the edges of the image go to infinity, mapping the image to the coordinate of all the objects is impossible or impractical.
The other wrinkle in precisely locating objects is light reaching the sensor may bend as the light travels through space-time. The gravity of objects with a large mass will warp space-time and cause light to bend. Because light from the object may take a considerable amount of time to reach the sensor, the sensor is recording the state of the object in the past and not the current or near current state of the object. This affects the time coordinate of the image. Since the gravitational pull of large objects can warp space-time and bend light, the location of the object may not be a linear distance from the observing sensor. Factoring General and Special Relativity into coordinate systems solves these issues. Many of these coordinate systems are spherical in nature. One approach for determining the location of an object relative to a sensor is to use spherical coordinate systems. An engineering coordinate system could define a sphere where the sensor is in the center of the sphere and the object to locate it is on the surface of the sphere. The issue is that the current GeoTIFF Standard does not define spherical coordinate reference systems and as such, an engineering coordinate system using a sphere is not definable. A precursor to defining an engineering coordinates system is to support the definition of 2-dimensional and 3-dimensional spherical coordinate reference systems. Terrestrial sensors can use the same approach when taking oblique images. For example, a person with a camera taking a scenic picture can have multiple objects at different locations within the same image. A spherical coordinate system from the camera is very similar to taking a picture of objects in space.
A revision to the GeoTIFF Standard could support both use cases. Adding registry and celestial body tags would help users and applications understand what datums, coordinate systems, and objects to use when defining the location of the image. Adding aliases helps users and applications identify various tag values within the file as things are renamed over time. Finally, adding spherical coordinate reference systems and engineering coordinate systems helps with defining the location of moving objects in space relative to the observer.
4. New concepts for GeoTIFF
In an attempt to solve the issues in Section 3 (Issues of locating non-terrestrial objects), the recommendations in Section 6 introduce additional GeoKeys. The new GeoKeys represent a significant shift from the current model in the GeoTIFF Standard. Existing implementations should ignore GeoKeys they do not recognize. Thus, adding new Tags/GeoKeys should not break existing implementations. This is seen in practice by the TIFF C Library which warns about GeoKeys but does not fail to read or modify Tags in TIFF files which the library knows about. This section discusses new concepts that affect future versions of the GeoTIFF Standard, such as Engineering Coordinate Systems and Coordinate Transformations.
4.1. Engineering coordinate systems
Recommendations in this Engineering Report propose how to encode Engineering Coordinate Reference Systems in GeoTIFF files. OGC Testbed 18 Reference Frame Transformation Engineering Report ogc22-038r2 discusses ISO 19111 EngineeringCRS class space use cases. In the GeoTIFF context, the EngineeringCRS class is subject to restrictions inherent to the GeoKeys usage pattern. In the GeoTIFF context and in this ER:
the engineering CRS is centered on the spacecraft’s camera;
the coordinate system class is restricted to Cartesian (3D), Spherical (3D), and Spherical (2D);
the axis directions are fixed by the GeoTIFF Standard2 to the ISO 19111 codes specified below; and
the axis names are free texts which a user or application defines.
For the Cartesian coordinate system case, the following table defines a right-hand system:
Table 1 — Axis directions of a Cartesian coordinate system (3D)
| Proposed axis name | Axis direction | Range | Range meaning |
|---|---|---|---|
| X | forward | −∞ … ∞ | exact |
| Y | port | −∞ … ∞ | exact |
| Z | up | −∞ … ∞ | exact |
Some image coordinates are impossible to describe in a Cartesian coordinate system. Describing pixels at the edge, for example, can represent an infinite distance in deep space (see Section 6 Recommendations). In such a case, a two-dimensional spherical CS is recommended. The 2D spherical case is identical to the 3D spherical case shown below, with the distance axis omitted:
Table 2 — Axis directions of a Spherical coordinate system (3D)
| Proposed axis name | Axis direction | Range | Range meaning |
|---|---|---|---|
| Relative bearing | clockwise | −180° … +180° | wraparound |
| Altitude | up | −90° … +90° | exact |
| Distance | away-from | 0 … ∞ | exact |
The approximate direction of displacement of the sensor defines the forward direction. Please note that these concepts apply to both terrestrial and non-terrestrial use cases. The forward definition is intentionally a bit vague because, for a terrestrial example, the direction of displacement of a drone flying in windy conditions may continuously change. The image producer may define “forward” as the direction that the drone has in perfectly calm conditions. The encoding for the exact direction of an engineering CRS is not necessary when the direction is stable relative to the spacecraft. The transformation must be accurate to a well known CRS (see Section 4.2). For the purpose of the engineering CRS, the forward direction defines the location of the (0,0) coordinates in a two-dimensional spherical coordinate system. However, it does not imply that the camera must be looking in that direction. There is no requirement that the (0,0) coordinates are at the image center. The (0, 0) coordinates may be outside the image. This is often true of projected coordinate systems for Earth bound applications and works for images in space as well. An affine transform in the ModelTransformationTag documents the relationship between the spherical coordinates and pixel coordinates.
4.2. Coordinate transformations
An EngineeringCRS is fine for identifying the relative location between two objects. However, locating something within the image on a planet or in some inertial CRS requires a transformation from the EngineeringCRS of the image. The GeoTIFF Standard does not support encoding transformation coordinate reference systems. Accomplishing such a transformation requires two or three coordinate reference systems: the source CRS, the target CRS, and sometimes the interpolation CRS. The GeoTIFF Standard encodes the source CRS, which is the EngineeringCRS. The Standard does not define anything other than the source CRS. Alternative approaches are recommended in Section 6.2.
5. An examination of experiments in recording the location of non-terrestrial objects
OGC Testbed 19 for the Extraterrestrial GeoTIFF activity uses the Double Asteroid Redirection Test (DART) mission from NASA as the subject for the experiment. This experiment uses an image of Dimorphos seen by the DART spacecraft before the impact. The image is from the European Space Agency (ESA) website in PNG format (see the bibliography reference ESA-multimedia). A reduced resolution overview is shown below:
Figure 1 — Didymos and Dimorphos seen by DART
Asteroid Didymos (bottom left) and its moonlet, Dimorphos, about 2.5 minutes before the impact of NASA’s DART spacecraft. The image was taken by the onboard Didymos Reconnaissance and Asteroid Camera for Optical navigation (DRACO) sensor from a distance of 570 miles (920 kilometers). This image was the last to contain a complete view of both asteroids. Didymos is roughly 2,500 feet (780 meters) in diameter; Dimorphos is about 525 feet (160 meters) in length. Ecliptic north is toward the bottom of the image. This image is shown as it appears on the DRACO detector and is mirror flipped across the x-axis from reality.
— ESA
Dimorphos is close to, but not exactly at, the image center. A visual examination of the Dimorphos extent in the image, combined with information about distance and ellipsoid size, provides an estimation of the resolution as 0.58 arc-second per pixel. The information, together with a DART EngineeringCRS definition, where encoded in Portable Graphic World (PGW) and Projection (PRJ) files close to the World File convention. World files contain the parameters used by an affine transformation such as ground sample distances of pixels, image rotation, and image upper left origin coordinates. Those PNG, PGW, and PRJ files where then read by an Apache SIS prototype and rewritten in a GeoTIFF file using some of the tags described in Annex B. The experiment is described in more detail in Annex D.
6. Recommendations
This section of the Engineering Report contains a summary of the recommendations for changes to the GeoTIFF Standard. Annex B goes into more details about the change recommendations. These changes help implementors with the ability to locate objects (terrestrial or non-terrestrial).
The experiment looks at asteroids as targets to hit or avoid. Users of imagery and implementors of a future GeoTIFF Standard may want to identify celestial objects within the image. The same users and implementers need to understand the location for the image. Currently, the GeoTIFF Standard lacks a metadata tag that would describe the identity of the celestial objects in the image. The Standard also limits the CRS definitions and which registries the CRS definitions come from. This poses a problem when these objects do not fit into the realm of Earth coordinate systems. The registries for new coordinate systems will probably come from registries which specialize in classifying non-terrestrial coordinate systems. The ER recommends adding a tag describing the celestial bodies that an image contains to the GeoTIFF Standard. Additionally, adding 2D and 3D Spherical CRS and an Engineering CRS to the GeoTIFF Standard will help identify the location of the objects. Another issue is that the identifiers for parameter values can and do change over time such as the value identifiers for datum, ellipsoid, prime meridian, or unit of measurement. Users and applications of imagery may find it hard to determine what an identifier is referring to when the value of an identifier changes. Adding aliases in the CRS definition parameters to the GeoTIFF Standard will help users and applications understand the identifier by being able to understand one of the aliases of the identifier value.
Applying these recommendations to the GeoTIFF Standard helps users and implementors describe and geolocate objects (terrestrial or non-terrestrial). This supports missions to map the surface of other planets and moons by allowing the use of new CRS definitions that describe them. The changes also support missions for images of distant and smaller objects. With distant and smaller objects the images will contain spherical or localized coordinates specified by a CRS with identifiers of the object represented in the image.
6.1. Observed object identification
Having an engineering CRS centered on the camera (Section 4.1) implies that the CRS is no longer fixed to the observed object, as it was for images of Earth’s surface. Consequently, the CRS metadata no longer relays repeatable information about positions on the surface of the object. This ER does not propose metadata for identifying the observed object. The TIFF Image_description tag may be used for that purpose.
6.2. Coordinate transformations
Because of the low capacity of the GeoTIFF format to express metadata, coordinate transformations (Section 4.2) are better expressed in specialized formats such as Gridded Geodetic data eXchange Format (GGXF). This ER recommends the storing of coordinate transformations in a separated file using specialized formats. In the case of coordinate transformations based on a spacecraft trajectory, an application may use a Moving Feature file. A Moving Feature file allows applications to exchange information about features that are moving in time and come in a variety of encodings. An example is given in Section 5.
6.3. Ambiguity in current specification
At least one change request proposed in this ER depends on the resolution of an ambiguity in the current GeoTIFF Standard. This ambiguity is not specific to space, and seems to be an issue with the Standard even for a terrestrial CRS. The issue is that GeoTIFF defines keys for specifying the name of a CRS, but there is no key for specifying the name of CRS components such as datum, ellipsoid, prime meridian, operation method, or units of measurement. However, some requirements in the GeoTIFF Standard seem to implicitly require the capability to specify the component names. This issue is discussed in Annex B.2.1.
6.4. Open issue for GeoTIFF SWG
With the addition of 16 new GeoKeys and 5 model types, implementing these recommendations increases the complexity for implementations based on the GeoTIFF Standard. The complexity follows established approaches which an implementor should recognize from the current Standard. However, the GeoKey approach is limited with respect to CRS definitions and the GeoKeys added to the Standard. An alternative implementation is to abandon the GeoKeys approach and replace it with CRS definitions in the Well-Known Text (WKT) format, as defined by ISO 19162. However, doing that is similar to creating a new TIFF-derived format. Whether to accept the increase in complexity implied by this ER, or to create a new TIFF-derived format (such as BigTIFF), is a decision left to the OGC GeoTIFF Standards Working Group (SWG).
7. Future Work
The following issues were not resolved during Testbed 19. Future Testbeds could examine them if the SWG accept the issues and suggestions.
7.1. Projected CRS based on geocentric CRS
This ER proposes new GeoTIFF keys for associating a Geodetic Coordinate Reference System to a SphericalCS instead of an EllipsoidalCS. However, this ER does not address the case of Projected Coordinate Reference Systems, which have a GeodeticCRS as their base CRS. The usual map projection formulas are designed for a base geographic CRS, but it is unclear whether these formulas need to be modified when the base CRS is geocentric instead of geographic. If such a distinction is necessary, the GeoTIFF Standard requires additional GeoTIFF keys to distinguish the base CRS of a projected CRS.
7.2. Identification of the observed object
With the existing GeoTIFF keys and some of the new proposed keys, the Coordinate Reference System is also an indirect identification of the observed object. For example, if an image contains the definition of a ProjectedCRS with a name such as “Mars (2015) — Sphere / Mercator,” the reader or application knows that the observed body is the planet Mars. But if the CRS is an EngineeringCRS, then the CRS is no longer associated to the observed body, but rather associated to the camera. The CRS name is no longer a useful identification of the observed body. There are currently no GeoTIFF keys proposed as a replacement for providing information about the image content.
7.3. Deformation caused by camera lenses
The current recommendations assume that the spherical coordinate system centered on a camera’s lens is perfect. If the lens causes any deformations, then the image should be rectified for compensating those deformations. This is like the geo-rectification process commonly applied to remote sensing images of Earth’s surface. However, some GeoTIFF images of Earth are not geo-rectified. They contain the real-word coordinates of some pixels in the ModelTiepointTag. In those cases, it is up to the GeoTIFF reader to apply some warp operation on the image using those coordinates. The resulting images may vary depending on the warp algorithm chosen by the GeoTIFF reader. A similar approach could be applied for images in space, but has not been explored in this Testbed. Because ModelTiepointTag is more complex than a ModelTransformationTag, the GeoTIFF SWG may desire focusing on the ModelTransformationTag instead.
Annex A
(normative)
Abbreviations/Acronyms
2D
2 Dimensions — A reference to something that has an x-axis and y-axis, or width and height.
3D
3 Dimensions — A reference to something that has an x-axis, y-axis, and z-axis, or width, height, and depth.
CRS
Coordinate Reference System — A coordinate reference system defines several parameters that aid in the mapping of objects to a particular location in 2-dimensional or 3-dimensional space.
DART
Double Asteroid Redirection Test — A mission conducted by NASA and other agencies to deflect the motion of an asteroid.
DRACO
Didymos Reconnaissance and Asteroid Camera for Optical navigation — An optical sensor placed on the DART spacecraft for taking images during the flight.
EPSG
European Petroleum Survey Group — The group originally developed a registry of geodetic datums, spatial reference systems, the Earth Ellipsoids, coordinate transformations, and units of measure. The International Association of Oil & Gas Producers Geomatics Committee currently maintains the registry; however, the registry is still known as the EPSG registry.
GDAL
Geospatial Data Abstraction Library — An open source library that reads geospatial data.
GeoTIFF
Geographic Tag Imagery File Format — An extension of the Tag Imagery File Format (TIFF) to allow the specification of coordinates, datums, and coordinate reference systems within the TIFF ‘tag’ specification.
NASA
National Aeronautics and Space Administration — An agency of the United States Government.
PGW
Portable Graphic World file — A file that describes the affine transformation parameters for a PNG file.
PNG
Portable Network Graphics — A file format for raster files.
PRJ
Projection file — A file that describes coordinate system and map projection parameters in a Well Known Text format.
SWG
Standards Working Group — A group the Open Geospatial Consortium forms to create or update new or current standards.
TIFF
Tag Imagery File Format — A file format that acts as a container for storing imagery data. The data contains ‘tags’ that relay information about the imagery in the container.
WGS
World Geodetic System — One of several datum available to describe the shape of the Earth.
Annex B
(informative)
Change Requests
From experimentation, the Testbed 19 participants recommend the following changes for consideration by the GeoTIFF Standards Working Group.
A new GeoKey for a celestial body
Aliases in citations
New Defining Model Coordinate Reference System codes
New GeoKeys for an engineering CRS
New User-defined Coordinate Reference Systems
Registry other than EPSG
Most of those change requests have a corresponding pull request in the public OGC GeoTIFF GitHub Repository. The pull requests contain the changes proposed to the GeoTIFF Standard. In this annex and in the pull requests, all “TBD” strings are placeholders for numbers to be assigned sequentially as requirements are added to the specification.
B.1. New GeoKey for a celestial body
Define a new GeoKey for identifying the celestial body (Mars, Venus, etc.) in a GeoTIFF file. Producers of the image will use the key in User-defined Model Coordinate Reference Systems.
B.1.1. Sections in Standard to Edit
In particular, the Testbed 19 participants recommend updating the items below shown in italics within the Standard for User-defined geographic 2D CRS and User-defined geocentric CRS:
geocentric coordinate reference system name (through the GeodeticCitationGeoKey);
geodetic datum through the GeodeticDatumGeoKey, either:
the geodetic datum code (if available through standard EPSG code), or
user-defined geodetic datum name and other defining information:
the geodetic datum name (through the GeodeticCitationGeoKey),
if different from Earth, the celestial body name (through the CelestialBodyGeoKey)
…
In addition, the Testbed 19 participants recommend updating requirement 18.5 in the Requirement Class for GeodeticDatumGeoKey with the text in italics as follows.
If the GeodeticDatumGeoKey value is 32767 (User-Defined) then the GeodeticCitationGeoKey, PrimeMeridianGeoKey and EllipsoidGeoKey SHALL be populated and the CelestialBodyGeoKey SHOULD be populated if different from Earth.
Further, the Testbed 19 participants recommend adding a requirements class:
Requirements Class CelestialBodyGeoKey
Use this key to specify an identifier for the celestial body the image represents. The default value is “Earth.”
Table B.1 — Celestial Body Requirements Class
| Requirements Class TBD.0: CelestialBodyGeoKey | |
|---|---|
| www.opengis.net/spec/GeoTIFF/1.2/req/CelestialBodyGeoKey | |
| Requirement TBD.1 | www.opengis.net/spec/GeoTIFF/1.2/req/CelestialBodyGeoKey.ID The CelestialBodyGeoKey SHALL have ID = 2063 |
| Requirement TBD.2 | www.opengis.net/spec/GeoTIFF/1.2/req/CelestialBodyGeoKey.type The CelestialBodyGeoKey SHALL have type = ASCII |
Finally, the participants suggest modifying Table E.1 in the Annex for the Summary of GeoKey IDs and names with
Table B.2 — Celestial Body GeoKey Identifier and Name
| Key ID | Type | GeoTIFF v1.0 key name | GeoTIFF v1.0 key alias | This document key name |
|---|---|---|---|---|
| GeoTIFF Configuration Keys | ||||
| … | ||||
| 2063 | Ascii | CelestialBodyGeoKey | ||
| … | ||||
B.1.2. Open Questions
There was some discussion if the tag should support a hierarchical structure to identify an object within another object such as “Milky Way Galaxy / The Solar System / Moon.” The exact syntax is something the OGC GeoTIFF Standards Working Group should discuss further.
B.1.3. Pull request
The proposed changes are described in more detail in GitHub pull request #120.
B.2. Aliases in citations
Names and identifiers may change over time. Hence, allowing citations to have aliases may help users to understand the metadata property being described.
B.2.1. Prerequisite
This change proposal depends on the capability to store the name of many geodetic object names in a single GeoKey. The current GeoTIFF Standard does not define explicitly any structure for multiple names. However, the Standard seems to implicitly assume that multiple-names are allowed. For example:
Requirement 25.5 said: If the VerticalDatumGeoKey value is 32767 (User-Defined) then the VerticalCitationGeoKey SHALL be populated. This requirement seems to imply that the VerticalCitationGeoKey should be able to store the datum name in addition of the CRS name;
Requirement 27.5 said: if the ProjectionMethodGeoKey value is 32767 (User-Defined) then the ProjectedCitationGeoKey shall be populated. This requirement seems to imply that ProjectedCitationGeoKey should be able to store projection method name in addition of CRS name; and
the spherical moon example in F.3.4 stores multiple-names.
Issue #59 on GitHub suggests using the GDAL structure for storing multiple names in citation GeoKeys. This structure is at odds with the rest of the GeoTIFF Standard, as it is an additional level of encoding embedded inside GeoKeys, which are themselves an encoding embedded inside TIFF tags. However, if this practice is already well established, it may be preferable to accept the GeoKeys rather than defining a cleaner alternative. This section describes a change proposal that assumes the GeoTIFF issue #59 has been accepted.
The current GDAL practice described in issue #59 is applied only on the GeodeticCitationGeoKey. This practice uses the following “CitationKeys” (not to be confused with “GeoKeys”): GCS Name, Datum, Ellipsoid, Primem, and AUnits. If the same structure is applied also on VerticalCitationGeoKey and ProjectedCitationGeoKey, then the following CitationKeys would need to be added: CRS Name (or simply CRS), Method, and LUnits. Note that contrarily to GeoKeys, which are stored in GeoTIFF files by their numerical values, CitationKeys are stored by their names, so those names cannot be changed without breaking compatibility.
Alternatively, issue #59 could be abandoned and replaced by new GeoKeys. This approach would be cleaner because it avoids the third level of encoding introduced by #59. However, this approach; would be incompatible with current GeoTIFF readers.
B.2.2. Sections in Standard to Edit
The Testbed 19 participants recommend adding a requirement class with the following characteristics:
A GeodeticCitationGeoKey, ProjectedCitationGeoKey and VerticalCitationGeoKey may contain multiple names for two reasons:
for providing the names of components such as datum, ellipsoid, prime meridian, or unit of measurement; and
for adding an arbitrary number of aliases for the same component.
If a citation contains multiple names, then all names are encoded as key-value pairs separated by the pipe character (|, ASCII decimal code 124). For each pair, the key and the value are separated by the = character (ASCII decimal code 61). Each key can be one of the following:
Table B.3 — Tags that may have an alias
| Key name | Description |
|---|---|
| GCS Name | Name of the geodetic CRS |
| Datum | Name of the datum |
| Ellipsoid | Name of the ellipsoid |
| Primem | Name of the prime meridian |
| AUnits | Name of the angular unit of measurement |
The same key can be repeated multiple times. All occurrences of a key after the first one are aliases. Examples:
GCS Name = WGS84|Datum = World Geodetic System 1984 ensemble|Datum = D_WGS_1984|Ellipsoid = WGS_1984|Primem = Greenwich|AUnits = Decimal_Degree|
GCS Name = Moon 2000|Datum = D_Moon_2000|Ellipsoid = Moon_2000_IAU_IAG|Primem = Reference_Meridian|AUnits = Decimal_Degree|
The above suggests the following new GeoTIFF requirements class:
Table B.4 — Additions to the CitationGeoKeys Requirement Class
| Requirements Class 15.0: CitationGeoKeys | |
| http://www.opengis.net/spec/GeoTIFF/1.2/req/CitationGeoKeys | |
| … | … |
| Requirement 15.TBD | http://www.opengis.net/spec/GeoTIFF/1.2/req/CitationGeoKeys.name.pair The CitationGeoKeys MAY contain multiple names as key-value pairs, with each pair separated by the | character and, for any given pair, the key separated from the value by the = character. |
| Requirement 15.TBD | http://www.opengis.net/spec/GeoTIFF/1.2/req/CitationGeoKeys.name.key If multi-names encoding is used, then the keys SHALL be one of the following: GCS Name, Datum, Ellipsoid, Primem, or AUnits. |
| Requirement 15.TBD | http://www.opengis.net/spec/GeoTIFF/1.2/req/CitationGeoKeys.alias If multi-names encoding is used and the same key is used more than once, then all occurrences after the first one SHOULD be aliases. |
B.2.3. Pull request
The proposed changes are described in more detail in GitHub pull request #122. Pending approval from the GeoTIFF SWG, the commit that introduce aliases follows another commit for standardizing the GDAL structure for multiple names in citation GeoKeys.
B.3. New Defining Model Coordinate Reference System codes
Enabling spherical coordinate systems is necessary to describe the locations of objects in space. To support this, the Testbed 19 participants recommend adding several new codes which represent the new models.
B.3.1. Sections in Standard to Edit
The Testbed 19 participants recommend updating section 7.2.2 to support spherical and engineering coordinate systems.
This new GeoKey defines the type of Model coordinate reference system used, to which the transformation from the raster space is made:
Model CRS is unknown or unspecified;
Model CRS is a Geographic 2D CRS;
Model CRS is a Geocentric 2D (spherical) CRS;
Model CRS is a Geocentric 3D (Cartesian) CRS;
Model CRS is a Projected CRS;
Model CRS is user-defined;
Model CRS is a Projected CRS; and
Model CRS is user-defined.
Furthermore, the Testbed 19 participants recommend modifying the requirements class for GTModelTypeGeoKey with the following:
Table B.5 — Additions to the GTModelTypeGeoKey Requirements Class
| Requirements Class 8.0: GTModelTypeGeoKey | |
| http://www.opengis.net/spec/GeoTIFF/1.2/req/GTModelTypeGeoKey | |
| … | … |
| Requirement 8.4 | http://www.opengis.net/spec/GeoTIFF/1.2/req/GTModelTypeGeoKey.value
|
| … | … |
A note should be added with the following recommendation: the ISO 19111 axis directions of an Engineering CRS shall be (forward, port, up) in the Cartesian case, or (clockwise, up, away-from) in the spherical case, with away-from omitted in the 2D case; and the axis names of the spherical CS should be (Relative bearing, Altitude, Distance).
Lastly, the Testbed 19 participants suggest modifying section 7.5.1 with the following.
The GeogAngularUnitsGeoKey key is used to specify the angular unit for:
the axes in user-defined geographic 2D CRSs;
the axes in user-defined geocentric 2D (spherical) CRSs;
the horizontal axes in user-defined geographic 3D CRSs;
the longitude from the reference meridian in user-defined prime meridians; and
user-defined map projection parameters that are angles.
B.3.2. Pull request
The proposed changes are described in more detail in GitHub pull request #117 for the spherical 2D case, pull request #118 for the spherical 3D case, and pull request #119 for the engineering CRS case.
B.4. New GeoKeys for engineering CRS
Engineering coordinate systems define the position of the observer (sensor) that is creating images of moving bodies. The GeoTIFF Standard should include engineering coordinate reference systems.
B.4.1. Sections in Standard to Edit
7.4.5. Requirements Class Citation GeoKeys, in particular requirement 15.1
7.5.1. Requirements Class Units GeoKeys, in particular requirements 16
7.5.2. Requirements Class Unit Size GeoKeys, in particular requirements 17
The Testbed 19 participants recommend the following changes.
Add EngineeringCitationGeoKey in the list of keys in 7.4.5. Requirements Class Citation GeoKeys.
In requirement 15.1 add the following item:
The EngineeringCitationGeoKey SHALL have ID = 6145
In requirements 16.1 add the following items:
The EngLinearUnitsGeoKey SHALL have ID = 6147
The EngAngularUnitsGeoKey SHALL have ID = 6149
In requirements 16.2, 16.3, and 16.10 add EngLinearUnitsGeoKey and EngAngularUnitsGeoKey to the list of codes.
In requirement 16.4 add EngAngularUnitsGeoKey to the list of codes
In requirement 16.5 add EngLinearUnitsGeoKey to the list of codes
Rename requirement 16.10 as 16.12 then insert new requirements as below:
Table B.6 — Engineering Citation Additions to Requirements Class for Citation GeoKeys
| Requirement 16.10: | http://www.opengis.net/spec/GeoTIFF/1.2/req/UnitsGeoKey.userdefinedEngLinear An EngLinearUnitsGeoKey value of 32767 SHALL be a user-defined linear unit. If the value is 32767 (User-Defined) then the EngineeringCitationGeoKey and the EngLinearUnitSizeGeoKey SHALL be populated. |
| Requirement 16.11: | http://www.opengis.net/spec/GeoTIFF/1.2/req/UnitsGeoKey.userdefinedEngAngular An EngAngularUnitsGeoKey value of 32767 SHALL be a user-defined angular unit. If the value is 32767 (User-Defined) then the EngineeringCitationGeoKey and the EngLinearAngularSizeGeoKey SHALL be populated. |
In requirements 17.1 add the following items:
The EngLinearUnitSizeGeoKey SHALL have ID = 6148.
The EngAngularUnitSizeGeoKey SHALL have ID = 6150.
In requirement 17.2 add EngLinearUnitSizeGeoKey and EngAngularUnitSizeGeoKey to the list of codes.
In requirement 17.3 add the following items:
The units of the EngLinearUnitSizeGeoKey value SHALL be meters.
The units of the EngAngularUnitSizeGeoKey value SHALL be radians.
Insert a new section between 7.4.5 and 7.5.5 titled “Requirements Class Engineering Datum.” Insert requirements class as below:
Table B.7 — New Engineering Datum Requirements Class
| Requirement | Description |
| Requirement TBD.1 | The EngineeringDatumGeoKey SHALL have ID = 6146 |
| Requirement TBD.2 | The EngineeringDatumGeoKey SHALL have type = SHORT |
| Requirement TBD.3 | EngineeringDatumGeoKey values in the range 1-1023 SHALL be reserved |
| Requirement TBD.4 | EngineeringDatumGeoKey values in the range 1024-32766 SHALL be EPSG engineering datum codes |
| Requirement TBD.5 | If the EngineeringDatumGeoKey value is 32767 (User-Defined) then the EngineeringCitationGeoKey SHALL be populated. |
| Requirement TBD.6 | EngineeringDatumGeoKey values in the range 32768-65535 SHALL be private |
Insert a new section between 7.4.4 and 7.4.5 titled “Requirements Class EngineeringCRSGeoKey”. Insert the requirement class as below:
Table B.8 — New EngineeringCRSGeoKey Requirements Class
| Requirement | Description |
| Requirement TBD.1 | The EngineeringCRSGeoKey SHALL have ID = 6144 |
| Requirement TBD.2 | The EngineeringCRSGeoKey SHALL have type = SHORT |
| Requirement TBD.3 | EngineeringCRSGeoKey values in the range 1-1023 SHALL be reserved |
| Requirement TBD.4 | EngineeringCRSGeoKey values in the range 1024-32766 SHALL be engineering EPSG Engineering CRS codes |
| Requirement TBD.5 | If the EngineeringCRSGeoKey value is 32767 (User-Defined) then the EngineeringCitationGeoKey, the EngUnitsGeoKey and EngineeringDatumGeoKey SHALL be populated. |
| Requirement TBD.6 | EngineeringCRSGeoKey values in the range 32768-65535 SHALL be private |
In Annex E, add the following rows:
Table B.9 — New Engineering CRS Parameter Keys
| Key ID | Type | Name |
| Engineering CRS Parameter Keys (6144-7168) | ||
| 6144 | Short | EngineeringCRSGeoKey |
| 6145 | Ascii | EngineeringCitationGeoKey |
| 6146 | Short | EngineeringDatumGeoKey |
| 6147 | Short | EngLinearUnitsGeoKey |
| 6148 | Double | EngLinearUnitSizeGeoKey |
| 6149 | Short | EngAngularUnitsGeoKey |
| 6150 | Double | EngAngularUnitSizeGeoKey |
B.4.2. Pull request
The proposed changes are described in more detail in GitHub pull request #119.
B.5. New User-defined Coordinate Reference Systems
This change request proposes the addition of a geodetic CRS for the spherical case and the engineering CRS. The spherical case is not strictly needed for Testbed 19 CRS in space, but is proposed as a step before the definition of an engineering CRS. The spherical case is simpler because it reuses the existing GeoTIFF definition of datum, while an engineering CRS will require a new datum definition.
The GeoTIFF Standard does not distinguish Coordinate System (CS) from Coordinate Reference System (CRS). The two concepts are defined together. GeoTIFF already supports a geocentric coordinate reference system, but only in association with a Cartesian coordinate system. There is no geographic CRS associated with a spherical coordinate system.
B.5.1. Sections in Standard to Edit
The new user-defined coordinate systems requires expanded definitions in Annex B.2.3.. The proposed additions are in italic:
Prime Meridian
The coordinate axes of the system referencing points on an ellipsoid are called latitude and longitude.
More precisely, geodetic latitude and longitude are required in this GeoTIFF Standard.
Spherical latitude and longitude may also be used for geocentric CRS.
…
Geodetic latitude is defined to be the angle subtended with the ellipsoid’s equatorial plane by a perpendicular through the surface of the ellipsoid from a point. Spherical latitude is defined to be the angle subtended with the same plane but by a line from the point to the ellipsoid’s center.
Before User-defined geocentric CRS, the Testbed 19 participants recommend adding the following sections:
User-defined geocentric 2D (spherical) CRS
For a user-defined geocentric CRS associated to a two-dimensional spherical coordinate system,
the user is expected to provide the same GeoKeys as above in the geographic case.
The geocentric case is distinguished from the geographic case by the
ModelType GeoKey value, which is 5 instead of 3.
User-defined geocentric 3D (spherical) CRS
For a user-defined geocentric CRS associated with a three-dimensional spherical coordinate system,
the user is expected to provide:
geocentric coordinate reference system name (through the GeodeticCitationGeoKey);
geodetic datum through the GeodeticDatumGeoKey, either:
the geodetic datum code (if available through standard EPSG code); or
user-defined geodetic datum name and other defining information:
the geodetic datum name (through the GeodeticCitationGeoKey),
the ellipsoid (through the EllipsoidGeoKey, see User-defined ellipsoid), and
the prime meridian (through the PrimeMeridianGeoKey, see User-defined prime meridian);
latitude and longitude axis unit through the GeogAngularUnitsGeoKey, either:
angular unit code (if available through standard EPSG code), or
user-defined angle unit name (through the GeodeticCitationGeoKey) and scaling from SI base unit of meter (through the GeogAngularUnitSizeGeoKey); and
radius axis unit through the GeogLinearUnitsGeoKey, either:
length unit code (if available through standard EPSG code); or
user-defined length unit name (through the GeodeticCitationGeoKey) and scaling from SI base unit of meter (through the GeogLinearUnitSizeGeoKey).
Notes:
If the CRS uses a user-defined prime meridian, the prime meridian Greenwich longitude unit is defined by the same GeogAngularUnitsGeoKey as for latitude and longitude axes.
If the CRS uses a user-defined ellipsoid, the ellipsoid axis unit is defined by the same GeogLinearUnitsGeoKey as for radius axis.
Rename User-defined geocentric CRS to User-defined geocentric 3D (Cartesian) CRS.
For a user-defined geocentric CRS associated to a three-dimensional Cartesian coordinate system,
the user is expected to provide:
…
Then add a section User-defined engineering CRS.
For a user-defined engineering CRS the user is expected to provide:
engineering coordinate reference system name (through the EngineeringCitationGeoKey);
engineering datum through the EngineeringDatumGeoKey, either:
the engineering datum code (if available through standard EPSG code), or
user-defined engineering datum name and other defining information:
the engineering datum name (through the EngineeringCitationGeoKey);
axis unit, either:
linear unit through the EngLinearUnitsGeoKey, either:
linear unit code (if available through standard EPSG code), or
user-defined linear unit name (through the EngineeringCitationGeoKey) and scaling from SI base unit of radian (through the EngLinearUnitSizeGeoKey);
angular unit through the EngAngularUnitsGeoKey, either:
angle unit code (if available through standard EPSG code), or
user-defined angle unit name (through the EngineeringCitationGeoKey) and scaling from SI base unit of radian (through the EngAngularUnitSizeGeoKey).
The Testbed 19 participants recommend the following change to Annex B.3.:
The following subtypes of Model coordinate reference system (CRS) are recognized in GeoTIFF:
Geographic 2D;
Geocentric 2D (spherical);
Geocentric 3D (spherical);
Geocentric 3D (Cartesian);
Projected (‘map grid (2D)’);
Vertical; and
Engineering 2D (spherical).
B.5.2. Open questions
Should the GeoTIFF Standards Working Group rename the GeogAngularUnitsGeoKey name to GeodeticAngularUnitsGeoKey as that is what the GeoTIFF Standard seems to refer to in this context?
B.5.3. References
An Overview of Reference Frames and Coordinate Systems in the SPICE Context, in particular pages 24 and 25.
B.5.4. Pull request
The proposed changes are described in more detail in GitHub pull request #117 for the spherical 2D case and pull request #118 for the spherical 3D case.
B.6. Registries other than EPSG
The rationale for this change comes from the need to define non-terrestrial coordinate systems. The EPSG registry only contains terrestrial coordinate systems. There exist other registries that classify coordinate systems for various space objects such as http://voparis-vespa-crs.obspm.fr:8080/web/. The GeoTIFF Standard needs to support referencing new codes from registries maintained by a variety of authorities.
B.6.1. Sections in Standard to Edit
The Testbed 19 participants recommend the following changes.
In Annex E, add the following rows:
Table B.10 — Additions for Geodetic and Vertical CRS Parameter Keys
| Key ID | Type | Name |
| Geodetic CRS Parameter Keys | ||
| … | … | … |
| Reserved | 2063 | Ascii |
| GeodeticCRSTextDefGeoKey | 2064 | Ascii |
| GeodeticDatumTextDefGeoKey | 2065 | Ascii |
| EllipsoidTextDefGeoKey | 2066 | Ascii |
| … | … | … |
| Vertical CRS Parameter Keys (4096-5119) | ||
| … | … | … |
| (as GeoTIFF v1.0) | 4100 | Ascii |
| VerticalTextDefGeoKey | 4101 | Ascii |
| … | … | … |
After Section 7.4.5 add a section 7.4.6 as follows.
7.4.6 Requirements Class TextDef GeoKeys
The GeodeticCRSTextDefGeoKey, GeodeticDatumTextDefGeoKey, EllipsoidTextDefGeoKey, PrimeMeridianTextDefGeoKey, ProjectedCRSTextDefGeoKey, ProjectionTextDefGeoKey, VerticalTextDefGeoKey, and VerticalDatumTextDefGeoKey can be used to provide full CRS element definitions through ASCII free text.
The definitions can be one of the following forms.
Type 1: URL of the form http://www.opengis.net/def/crs/{authority}/{version}/{code}.
Type 2: Well-Known Text (WKT) as defined by ISO 19162:2019.
The type number is specified in the GeodeticCRSGeoKey, GeodeticDatumGeoKey, EllipsoidGeoKey, PrimeMeridianGeoKey, ProjectedCRSGeoKey, ProjectionGeoKey, VerticalGeoKey or VerticalDatumGeoKey.
Table B.11 — New TextDefGeoKeys Requirements Class
| Requirements Class TBD: TextDefGeoKeys | |
| http://www.opengis.net/spec/GeoTIFF/1.2/req/TextDefGeoKeys | |
| Requirement TBD.1 | http://www.opengis.net/spec/GeoTIFF/1.2/req/TextDefGeoKeys.ID
|
| Requirement TBD.2 | http://www.opengis.net/spec/GeoTIFF/1.2/req/TextDefGeoKeys.type The TextDefGeoKeys SHALL have type = ASCII |
| Requirement TBD.3 | http://www.opengis.net/spec/GeoTIFF/1.2/req/TextDefGeoKeys.url If the textual definition is a URL (type 1), then the Ascii string SHOULD be of the form http://www.opengis.net/def/crs/{authority}/{version}/{code}. The www.opengis.net part SHALL be something else if the defining authority is not OGC. A {version} value of 0 means to use the latest version of the definition. |
| Requirement TBD.4 | http://www.opengis.net/spec/GeoTIFF/1.2/req/TextDefGeoKeys.wkt _If the textual definition is a Well-Known Text (type 2), then the Ascii string SHALL be a valid WKT definition as specified by ISO 19162:2019. Carriage returns are allowed for readability and should be treated as white spaces. |
The following Requirements Classes should contain the following modifications:
Table B.12 — Modification to CRS, Vertical, Geodetic, Prime Meridian, Ellipsoid, Datum and Projection GeoKeys
| |
| … | … |
| Requirement TBD.2 | … |
| Requirement TBD | If the ProjectedCRSGeoKey, GeodeticCRSGeoKey, VerticalGeoKey, GeodeticDatumGeoKey, PrimeMeridianGeoKey, EllipsoidGeoKey, VerticalDatumGeoKey, or ProjectionGeoKey value is 1 (authority code specified by URL) or 2 (full definition provided by WKT 2), then the GeodeticCRSTextDefGeoKey SHALL be populated. |
| Requirement TBD.3 | ProjectedCRSGeoKey, GeodeticCRSGeoKey, VerticalGeoKey, GeodeticDatumGeoKey, PrimeMeridianGeoKey, EllipsoidGeoKey, VerticalDatumGeoKey, or ProjectionGeoKey values in the range 3-1023 SHALL be reserved. |
| … | … |
B.6.2. Pull request
The proposed changes are described in more detail in GitHub pull request #121.
Annex C
(informative)
Fix Requests
This annex describes change requests for what appear to be minor errors in the current GeoTIFF Standard. The issues discussed here are not specific to space.
C.1. Misplaced requirements
The GeoTIFF Standard contains a requirement saying:
keys for each map projection parameter (coordinate operation parameter) appropriate to that method SHALL be populated.
This requirement is currently associated with ProjectionGeoKey. This should be a ProjMethodGeoKey requirement instead. The key is significant because it defines when the parameters are mandatory. More details are provided in pull request #123.
C.2. Formatting
CoordinateEpochGeoKey appears in a column of Table E.1 that does not reflect the history of this key. More details in pull request #116.
C.3. Multiple-names
This issue was discussed in Annex B.2 but is also in this section as a gap because the GeoTIFF Standard seems to implicitly assume that multiple-names are supported. More details in issue #59.
Annex D
(informative)
Experiment details
The image used for this experiment was introduced in Section 5 above. A visual examination of the Dimorphos position in the image, combined with information about the distance and ellipsoid size, give the following approximate properties:
Table D.1 — Dimorphos referencing
| Property | Row axis | Column axis |
|---|---|---|
| Image size (pixels) | 1041 | 1041 |
| Minimal pixel coordinate | 481 | 503 |
| Maximal pixel coordinate | 539 | 555 |
| Dimorphos size (pixels) | 59 | 53 |
| Semi-axis length (meters) | 88.5 | 58 |
| Resolution (meters/pixel) | 3.00 | 2.19 |
| Resolution (arc-second/pixel) | 0.67 | 0.49 |
The assumption made in Testbed 19 by the participants are that the camera resolution is the same in all directions and takes an average value of 0.58 arc-second per pixel. Assuming that the (0,0) coordinates are at image center, 301.89 arc-seconds is the x and y coordinate of the image upper-left corner. Those coordinate values are positive and the scale factors below are negative because the image is flipped across the y axis (as usual in GeoTIFF images) and also across the x axis (as specified in above description). The 16×16 matrix to store in ModelTransformationTag is as below:
(D.1)
The target CRS of coordinates transformed by the above matrix is shown below. Note that the JPL namespace used below does not identify official JPL codes. This namespace is used only for demonstrating what the identifier may look like if JPL published CRS definitions in GML or WKT format.
EngineeringCRS["DART spacecraft spherical CRS",
EngineeringDatum["DART center of mass"],
CS[spherical, 3],
Axis["Relative bearing (θ)", clockwise, Unit["arc-second", 4.8481368110954E-6]],
Axis["Altitude (α)", up, Unit["arc-second", 4.8481368110954E-6]],
Axis["Distance (D)", awayFrom, Unit["kilometre", 1000]],
Scope["For identifying positions of objects relative to DART spacecraft."],
Id["JPL", -135, Citation["JPL:HORIZONS"]]]
Listing D.1 — Well-Known Text (WKT) definition of image CRS
The two first dimensions of above matrix and CRS are specified in the "DART_camera.pgw" and "DART_camera.prj" auxiliary files in the same directory as the "DART_camera.png" image file. The file extensions and the file contents follow the “World File” convention, except for the following departures:
metadata are added in the "DART_camera.xml" file using ISO 19115-3 format; and
the CRS definition in the "DART_camera.prj" file uses the WKT 2 format instead of WKT 1. This departure is for using EngineeringCRS.
Those files are then read by an Apache SIS prototype and rewritten in a GeoTIFF file using some of the tags described in Annex B. The prototype is available in the form of source code and compiled code in the prototype home page. Note that this prototype uses non-standards and non-released versions of GeoAPI and Apache SIS, because of the need for new classes described in OGC 23-042 and GeoTIFF tags described in this ER.
D.1. Running the prototype
Apache SIS is an open-source Java library for helping developers write their own geospatial applications. However, a small amount of Apache SIS functionalities are available from the command-line or from a Java shell. In the following example, texts on the right side of $ or jshell> are bash or JShell commands respectively, and other texts are outputs. The paths to the Apache SIS directory and to the DART data directory may need to be adapted. The first command shall be entered in a Unix shell for launching the Java shell (jshell) with Apache SIS dependencies. The second command is in Java code for encoding the DART_camera.png image in a new GeoTIFF file named DART_camera.tiff. For safety, this command does not overwrite existing files, so any previously existing output file should be deleted first. Finally the third command verifies the result.
$ ./apache-sis-2.0-SNAPSHOT/bin/sis_shell
jshell> SIS.TRANSLATE.metadata("*.xml").output("data/DART_camera.tiff").run("data/DART_camera.png")
jshell> SIS.CRS.run("data/DART_camera.tiff")
EngineeringCRS["DART spacecraft spherical CRS",
EngineeringDatum["DART center of mass"],
CS[spherical, 2],
Axis["Relative bearing (V)", CLOCKWISE],
Axis["Altitude (α)", up],
Unit["arc-second", 4.84813681109536E-6]]
jshell> /exit
Listing D.2 — Prototype execution
Currently, the SIS.CRS output produces the above WKT CRS above. The output is missing scope and identifier which are lost because there are not any corresponding GeoTIFF tags. The datum is lost too, unless the GDAL convention for Geodetic Datum name is applied also to Engineering Datum (GeoTIFF issue #59), which this prototype does. The Testbed 19 Participants are working on a GDAL extension for datum name. However, the participants do not have a screenshot of the extension to include in the ER. Running the current gdalinfo command (gdalinfo data/DART_camera.tiff) shows an empty ENGCRS, because the GeoTIFF tags used in this experiment are not yet standardized and are not recognized by GDAL.
The JavaFx application can see the GeoTIFF tags. A user may launch the application by issuing ./apache-sis-2.0-SNAPSHOT/bin/sisfx on the command-line. The tags from JavaFx look like what the ER shows in the image below. There are not many tags in this particular example, but the prototype can handle more.
Figure D.1 — TIFF and GeoTIFF tags in the encoded image
Annex E
(informative)
BigTIFF
BigTIFF is a variant of the TIFF format in which 32-bit pointers and offsets are replaced by 64-bit pointers and offsets. The BigTIFF format is incompatible with the TIFF format. However, the differences are minimal and existing TIFF readers can be adapted for reading BigTIFF with a reasonable number of changes. BigTIFF is currently not an OGC standard; but is supported by some libraries such as GDAL and Apache SIS and has its non-official specification website.
Standardizing the BigTIFF specification has been proposed. Since BigTIFF is a new format and breaks compatibility with TIFF anyway, a BigTIFF standard may take this opportunity for introducing a few more incompatible changes described below.
E.1. Sparse BigTIFF
When an image contains many empty tiles, space can be saved by not writing those tiles at all. The space gain can be very large for uncompressed images, but is still significant even for compressed images if only a small fraction of the tiles are non-empty. A use case observed in practice is an image where tiles exist only along the coastline of a country.
GDAL supports such sparse images by allowing the offsets of empty tiles to be zero with a length of zero. Apache SIS also accepts this convention for TIFF and BigTIFF. This convention could be standardized for BigTIFF only as it is a different format than TIFF.
E.2. Remove tile size constraint
The TIFF specification requires that tile sizes are multipliers of 16 bytes. Removing this constraint for a BigTIFF format should be considered. This makes choosing a tile size easier, thus reducing the amount of space wasted in the left and bottom sides of the image.
E.3. Notes on a BigTIFF oddity
The current BigTIFF non-official specification defines numberOfTags as a 64-bits integer instead of a 16-bits integer. However, given that TIFF tags are 16-bits integers, and given that a TIFF tag can’t be repeated, BigTIFF files can never contain more than 2¹⁶ tags. Consequently, the change of numberOfTags size seems an unnecessary departure from TIFF specification. However, this change can probably not be reversed since it would break existing BigTIFF readers.
Bibliography
[1] Roger Lott: OGC 18-005r5, Topic 2 — Referencing by coordinates Corrigendum. Open Geospatial Consortium (2021). http://www.opengis.net/doc/AS/topic-2/5.0.1.
[2] Martin Desruisseaux: OGC 22-038r2, Testbed-18: Reference Frame Transformation Engineering Report. Open Geospatial Consortium (2023). http://www.opengis.net/doc/PER/T18-D025.
[3] 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.
[4] Akinori Asahara, Ryosuke Shibasaki, Nobuhiro Ishimaru, David Burggraf: OGC 14-084r2, OGC® Moving Features Encoding Extension: Simple Comma Separated Values (CSV). Open Geospatial Consortium (2015). http://www.opengis.net/doc/IS/movingfeatures/csv-extension/1.0.0.
[5] ISO: ISO 19111, Geographic information — Referencing by coordinates. International Organization for Standardization, Geneva https://www.iso.org/standard/74039.html.
[6] OGC: OGC 23-042: Non-Terresterial Geospatial Engineering Report, 2023.
[7] IOGP: EPSG Geodetic Parameter Dataset. https://epsg.org
[8] ESA: Didymos and Dimorphos seen by DART, 2023. https://www.esa.int/ESA_Multimedia/Images/2023/02/Didymos_and_Dimorphos_seen_by_DART
[9] OGC: Gridded Geodetic data eXchange Format (GGXF). https://github.com/opengeospatial/CRS-Gridded-Geodetic-data-eXchange-Format/