<div dir="ltr">FYI<div><br></div><div>Doug<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Gottfried Mandlburger</b> <span dir="ltr"><<a href="mailto:gm@ipf.tuwien.ac.at">gm@ipf.tuwien.ac.at</a>></span><br>
Date: Tue, Sep 17, 2013 at 3:40 AM<br>Subject: Re: [LAStools] Datum converson<br>To: <a href="mailto:lastools@googlegroups.com">lastools@googlegroups.com</a><br>Cc: "Heidemann, Hans" <<a href="mailto:kheidemann@usgs.gov">kheidemann@usgs.gov</a>><br>
<br><br>Dear all,<br>
<br>
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.<br>
<br>
Concerning datum transformations in general, there is another issue. Currently, we have two commonly accepted ways for performing the datum transition:<br>
<br>
1) Via a 7-parameter spatial similarity transformation (3 shifts, 3 rotations, 1 scale). This is established in the OGC "Coordinate Transformation Services" standard (<a href="http://www.opengeospatial.org/standards/ct" target="_blank">http://www.opengeospatial.<u></u>org/standards/ct</a>) 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.<br>
<br>
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!<br>
<br>
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: <a href="https://github.com/ottointhesky/OGRSpatialRef3D" target="_blank">https://github.com/<u></u>ottointhesky/OGRSpatialRef3D</a>). The project is not yet finished, but pencil-down is this week, so we expect a clean version at the end of the month.<br>
<br>
The primary goal was to extend the OGRSpatialReference classes to support:<br>
<br>
.) user defined geoid undulation models (ellip.->orthom. heights)<br>
.) user defined height correction models (to compensate anomaliess of the height system)<br>
.) a vertical offset (false elevation)<br>
<br>
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.<br>
<br>
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.<br>
<br>
Kind regards,<br>
Gottfried<br>
<br>
-- <br>
Dr. Gottfried Mandlburger<br>
<br>
Tel.: +43 1 58801 12235<br>
Fax.: +43 1 58801 12299<br>
<a href="http://www.ipf.tuwien.ac.at" target="_blank">http://www.ipf.tuwien.ac.at</a><br>
<a href="http://www.geo.tuwien.ac.at/opals" target="_blank">http://www.geo.tuwien.ac.at/<u></u>opals</a><br>
_____ _____ _____<br>
/____// ___// / Vienna University of Technology<br>
// __ / /__ / // / Department of Geodesy and Geoinformation<br>
//__/// /__ / // / Research Groups Photogrammetry and Remote Sensing<br>
/____//____//____/ Gusshausstrasse 27-29, A-1040 Vienna<div class="im"><br>
<br>
<br>
<br>
<br>
<br>
<br>
On 13.09.2013 18:39, Heidemann, Hans wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
...and my understanding is that the vertical error Kirk refers to can be<br>
significant, particularly at high latitude i.e., Alaska North Slope.<br>
<br>
Karl<br>
<br></div>
*H. Karl Heidemann, GISP*<br>
/Physical Scientist, Lidar Science/<div class="im"><br>
U.S. Geological Survey<br>
Mundt Federal Building<br>
47914 252nd Street<br>
Sioux Falls, SD 57110<br>
605-594-2861<br>
</div><a href="mailto:kheidemann@usgs.gov" target="_blank">kheidemann@usgs.gov</a> <mailto:<a href="mailto:kheidemann@usgs.gov" target="_blank">kheidemann@usgs.gov</a>><br>
/*<br>
*/<br>
/*"Nothing matters very much, and very few things ... matter at all."*/<br>
<br>
/*- Arthur James Balfour*/<div class="im"><br>
<br>
<br>
<br>
On Fri, Sep 13, 2013 at 8:39 AM, Kirk Waters - NOAA Federal<br></div><div class="im">
<<a href="mailto:kirk.waters@noaa.gov" target="_blank">kirk.waters@noaa.gov</a> <mailto:<a href="mailto:kirk.waters@noaa.gov" target="_blank">kirk.waters@noaa.gov</a>>> wrote:<br>
<br>
Howard,<br>
Whether they are equivalent depends a bit on what you're doing. They<br>
use the same ellipsoid, but there is about a 2 meter offset between<br>
the centers. Horizontally, we usually aren't too worried about a 2<br>
meter difference. Of course, the offset is in 3-D space, so it isn't<br>
just the horizontal that is offset. Some part of that 2 meters is in<br>
the vertical (how much depends on where you are). We usually do care<br>
about meter differences in the vertical for lidar data. If you only<br>
alter the horizontal components, you could reasonably consider<br>
yourself to still be in the same vertical datum that you were before<br>
the transform (e.g. NAVD88), but not if you do the full 3-D<br>
transform, unless you can tolerate that level of vertical error.<br>
<br>
Kirk<br>
<br>
On Thu, Sep 12, 2013 at 3:45 PM, Howard Butler <<a href="mailto:howard@hobu.co" target="_blank">howard@hobu.co</a><br></div><div class="im">
<mailto:<a href="mailto:howard@hobu.co" target="_blank">howard@hobu.co</a>>> wrote:<br>
<br>
<br>
On Sep 12, 2013, at 8:01 AM, Karl Heidemann <<a href="mailto:karl@heidemann.us" target="_blank">karl@heidemann.us</a><br></div><div><div class="h5">
<mailto:<a href="mailto:karl@heidemann.us" target="_blank">karl@heidemann.us</a>>> wrote:<br>
<br>
> Kirk: Yes, 2D.<br>
><br>
> I suppose I should have been more specific.<br>
><br>
> Is there a way to do the conversion with LAStools (las2las) ?<br>
> The data in question is in UTM WGS84 and needs to be UTM NAD83.<br>
<br>
I guess it has always been my understanding that NAD83 and WGS84<br>
were equivalent in North America. Not the case?<br>
<br>
Proj.4 + GDAL + libgeotiff, which libLAS (defunct) and PDAL use<br>
for coordinate transformation, support both 2D and 3D datum<br>
transformations. Only a few 3D transformations are supported,<br>
however, but they are the common ones like NAVD88 or EGM and<br>
transition through WGS84. Getting support for more datums is a<br>
function of developing the transformation grids for proj.4.<br>
<br>
Maybe LAStools will provide GDAL/proj.4/libgeotiff support in<br>
the near future :) (hint, hint)<br>
<br>
Hope this helps,<br>
<br>
Howard<br>
<br>
--<br>
Download LAStools at<br>
<a href="http://lastools.org" target="_blank">http://lastools.org</a><br>
<a href="http://rapidlasso.com" target="_blank">http://rapidlasso.com</a><br>
Be social with LAStools at<br>
<a href="http://facebook.com/LAStools" target="_blank">http://facebook.com/LAStools</a><br>
<a href="http://twitter.com/LAStools" target="_blank">http://twitter.com/LAStools</a><br>
<a href="http://linkedin.com/groups/LAStools-4408378" target="_blank">http://linkedin.com/groups/<u></u>LAStools-4408378</a><br>
Manage your settings at<br>
<a href="http://groups.google.com/group/lastools/subscribe" target="_blank">http://groups.google.com/<u></u>group/lastools/subscribe</a><br>
<br>
<br>
--<br>
Download LAStools at<br>
<a href="http://lastools.org" target="_blank">http://lastools.org</a><br>
<a href="http://rapidlasso.com" target="_blank">http://rapidlasso.com</a><br>
Be social with LAStools at<br>
<a href="http://facebook.com/LAStools" target="_blank">http://facebook.com/LAStools</a><br>
<a href="http://twitter.com/LAStools" target="_blank">http://twitter.com/LAStools</a><br>
<a href="http://linkedin.com/groups/LAStools-4408378" target="_blank">http://linkedin.com/groups/<u></u>LAStools-4408378</a><br>
Manage your settings at<br>
<a href="http://groups.google.com/group/lastools/subscribe" target="_blank">http://groups.google.com/<u></u>group/lastools/subscribe</a><br>
<br>
<br>
--<br>
Download LAStools at<br>
<a href="http://lastools.org" target="_blank">http://lastools.org</a><br>
<a href="http://rapidlasso.com" target="_blank">http://rapidlasso.com</a><br>
Be social with LAStools at<br>
<a href="http://facebook.com/LAStools" target="_blank">http://facebook.com/LAStools</a><br>
<a href="http://twitter.com/LAStools" target="_blank">http://twitter.com/LAStools</a><br>
<a href="http://linkedin.com/groups/LAStools-4408378" target="_blank">http://linkedin.com/groups/<u></u>LAStools-4408378</a><br>
Manage your settings at<br>
<a href="http://groups.google.com/group/lastools/subscribe" target="_blank">http://groups.google.com/<u></u>group/lastools/subscribe</a><br>
</div></div></blockquote><div class="HOEnZb"><div class="h5">
<br>
-- <br>
Download LAStools at<br>
<a href="http://lastools.org" target="_blank">http://lastools.org</a><br>
<a href="http://rapidlasso.com" target="_blank">http://rapidlasso.com</a><br>
Be social with LAStools at<br>
<a href="http://facebook.com/LAStools" target="_blank">http://facebook.com/LAStools</a><br>
<a href="http://twitter.com/LAStools" target="_blank">http://twitter.com/LAStools</a><br>
<a href="http://linkedin.com/groups/LAStools-4408378" target="_blank">http://linkedin.com/groups/<u></u>LAStools-4408378</a><br>
Manage your settings at<br>
<a href="http://groups.google.com/group/lastools/subscribe" target="_blank">http://groups.google.com/<u></u>group/lastools/subscribe</a><br>
</div></div></div><br><br clear="all"><div><br></div>-- <br><div>Doug Newcomb</div><div>USFWS</div><div>Raleigh, NC</div><div>919-856-4520 ext. 14 <a href="mailto:doug_newcomb@fws.gov" target="_blank">doug_newcomb@fws.gov</a></div>
<div>---------------------------------------------------------------------------------------------------------</div><div>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.</div>
</div></div>