Recommendations to the Open Navigation Surface Working Group (ONSWG) from the sub-working group for BAG coordinate reference system metadata

2022-10-21

Background

Historically maps were static products, but the advent of Geographic Information System technology has driven a need for accurate coordinate reference system (CRS) metadata to facilitate display and use of data in concert with other sources. Using data with different CRSs necessitates transformations to display or perform work on the data within the same context. The uncertainty associated with CRS transformations is often not well tracked, leading to ambiguity in the data quality and significant capability shortfall in the Bathymetric Attributed Grid (BAG) as a standard.

The vertical part of a CRS has often been treated secondary to the horizontal part: Data were often acquired relative to a given vertical datum (control), where uncertainty was inherently managed in a pass/fail sense with respect to application to a specific product assembly (e.g., nautical charting). Modern marine geodesy context requires an unambiguous reference and record of the CRS in the BAG. For example, references to "mean lower low water" or "WGS84" lack rigor, limiting the utility of the bathymetry data with respect to modernized navigational requirements and geomatics in general.

The sub-working group for vertical CRS metadata was tasked with finding a solution that exists in current standards to facilitate use of the BAG (ONSWG Meeting minutes 2022-06-09) after a decision could not be made to address the concerns raised in the position paper (Vertical CRS Storage in BAG Metadata). Goals and Guidance for the group, meeting minutes from the group and any code generated for testing can be found in the GitHub repository and Wiki.

Discussion

The BAG library currently expects the CRS to be broken into two components: horizontal and vertical. To precisely reference in the BAG XML metadata the defining vertical CRS we must accommodate both three-dimensional (position vector) and specialized compound-system realizations.

EPSG codes

While EPSG codes have become common for horizontal coordinate systems, many vertical systems do not have an EPSG code or multiple realizations of "the same" CRS are lumped together within an ensemble definition. Metadata which references such an ensemble CRS obfuscates the quality of information and complicates the construction of an authoritative composite product from different sources. The requirement to register new CRS definitions and their subsequent realizations to the EPSG registry before they may be referenced in BAG metadata is not a tenable solution. In the case of NOAA, mapping and charting data are linked to numerous localized ortho-tidal datum definitions over time. Although it was strongly recommended by the working group to consider an "EPSG solution", the sub-working group does not consider EPSG codes to be a self-contained solution that is ready for all BAG CRS metadata needs.

Well Known Text (WKT), WKT2, and the Bound CRS

The WKT code space is currently the common way to express a CRS in the BAG for versions later than 1.4. The current standard definition is ISO 19162:2019 (WKT2) and its use continues to grow and supplant the initial WKT format (WKT1) defined by the Open Geospatial Consortium (OGC). As it currently stands, the BAG library includes simple passthrough support of the georeferencing text between the user and the metadata store, leaving it up to the client's application program to distinguish between WKT2 and older WKT formats.

For any WKT that may be used in the BAG, at a minimum, the vertical CRS metadata elements should be explicit about: descriptive name, vertical axis orientation (must be up, for BAG dictates elevations only), vertical units (must be meters for BAG), epoch (if time dependent; e.g., those involving an ortho-tidal data realization), and, optionally, the relevant ESPG code(s) that do not otherwise conflict with any information in the WKT or as mandated by the BAG specification.

WKT2 has the advantage of supporting the bound CRS (BoundCRS) construct to model any source CRS (SourceCRS) through an association to a truly well-known target CRS (TargetCRS). The association is by way of an (abridged) transformation structure that includes various vector and gridded coordinate operation methods and parameters to express a SourceCRS-to-well-known-TargetCRS coordinate mapping definition. Because the WKT2 CRS coordinate transformation metadata affords for an explicit encoding, there is no need to limit or otherwise misconstrue BAG "datum transformation parameter group" metadata to be that of EPSG 9606 (position vector), as mentioned in the current BAG Format Specification Document (Release 1.6.3).

It is important to note that, contrary to its name, in WKT2 the BoundCRS is not a CRS; instead, a BoundCRS is instead an object that has a CRS (the SourceCRS), with a definitive relationship to another CRS (the TargetCRS). In the coordinate transformation software PROJ, the BoundCRS is used to be able to represent the legacy TOWGS84[] construct of WKT1 in terms of WKT2. In PROJ, the BoundCRS is regarded as a CRS and it equates to the SourceCRS; the TargetCRS constitutes the recognized "pivot CRS", whether that may be defined using a WGS84 CRS or any other CRS that is relatable via the abridged transformation construct. The BoundCRS is a ready and effective way to record the BAG coordinate system in WKT2 when other registered CRS and WKT formatting options fall short.

Handling the current state

Ideally the CRS is specified in a single XML entry of WKT, but such that there is no ambiguity when faced with the current option in BAG metadata of two separate CRS clauses: one (first) field for horizontal CRS and a second field for vertical CRS. Opting for a compound or three-dimensional (3-D) CRS in the BAG metadata means the second should be blank and ignored. To preserve backward compatibility for BAG metadata that describes only a horizontal CRS, the default vertical CRS of ‘unknown’ would continue to apply and require either updating by the issuing agency or some continued intervention by the data user. In the future perhaps a compound or 3-D CRS should be required and the second field omitted.

We recognize that the decision to accommodate WKT2 may make translation of BAG metadata into the metadata of other formats more difficult. For example, while we were able to demonstrate the use of a BoundCRS in a GeoTIFF, as a common and open format, using GDAL, the result made use of a sidecar file rather than storing the georeferencing information internal to the GeoTIFF. While this risks loss of the georeferencing information when using a GeoTIFF, it does demonstrate the translation to a common format.

