Datum converson

[Karl Heidemann]

Hi Martin,

Although the argument may be made that it doesn't matter ...

Can LAS data be converted/reprojected from NAD83 to WGS84, all other factors remaining unchaged?

If so, how?

Thanks

Karl

[Kirk Waters - NOAA Federal]

Karl,

Are you looking for a 3-D transform or a 2-D horizontal transform? I suspect you're talking 2-D because for 3-D you can't make an argument that it doesn't matter. VDatum should do the 3-D, though it doesn't support LAS 1.4 yet.

Kirk

--
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

[Karl Heidemann]

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.

[Howard Butler]

On Sep 12, 2013, at 8:01 AM, Karl Heidemann <ka...@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

[Heidemann, Hans]

Certainly for CONUS, WGS84 and NAD83 are equivalent (2D ) for all practical purposes. 

In high latitudes (Alaska North Coast) the difference becomes problematic.

I wanted to be sure that the transformation could not be done using LAStools, and that I wasn't missing something obvious (often the case these days). It isn't that I can't accomplish the task; I'm just really tired of having to keep a dozen tools to perform all the day-to-day tasks. 

Howard, as you note, MAYBE someday soon??  (HINT HINT!!)

Thanks All!

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

kheid...@usgs.gov

"Nothing matters very much, and very few things ... matter at all."

- Arthur James Balfour

[Kirk Waters - NOAA Federal]

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

[Hudak, Andrew -FS]

Actually, I’ve seen WGS84 and NAD83 differ by as much as 0.75 m in CONUS.

 

Andy

 

From: last...@googlegroups.com [mailto:last...@googlegroups.com] On Behalf Of Heidemann, Hans
Sent: Friday, September 13, 2013 7:19 AM
To: last...@googlegroups.com
Subject: Re: [LAStools] Datum converson

 

Certainly for CONUS, WGS84 and NAD83 are equivalent (2D ) for all practical purposes. 

In high latitudes (Alaska North Coast) the difference becomes problematic.

 

I wanted to be sure that the transformation could not be done using LAStools, and that I wasn't missing something obvious (often the case these days). It isn't that I can't accomplish the task; I'm just really tired of having to keep a dozen tools to perform all the day-to-day tasks. 

 

Howard, as you note, MAYBE someday soon??  (HINT HINT!!)

 

Thanks All!

Karl

 

H. Karl Heidemann, GISP

This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

[Heidemann, Hans]

...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

kheid...@usgs.gov

"Nothing matters very much, and very few things ... matter at all."

- Arthur James Balfour

[Gottfried Mandlburger]

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

> kheid...@usgs.gov <mailto:kheid...@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....@noaa.gov <mailto:kirk....@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 <how...@hobu.co
> <mailto:how...@hobu.co>> wrote:
>
>
> On Sep 12, 2013, at 8:01 AM, Karl Heidemann <ka...@heidemann.us

[Robin Poot]

Hi,

 

Prior to 1995 or so WGS84 was aligned with NAD83.  After that, WGS84 was realigned with ITRF.  There is about 1.5 (or 2?)  metres difference between ITRF and NAD83 at the centre of the earth.  So imagine in the offset was in Z (ECEF) then it is 1.5 metres off in Z (local topocentric) at the pole and 1.5 metre off in Y (local topocentric) at the equator.  So yes, it matters where you are.. 

 

my 2 cents.

 

Robin

 

I highly recommend the short read:

 

http://www.naref.org/transf/nad83_hydroscan2006.pdf

 

Robin

 

[Martin Isenburg]

Hello Hans,

you cannot curretnly do it with las2las from LAStools. But you can do
it with las2las from libLAS.

http://www.liblas.org/utilities/las2las.html

scroll down to the options '--s_srs arg' and '--t_srs arg' ... not
sure when las2las from LAStools will have that (a bit overloaded right
now).

Martin

On Wed, Sep 18, 2013 at 5:34 PM, Heidemann, Hans <kheid...@usgs.gov> wrote:
> all good and appreciated info.
>
> The real and original questions remain for Martin:
> Can the transformation (now understood to have to be 3D) be done using
> LAStools?
> If so, How?
> If not, When?
>
> 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
> kheid...@usgs.gov
>
> "Nothing matters very much, and very few things ... matter at all."
>
> - Arthur James Balfour
>
>
>

[Heidemann, Hans]

all good and appreciated info.

The real and original questions remain for Martin:
Can the transformation (now understood to have to be 3D) be done using LAStools?
If so, How?
If not, When? 

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

