[GRASS-dev] [LAStools] Datum converson

FYI

Doug

---------- Forwarded message ----------
From: Gottfried Mandlburger <gm@ipf.tuwien.ac.at>
Date: Tue, Sep 17, 2013 at 3:40 AM
Subject: Re: [LAStools] Datum converson
To: lastools@googlegroups.com
Cc: “Heidemann, Hans” <kheidemann@usgs.gov>

Dear all,

I’d like to jump into this discussion concerning 2D and 3D transformation as I strongly believe this is a hot issue. Howard was referring to proj.4+gdal+libgeotiff (GDAL/OGR) and said that it provides the 3D transformation. True, if you want to transform from geometrically defined (i.e. ellipsoidal) heights in the source datum to ellipsoidal heights in the target datum. True also for specific orthometric height systems like NAVD88 as long as the required geoid undulations are available in the correct format and at the expected place (on disc). But this dataset is restricted to North America. For the rest of the world, geoid undulation w.r.t the WGS84 spheroid are available via the EGM2008 model but, however, in general the the federal geodetic administrations provide more precise local geoid models. All these models are not supported in GDAL/OGR. If you would like to use them, you would have to hack the library. In other words, user-defined geoid models are not supported by the library (nor is there an established (OGC, …) standard), and therefore, the spatial reference system transformations by GDAL/OGR cannot be regarded as being full 3D.

Concerning datum transformations in general, there is another issue. Currently, we have two commonly accepted ways for performing the datum transition:

  1. Via a 7-parameter spatial similarity transformation (3 shifts, 3 rotations, 1 scale). This is established in the OGC “Coordinate Transformation Services” standard (http://www.opengeospatial.org/standards/ct) by the TOWGS84 parameter in the Well-Known-Text representation. However, due to inconsistencies in the (historically grown) national surveying systems, multiple 7P datasets are necessary to transform from the inhomogeneous national system (eg. NAD…, DHDN/Germany, MGI/Austria…) to the (homogeneous) trans-national system (WGS84, ETRS89, ITRS…) in sub-meter accuracy. This becomes relevant as, nowadays, the typical (planimetric and height) accuracy of lidar data is in the decimeter range.

  2. Via NTv2 grid shift files. This is not established in OGC/CT, but only an industry standard. Certain grid shift transformations are supported by GDAL/OGR, but, as discussed before for geoid undulation models, others are not. Apart from that problem, there is another general problem, when it comes to the transformation of heights. As grid shifts directly transform lat/lon from one datum to the other, the respective ellipsoidal height on the target system is lost, which is not the case for the 7P datum transformation!

To overcome at least some of the aforementioned problems, we (TU Vienna, Department of Geodesy and Geoinformation, Research group Photogrammetry and Laserscanning) have initiated a Google-Summer-of-Code project (Rigorous support of Vertical Datums within OGRSpatialReference, see: https://github.com/ottointhesky/OGRSpatialRef3D). The project is not yet finished, but pencil-down is this week, so we expect a clean version at the end of the month.

The primary goal was to extend the OGRSpatialReference classes to support:

.) user defined geoid undulation models (ellip.->orthom. heights)
.) user defined height correction models (to compensate anomaliess of the height system)
.) a vertical offset (false elevation)

Tools from the raster domain of the GDAL library are used to read/process the geoid undulation grid models and to use them within 3D-coordinate transformations implemented in OGRCoordinateTransformation.

I’m sure the above mentioned initiative is no universal remedy, but at least is an attempt to shed light on the “3d transformation jungle”. Coming back to Karls original request. Yes, it would definitely be nice to have tools available to reliably perform 3D-transformations for lidar data. If this is within LAStools or any other commonly accessible implementation (like GDAL/OGR) is of minor importance.

Kind regards,
Gottfried


Dr. Gottfried Mandlburger

Tel.: +43 1 58801 12235
Fax.: +43 1 58801 12299
http://www.ipf.tuwien.ac.at
http://www.geo.tuwien.ac.at/opals