Coordinate transformation support

The previous BAG specification does contain reference to a "datum transformation parameter group" (BAG spec geo-referencing), but no other reference to this information in the BAG specification or BAG library was found.

The BoundCRS construct is a reasonable way to specify a CRS in a self-describing manner. We have demonstrated the creation and use of a BoundCRS as part of the examples found in the repository associated with this sub-working group. While perhaps not ideal, we believe the use of the PROJ-based coordinate operation method in the BoundCRS abridged transformation clause is reasonable and quite practical when coordinate system datums are described relative to others through a pipeline of parameter files. Indeed, no other option exists to capture a multistep transformation in the WKT of the BoundCRS. NOAA VDatum geodetic ortho-tidal transformations involve two to three grids; even if all the required multistep conversion realizations were collapsed to use just a single grid each, that would not cover all use cases. This would be possible, for example, via coordinate operation method "Geog3D to Geog2D+GravityRelated Height (gtx)" (EPSG 1088), but that precludes a source CRS of any type other than geographic: BAGS are often published in a source CRS that is projected (e.g., UTM).

If using a BoundCRS, we recommend that the SourceCRS be of type compound to enforce consistency between the horizontal and vertical frames; in general, we expect the horizontal CRS here to be well known such that its role in the BoundCRS transformation is easily accommodated. As discussed above, the TargetCRS should be truly well known to facilitate the coordinate transformation of the BAG source data into a variety of other coordinate options.

The potential lack of access to BoundCRS parameter file data (e.g., vertical transformation grids) impacts coordinate transformation utility. The BAG Vertical Surface Correctors dataset presents a convenient location to convey this essential information short of some other content delivery route, although this operation was not tested by the sub-working group. To support this option, a way to reference the authoritative source parameter files should be accommodated in the BAG Vertical Surface Correctors metadata.

Transformation uncertainties are expected to be applied appropriately to the uncertainty layer, thereby ensuring suitability for navigation and other applications in geomatics. We do not expect transformation histories to be incorporated into the BAG.

To capture a formal record of coordinate epoch or reference frame epoch in WKT, the COORDINATEMETADATA[] (not supported by PROJ currently) and the DYNAMIC[FRAMEEPOCH[]] construct are available (resp.) but limited to the CRS of type dynamic. In EPSG, a CRS variety is often registered as static only, but alternative time realizations from the base definition may nonetheless be required to complete the metadata description. The CRS type would either need to be changed or distinct dynamic CRSs must be registered in EPSG to cover this situation; alternatively, the WKT ID[] construct presents a more nimble way to identify the CRS epoch, as well as other descriptive metadata including name, authority, and other attributes.

Applicable geographic area of usage (WKT extent) of the CRS presents a somewhat similar challenge. In EPSG, an applicable CRS (or coordinate operation or associated datum) may for example include usage details of an "onshore" extent only. Again, the recourse is to submit a request to change the existing registered definition, or expand the EPSG registry with a new instance. It is also worth noting that the EPSG-registered extent includes a code to reference (any) detailed geometry. WKT includes a text representation of geometry, but the CRS, etc. WKT includes just a descriptive name (AREA) and possibly bounding box (BBOX) coordinates; neither the extend code nor the WKT geometry format is included.

Validation

It is important again to recognize that the CRSs are currently just passed through as text to and from the user. Adding validation would in turn add significant code to the BAG which would need to be maintained, with the obvious benefit of improving overall quality of BAGs written via its API. If the ONSWG decides that this additional overhead is worth pursuing, we recommend adding PROJ as a dependency to minimize the work to keep validation up-to-date with the latest CRS definitions and transformation utility. Nonetheless, an important part of the validation process should be to enforce the simpler parts of the BAG specification: elevation in meters, positive up.

While it would be beneficial to validate BAGs written by the BAG library, it is important to consider BAGs written outside of that, such as GDAL currently. Specifications that are "machine readable" in this regard are desirable, but exhaustive validation details of the BAG metadata is outside of the scope of this sub-working group.

Notes

OGC WKT 18-010r7, Version 2.0.6, Annex B.8 Version of CRS WKT

BoundCRS examples from OGC specification

Example of a BoundCRS as proposed by Coast Survey to deal with NOAA VDatum CRS realizations

Recommendations

• WKT2 is allowed and preferred in the BAG format specification moving forward, but older WKT should continue to be supported for backward compatibility.
• The version of WKT must be consistent throughout a given BAG dataset.
• The BAG metadata should included an identifier for the reference system description type to be explicit as to whether WKT2 or older WKT is used.
• If a CompoundCRS or 3D CRS is used it shall be placed in the first XML field.
• A BoundCRS shall be compound if used.
• Use of the PROJ-based coordinate operation method is permitted in the BoundCRS abridged transformation.
• EPSG in the WKT is helpful if available, but not required.

References

Open Navigation Surface Working Group (ONSWG) Meeting minutes 2022-06-09

Bathymetry Attributed Grid (BAG) Coordinate System Orientation and Geo-Referencing

ONSWG BAG CRS metadata sub-working group GitHub repository

Vertical CRS Storage in BAG Metadata

Open Geospatial Consortium (OGC) Well Known Text (WKT)

OGC Implementation Standard document for WKT: 18-010r7, Version 2.0.6

EPSG Geodetic Parameter Registry

PROJ