[pdal] NAD83 ellipsoid heights in entwine

Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[pdal] NAD83 ellipsoid heights in entwine

Kirk Waters - NOAA Federal
This may also relate to a recent question on "Unknown" values in WKT strings. I'm trying to create EPT files where my horizontal coordinates are in NAD83 UTM and my vertical are ellipsoid heights. There isn't a lot of information that I could find about how to set up the reference system for something like that. The recommendations in the OGC GeoTIFF documentation suggest you could do something like putting the projected 2D CRS in the horizontal and the code/description for the geographic 3D reference system in the vertical. There is no EPSG code for NAD83 ellipsoid heights except as part of a 3D reference system. 

Do you have any idea how I can specify those coordinates such that entwine or pdal will understand it? They currently do not recognize the 3D CRS code (e.g. 6319 for NAD83(2011) ellipsoid) as a legitimate vertical choice. Is there a WKT for this that just isn't well known to me? I think it isn't only NAD83 that has this issue. I have checked in with EPSG on this before. The response didn't get me very far, but I'll put it here in case it helps someone else.

In the ISO data model (which EPSG follows) ellipsoidal height has been defined as the vertical component of a 3D geographic coordinate reference system. An ellipsoidal height definitely cannot exist on its own as a 1D vertical CRS, and therefore cannot be part of a compound 2D + 1D CRS..

However there has been some recent discussion regarding whether the concept of a 3D projected CRS (easting northing with ellipsoidal height) is valid. Superficially it sounds possible. But there are some in the geodetic parts of NOAA and other national mapping agencies that are doubtful as to whether the concept is valid. There are sound technical arguments for why the concept may be invalid. These revolve around the map projection process being tangential to the ellipsoid surface and not on it.

We in the IOGP geodesy subcommittee are seeking evidence of an appropriate implementation. We have yet to have explained a valid case. Most of the evidence we have collected so far turns out to be imagery being draped over a TIN and it then transpires that the heights in the TIN are gravity-related, not ellipsoidal. These are not academic questions, for if a projected 3D CRS construct were to be possible, we can envisage a number of ways in which the components could be created. For spatial data management there are plusses and minuses in each of these. We wish to fully understand the pros and cons before we contemplate populating what, if we got it wrong, could turn out to be inappropriate records in the EPSG Dataset.


While it seems like the EPSG answer says my reference system isn't valid, I'm not convinced. Lidar collections are going to start in the 3D coordinate system (lat, lon, ellipsoid heights). If they then have a geoid applied to get to orthometric prior to projecting, that seems to be considered valid (e.g. NAD83 UTM + NAVD88), but if you don't apply the geoid, it's invalid. That makes no sense.

Thanks,

Kirk Waters, PhD, BJCP          | NOAA Office for Coastal Management
Applied Sciences Program      | 2234 South Hobson Ave
843-740-1227 (empty office)   | Charleston, SC 29405
843-324-2203 (cell during COVID)    


_______________________________________________
pdal mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pdal
Reply | Threaded
Open this post in threaded view
|

Re: [pdal] NAD83 ellipsoid heights in entwine

Howard Butler-3


On Oct 5, 2020, at 10:37 AM, Kirk Waters - NOAA Federal <[hidden email]> wrote:

This may also relate to a recent question on "Unknown" values in WKT strings. I'm trying to create EPT files where my horizontal coordinates are in NAD83 UTM and my vertical are ellipsoid heights. There isn't a lot of information that I could find about how to set up the reference system for something like that. The recommendations in the OGC GeoTIFF documentation suggest you could do something like putting the projected 2D CRS in the horizontal and the code/description for the geographic 3D reference system in the vertical. There is no EPSG code for NAD83 ellipsoid heights except as part of a 3D reference system. 

Do you have any idea how I can specify those coordinates such that entwine or pdal will understand it? They currently do not recognize the 3D CRS code (e.g. 6319 for NAD83(2011) ellipsoid) as a legitimate vertical choice. Is there a WKT for this that just isn't well known to me? I think it isn't only NAD83 that has this issue. I have checked in with EPSG on this before. The response didn't get me very far, but I'll put it here in case it helps someone else.

In the ISO data model (which EPSG follows) ellipsoidal height has been defined as the vertical component of a 3D geographic coordinate reference system. An ellipsoidal height definitely cannot exist on its own as a 1D vertical CRS, and therefore cannot be part of a compound 2D + 1D CRS..

However there has been some recent discussion regarding whether the concept of a 3D projected CRS (easting northing with ellipsoidal height) is valid. Superficially it sounds possible. But there are some in the geodetic parts of NOAA and other national mapping agencies that are doubtful as to whether the concept is valid. There are sound technical arguments for why the concept may be invalid. These revolve around the map projection process being tangential to the ellipsoid surface and not on it.

We in the IOGP geodesy subcommittee are seeking evidence of an appropriate implementation. We have yet to have explained a valid case. Most of the evidence we have collected so far turns out to be imagery being draped over a TIN and it then transpires that the heights in the TIN are gravity-related, not ellipsoidal. These are not academic questions, for if a projected 3D CRS construct were to be possible, we can envisage a number of ways in which the components could be created. For spatial data management there are plusses and minuses in each of these. We wish to fully understand the pros and cons before we contemplate populating what, if we got it wrong, could turn out to be inappropriate records in the EPSG Dataset.


While it seems like the EPSG answer says my reference system isn't valid, I'm not convinced. Lidar collections are going to start in the 3D coordinate system (lat, lon, ellipsoid heights). If they then have a geoid applied to get to orthometric prior to projecting, that seems to be considered valid (e.g. NAD83 UTM + NAVD88), but if you don't apply the geoid, it's invalid. That makes no sense.

Kirk,

I reached out to Even and he asked the GeoTIFF group. The discussion on the topic you might participate in is at https://github.com/opengeospatial/geotiff/issues/82

Howard


_______________________________________________
pdal mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pdal