Include vertical transformation models in spatial reference frame information

[kjwaters]

Kirk Waters NOAA

Requirement(s)

Supply a field or structure in the metadata to define the vertical transformation model that was used to calculate the vertical coordinates in the spatial reference frame. This is typically the geoid model used to transform from ellipsoid heights to orthometric heights, but could be other models too.

Problem Statement

Elevation data is typically produced in orthometric heights or referenced to a tidal datum. For modern GPS derived data, that production requires the application of one or more models to convert from ellipsoid heights to the final datum. The information does not currently have a clear location in metadata. An end user may be lucky enough to find it in the abstract, but it isn't in machine readable location. As new models are developed that come closer to the idealized datum, there is a need to know the old model in order to reverse it and apply the new model. An example of this need is when differencing data from two time periods and ensuring that the differences are not due to the models.

Stakeholders that experience this issue include surveyors and engineering firms working with elevation data. Federal agencies include FEMA, NOAA, USGS, and possibly all the agencies in the 3D Elevation Program.

Target Audience / Stakeholders

• User 1. Producers of elevation data, especially where GPS/GNSS was involved.
• User 2. Developers of automated datum conversion tools (e.g. GIS software suppliers)
• User 3. Data Consumers in the elevation domain.

Intended Uses / Use Cases

Know the model(s) applied in a data set.

Existing Approaches - Optional

Optional references to standards and examples of established approaches with a potential for reuse in DCAT

Additional context, comments, or links - Optional

Some examples of geoid models can be found at https://geodesy.noaa.gov/GEOID/. NGS is also planning to release new time-dependent reference frames in the near future. I anticipate we will need some mechanism to adequately describe them in the metadata in a standard format.

[fellahst]

The section about handling of map projection and coordinate systems in spatial metadata provides guidance about the handling of coordinate reference systems.

[kjwaters]

That section does not address the vertical component, though specifying the vertical reference frame is not the issue. It is very common to apply a model (transformation) to change from GPS originating coordinates to orthometric coordinates that people work with. There needs to be a place to record what model was used.

Sent from a mobile device subject to autocorrect errors.

On Thu, Jan 11, 2024 at 6:00 PM fellahst @.***> wrote:

The section about handling of map projection and coordinate systems https://doi-do.github.io/dcat-us/#map-projections-coordinate-systems in spatial metadata provides guidance about the handling of coordinate reference systems.

— Reply to this email directly, view it on GitHub https://github.com/DOI-DO/dcat-us/issues/16#issuecomment-1888101444, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA5B33OEYCUIBI7POY36MFDYOBVIPAVCNFSM6AAAAAAZE74AAOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBYGEYDCNBUGQ . You are receiving this because you authored the thread.Message ID: @.***>

[fellahst]

Thank you for your valuable insights regarding the DCAT-US specification. We understand the importance of balancing simplicity and expressiveness, especially when it comes to spatial metadata standards.

Given that EPSG standards already provide codes for vertical reference systems, like the method described at https://epsg.io/9840-method, we're keen to understand if these are sufficient for DCAT-US purposes or if there are specific scenarios where they might fall short. Your perspective on whether the lack of detailed transformation model information in spatial metadata could hinder users in finding and utilizing data would be greatly appreciated.

We also wish to consider the balance between complexity and utility that comes with adding specific transformation model details, and the impact this change could have on data providers in terms of implementation challenges.

Your expertise is invaluable in helping us refine the DCAT-US specification to best serve our user base, and we look forward to your further insights on these matters.

[fellahst]

Considering the discussion in the thread, it's clear that the use case for including transformation model details in the DCAT-US specification, particularly for elevation data, has not been fully defined in terms of its impact on search and discovery. It's crucial to understand how the inclusion or exclusion of such details affects end-user experience and data utility. I recommend reassessing this during the implementation phase to see if the current approach addresses the issue effectively. If the goals and specific use case remain unclear, it might be beneficial to reconsider the proposed changes or even close this thread until a more defined use case is established.

[TDabolt]

Would recommend FGDC perspective.

[kjwaters]

I'm getting a little confused by the links you're providing. Or perhaps it's an indication that I'm not being clear enough. The orthographic reference https://epsg.io/9840-method you provided relates to making an orthographic projection. This is not the same thing as an orthometric vertical datum.

