[GRASS-dev] Fwd: [LAStools] Datum converson
Newcomb, Doug
doug_newcomb at fws.gov
Tue Sep 17 04:47:10 PDT 2013
FYI
Doug
---------- Forwarded message ----------
From: Gottfried Mandlburger <gm at ipf.tuwien.ac.at>
Date: Tue, Sep 17, 2013 at 3:40 AM
Subject: Re: [LAStools] Datum converson
To: lastools at googlegroups.com
Cc: "Heidemann, Hans" <kheidemann at 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 <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<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 <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 at usgs.gov <mailto:kheidemann at 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 at noaa.gov <mailto:kirk.waters at 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 at hobu.co
> <mailto:howard at hobu.co>> wrote:
>
>
> On Sep 12, 2013, at 8:01 AM, Karl Heidemann <karl at heidemann.us
> <mailto:karl at 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 :) (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<http://linkedin.com/groups/LAStools-4408378>
> Manage your settings at
> http://groups.google.com/**group/lastools/subscribe<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<http://linkedin.com/groups/LAStools-4408378>
> Manage your settings at
> http://groups.google.com/**group/lastools/subscribe<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<http://linkedin.com/groups/LAStools-4408378>
> Manage your settings at
> http://groups.google.com/**group/lastools/subscribe<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<http://linkedin.com/groups/LAStools-4408378>
Manage your settings at
http://groups.google.com/**group/lastools/subscribe<http://groups.google.com/group/lastools/subscribe>
--
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20130917/f8551782/attachment-0001.html>
More information about the grass-dev
mailing list