lasplaner

[Anahita Khosravipour]

Hi everyone,

 

I try to understand and test "planar_patches_tls.bat" file (in :\\LAStools\example_batch_scripts)

My first question is why we need to convert the files’ coordinate system to UTM? is it necessary?

If its necessary how  I can convert RDNAP coordinate system (Dutch coordinate system) to UTM and vice versa.

 

Many thanks,

Anahita 

[Martin Isenburg]

Hello Anahita,

the tool that is called "lasplanes" which is the main reason to use the script "planar_patches_tls.bat" that you are referring to is trying to detect planar patches in LiDAR scans that can subsequently be used for trajectory alignment.

http://github.com/LAStools/LAStools/blob/master/example_batch_scripts/planar_patches_tls.bat

It was originally developed for the needs of scanning the city of Budapest where highly accurately geo-referenced terrestrial control scans at intersections of the city were used to "tie" down the trajectories of the mobile scanners that often do not see sufficiently many GPS satellites and can therefore exhibit some drift off the true locations. The terrestrial and mobile scanners used were both from RIEGL and hence the "lasplanes" module offers to output these planes in RIEGL's PEF format in addition to a more generic SHP format.

http://lastools.org/download/lasplanes_README.txt

The RIEGL input files that the city of Budapest was using came with ECEF coordinates. This representation does not have the z coordinate represent the elevation (e.g. the z-axis is not always pointing up) and the x/y coordinates do not represent the Easting and the Northing. Hence, the ECEF representation of the XYZ coordinates is - just like a long/lat representation - not suitable for the pre-processing steps of this scripts consisting of lasthin, lasground, and lasheight, ... that require the x and y coordinate to represent the terrain and the z coordinate the elevation.

Hence *any* common projection will do. It seems to me that the RDNAP coordinate system [1] is long/lat based so you should go to some projected coordinate system before running lasthin, lasground, and lasheight. I think simply running

las2las -i raw_rdnap.laz -longlat -target_utm auto -o raw_utm.laz

before all of your processing and then the inverse

las2las -i final_utm.laz -target_longlat -o final_rdnap.laz

at then end of your processing should make a round-trip from RDNAP to an appropriate projected coordinate system for running lasthin, lasground, lasheightm and lasplanes on.

[1] http://spatialreference.org/ref/epsg/rdnap/prettywkt/

Also lasplanes will not properly work in a long/lat based coordinate system such as RDNAP. All coordinates will have to have the same unit, usually meters. In the script ECEF coordinates are used that are also all in meters but tilted in space. For this client the planes that were found in this slightly tilted representation turned out to be "nicer" than those that were found in a projected representation with z pointing up.

Regards,

Martin @rapidlasso

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

[Anahita Khosravipour]

Hi Martin,

 

Thank you so much for your explanation.

The Netherland is located in 2 UTM zones, 32 and 31; and the test data is exactly located between these zones. 

Do you think I can still use UTM in this situation? and is there any other appropriate projections for this situation?

what about ETRS89, is it also ECEF?

 

Many thanks in advance,

Anahita

[Anahita Khosravipour]

Dear Martin,

 

for testing, I selected only the TLS data that is located on zone 32U.

 

I have used las2las to convert its projection to UTM, as the first step.

 

las2las -i %INPUT_FOLDER%\*.%INPUT_FORMAT% ^

        -longlat ^

        -target_utm 32N ^

        -odir %OUTPUT_FOLDER% -odix _utm -olaz ^

 

as you can see in the attached file the shaped is distorted (it was a road).

 

 

The coordinate system of the data is RD New ,datum: Amsersfoort.

but I don’t know how I can define it with las2las

 

https://epsg.io/28992

http://spatialreference.org/ref/epsg/amersfoort-rd-new/

 

thanks,

Anahita

 

 

RD_New

WKID: 28992 Authority: EPSG

Projection: Double_Stereographic

False_Easting: 155000.0

False_Northing: 463000.0

Central_Meridian: 5.38763888888889

Scale_Factor: 0.9999079

Latitude_Of_Origin: 52.15616055555555

Linear Unit: Meter (1.0)

[Martin Isenburg]

Hello,

well .. this changes things. The coordinate representation "Amersfoort / RD New" is already a projected coordinate representation with x and y being horizontal, z being vertical, and all units being meters. There is no need for any conversion. 

http://spatialreference.org/ref/epsg/amersfoort-rd-new/html/

http://spatialreference.org/ref/epsg/rdnap/html/

RDNAP on the other hand would have been quite a different coordinate representation as you can see if you compare the two descriptions and would have required pre-processing into a projected coordinate system. But "Amersfoort / RD New" is already a suitable one for that. So you can simply skip the conversion step and directly process the data with lasthin, lasground, ...

However ... your experiments created a really cool coordinate swirl effect. Maybe that transform could be used for a "LiDAR as Art" submission ... (-:

Regards,

Martin

[Anahita Khosravipour]

Perfect! thank you so much.

 

another question.

what was the reason behind of keeping only points between 0.5 m to 10 m above the thinned ground for Budapest dataset?

 

lasheight -i %OUTPUT_FOLDER%\*_utm.laz ^

          -ground_points %OUTPUT_FOLDER%\%OUTPUT_NAME%_ground.laz ^

          -drop_below %CUTOFF_BELOW% -drop_above %CUTOFF_ABOVE% ^

          -odir %OUTPUT_FOLDER% -odix _cut -olaz ^

 

my dataset information is :

 

min x y z:                  222760.637 584763.433 4.105

max x y z:                  223591.900 585308.223 4.605

 

what should I keep for these dataset?

 

Thanks,

Anahita

[Martin Isenburg]

Hello Anahita,

the reason for keeping only points between 0.5 m to 10 m above the ground for Budapest dataset was that the client was only interested in finding tie-planes within this range of heights above the ground. This avoids finding many many horizontal planes on the surface of the road or the sidewalks and gets rid of the vertical planes on tall buildings that are far from the terrestrial scanner and will be increasingly sparsely sampled by the mobile system.

Regards from Salzburg,

Martin