The typical process for broad area elevation data using airborne technologies (e.g. lidar, IfSAR, and probably stereo photography) is going to involve using GPS to know where your airplane was during each collection event (laser pulse, camera exposure, etc). That GPS location is relative to a reference frame (likely a specific ITRF in the WGS84 family). From there, we can mathematically transform to other reference frames such as NAD83(2011) or the future NATRF(2022) through published relationships. You would also move from an earth centric XYZ reference frame to a latitude, longitude, ellipsoid height frame. All those things are well known and defined by saying, for instance, you're in NAD83(2011) ellipsoid heights. If we want to get to the North American Vertical Datum of 1988 (NAVD88) from those ellipsoid heights, we have to apply a geoid model. Documenting that the data is in NAVD88 vertically does not tell you which geoid model was used and there are multiple models. If, in a couple of years, you wanted to transform your data from NAVD88 as you have it currently, to the new U.S. vertical datum (North American-Pacific Geopotential Datum of 2022 (NAPGD2022)) and don't know the geoid that was used to get to NAVD88, then you don't know how to get there. Even neglecting the new reference frames, you can't calculate the temporal change between two NAVD88 elevation datasets unless you know they used the same geoid model.

Kirk

On Wed, Jan 31, 2024 at 1:17 PM TDabolt @.***> wrote:

Would recommend FGDC perspective.

— Reply to this email directly, view it on GitHub https://github.com/DOI-DO/dcat-us/issues/16#issuecomment-1919661819, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA5B33ODOFEGKOUIOOCCITTYRKDB3AVCNFSM6AAAAAAZE74AAOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJZGY3DCOBRHE . You are receiving this because you authored the thread.Message ID: @.***>

[fellahst]

In DCAT-US, the dct:conformsTo property from the Dublin Core Terms vocabulary is a user-friendly way to indicate that a dataset or distribution conforms to a certain standard or specification, including geoid models. This approach is designed to be straightforward and avoids the use of advanced technical jargon, making the specification accessible to a wide audience.

Here's how you might use dct:conformsTo to indicate the geoid model that a dataset conforms to:

1. Identify the Geoid Model Standard: First, identify the specific geoid model that your dataset conforms to (e.g., EGM96, GEOID18).

2. Use a URI for the Geoid Model: If there is a URI that uniquely identifies the geoid model standard (like an entry in a standards registry or a document describing the model), use this as the reference.

3. Describe the Dataset in RDF Using DCAT: When describing your dataset, include the dct:conformsTo property to link it to the geoid model.

Here's an example in RDF/Turtle syntax:

@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix ex: <http://example.org/data#> .

ex:myDataset
    a dcat:Dataset ;
    dct:title "Elevation Data for Region X" ;
    dct:description "This dataset contains elevation data for Region X, referenced to the GEOID18 model." ;
    dct:conformsTo <http://example.org/standards/geoid18> .

In this example:

• ex:myDataset is the URI for your dataset.
• dct:title and dct:description provide basic information about the dataset.
• dct:conformsTo links to the URI <http://example.org/standards/geoid18>, which represents the GEOID18 geoid model standard. Replace this URI with the actual reference URI for the geoid model you are using.

If a URI for the geoid model standard does not exist, you can alternatively use a literal value that clearly identifies the standard, although using a URI is preferable for unambiguity and linking to external resources. I can add a note in the specification about the use of conformsTo to support geoid model references, if you are satisfied with this approach.

[mrratcliffe]

+1

[RogerLott]

In the EPSG Dataset, geoid (and hydroid) models are described as coordinate transformations, between a source 3D georaphic CRS (e.g. NAD83(2011) and a target 1D vertical CRS (e.g. NAVD88 height). The transformation name is somewhat opaque in that it comprises the names of the source and target CRSs, but an alias gives the model name. A text search using model name 'geoid18' will return three entries, the geoid18 models for CONUS (https://epsg.org/transformation_9229/NAD83-2011-to-NAVD88-height-3.html), Alaska, and PRVI. EPSG does not include 'scientific' geoid models, only those that are used for the production of vertical CRS coordinate from GNSS observations. But with this caveat, citing the EPSG code for the transformation will provide adequate metadata.