kheid...@usgs.gov

"Nothing matters very much, and very few things ... matter at all."

- Arthur James Balfour

On Wed, Sep 18, 2013 at 10:15 AM, Robin Poot <r...@airsensing.com> wrote:

[Evon Silvia]

Hans,

Your original question lacks the clarifications necessary to give a definite answer. What precision are you looking for? As mentioned already by several folks, if your horizontal/vertical precision is on the order of 3m, then WGS84 and NAD83 can be considered almost equivalent and you can ignore transformations altogether.

If you want 0.5m precision (or so... it varies around the conterminous USA), you might be able to accomplish a transformation between the datums using one of the 7-parameter transformations.

If you want to get better precision than that, you have to start talking about which realization of NAD83, which realization of WGS84 (they generally align with the ITRF frames), and your reference (epoch) date. In addition, you must consider where you are so that you can model the crustal motion in your area of interest. 

This translates to a need for a 14-parameter transformation, as NGS describes in this dated but still relevant paper. It's my understanding that LAStools does not support 14-parameter transformations, so you're out of luck there.

In my neck of the woods, the Pacific Northwest, these differences from epoch dates can be quite substantial. Since we work on the centimeter to sub-centimeter scale, I have found HTDP to give the only satisfactory and consistent result for NAD83 transformations, and Blue Marble's Geographic Calculator is my preferred interface (no endorsement by WSI is expressed or implied). I'm not aware of any other software package that fully implements this time-based concept.

That's my $0.02.

Cheers,

Evon

--

Evon Silvia  Geomatics Specialist

P: 541-752-1204 | E: esi...@wsidata.com | W: wsidata.com 

WSI Corvallis, OR WSI Portland, OR WSI Oakland, CA

517 SW 2nd St., Suite 400, Corvallis, OR 97333

[Heidemann, Hans]

and this is the 3D transformation?

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

kheid...@usgs.gov

"Nothing matters very much, and very few things ... matter at all."

- Arthur James Balfour

[Jennifer]

This answer was relevant to me, as I'd like to alter the vertical datum from WGS84 to EGM96.

The only problem is, I'm not sure how to do this...

Any help would be much appreciated!!

Alter vertical datum information

$ las2las in.las --a_vertcs 5703 "North American Vertical Datum of 1988 (NAVD88)" 5103 9001

sets the vertical datum information for the file to be NAVD88 with vertical units of meters.

Note

 

This may not be relevant depending upon the circumstances of the coordinate system the file is already in. This option only changes thedescription of the points. It does not reproject them in any way. Use a combination of –a_srs and –t_srs to do perform reprojection of the file

[Howard Butler]

On Jan 30, 2014, at 6:29 PM, Jennifer <jenc...@gmail.com> wrote:

> This answer was relevant to me, as I'd like to alter the vertical datum from WGS84 to EGM96.

I think only libLAS or PDAL can currently do this through their use of vertical datum [1] support in GDAL. Maybe now that LAStools is pure LGPL, we can convince Martin to hang the source code off of https://github.com/LAStools/LASlib so he can accept patches that link the GDAL features in and we can avoid the libLAS silliness (hint, hint).

Howard

[1] http://trac.osgeo.org/proj/wiki/VerticalDatums

[Evon Silvia]

We frequently use Blue Marble's Geographic Calculator software or the GeoCalc SDK for major datum transformations. Their library is extensive and methods seem to reflect the current state of the art. It's not free, though.

Evon

[Tobias K Kohoutek]

Hi everybody, I would like to push this up here again because none of the other post about "datum transformation" or "transformation to local coordinate system" helped me yet. 

We've a customer who has his local coordinate system which is similar to UTM coordinates and we know a, f, ko, false easting, false northing and central meridian (see attached image)

My question is, if there's any chance to place those parameters inside las2las in target projection? There is the transverse mercator option which would let me enter easting, northing and scale factor. Maybe that's already everything I need, but what about the central meridian?

I would appreciate any help.

Cheers,

Tobias

[Evon Silvia]

Since you mentioned it's similar to UTM18, you should be able to set a user-defined transverse mercator projection in the target projection area of las2las, toward the lower-right corner. I filled it out with what I could tell from your screenshot, so yours will look somewhat similar. I can't remember whether Martin requires a positive or negative center longitude/meridian. I'm assuming negative.

Hope that helps.

Evon

--

Evon Silvia PLS Geomatics Specialist 517 SW 2nd Street, Suite 400, Corvallis, OR 97333 P: (541) 452-8502 E: esi...@quantumspatial.com