/// // / Vienna University of Technology
// __ / /
/ // / Department of Geodesy and Geoinformation
//
/// /_ / // / Research Groups Photogrammetry and Remote Sensing
/
///// Gusshausstrasse 27-29, A-1040 Vienna

On 13.09.2013 18:39, Heidemann, Hans wrote:

…and my understanding is that the vertical error Kirk refers to can be
significant, particularly at high latitude i.e., Alaska North Slope.

Karl

H. Karl Heidemann, GISP
/Physical Scientist, Lidar Science/

U.S. Geological Survey
Mundt Federal Building
47914 252nd Street
Sioux Falls, SD 57110
605-594-2861

kheidemann@usgs.gov mailto:[kheidemann@usgs.gov](mailto:kheidemann@usgs.gov)
/*
/
/
“Nothing matters very much, and very few things … matter at all.”*/

/- Arthur James Balfour/

On Fri, Sep 13, 2013 at 8:39 AM, Kirk Waters - NOAA Federal

<kirk.waters@noaa.gov mailto:[kirk.waters@noaa.gov](mailto:kirk.waters@noaa.gov)> wrote:

Howard,
Whether they are equivalent depends a bit on what you’re doing. They
use the same ellipsoid, but there is about a 2 meter offset between
the centers. Horizontally, we usually aren’t too worried about a 2
meter difference. Of course, the offset is in 3-D space, so it isn’t
just the horizontal that is offset. Some part of that 2 meters is in
the vertical (how much depends on where you are). We usually do care
about meter differences in the vertical for lidar data. If you only
alter the horizontal components, you could reasonably consider
yourself to still be in the same vertical datum that you were before
the transform (e.g. NAVD88), but not if you do the full 3-D
transform, unless you can tolerate that level of vertical error.

Kirk

On Thu, Sep 12, 2013 at 3:45 PM, Howard Butler <howard@hobu.co

mailto:[howard@hobu.co](mailto:howard@hobu.co)> wrote:

On Sep 12, 2013, at 8:01 AM, Karl Heidemann <karl@heidemann.us

mailto:[karl@heidemann.us](mailto:karl@heidemann.us)> wrote:

Kirk: Yes, 2D.

I suppose I should have been more specific.

Is there a way to do the conversion with LAStools (las2las) ?
The data in question is in UTM WGS84 and needs to be UTM NAD83.

I guess it has always been my understanding that NAD83 and WGS84
were equivalent in North America. Not the case?

Proj.4 + GDAL + libgeotiff, which libLAS (defunct) and PDAL use
for coordinate transformation, support both 2D and 3D datum
transformations. Only a few 3D transformations are supported,
however, but they are the common ones like NAVD88 or EGM and
transition through WGS84. Getting support for more datums is a
function of developing the transformation grids for proj.4.

Maybe LAStools will provide GDAL/proj.4/libgeotiff support in
the near future :slight_smile: (hint, hint)

Hope this helps,

Howard


Download LAStools at
http://lastools.org
http://rapidlasso.com
Be social with LAStools at
http://facebook.com/LAStools
http://twitter.com/LAStools
http://linkedin.com/groups/LAStools-4408378
Manage your settings at
http://groups.google.com/group/lastools/subscribe


Download LAStools at
http://lastools.org
http://rapidlasso.com
Be social with LAStools at
http://facebook.com/LAStools
http://twitter.com/LAStools
http://linkedin.com/groups/LAStools-4408378
Manage your settings at
http://groups.google.com/group/lastools/subscribe


Download LAStools at
http://lastools.org
http://rapidlasso.com
Be social with LAStools at
http://facebook.com/LAStools
http://twitter.com/LAStools
http://linkedin.com/groups/LAStools-4408378
Manage your settings at
http://groups.google.com/group/lastools/subscribe


Download LAStools at
http://lastools.org
http://rapidlasso.com
Be social with LAStools at
http://facebook.com/LAStools
http://twitter.com/LAStools
http://linkedin.com/groups/LAStools-4408378
Manage your settings at
http://groups.google.com/group/lastools/subscribe

Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb@fws.gov

The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.