LAS2LAS convert to las v1.4, set coordinate system and units

bsandco

unread,

Apr 7, 2016, 10:00:27 AM4/7/16

to LAStools - efficient tools for LiDAR processing

I am running the las2laspro (filter) script to convert to las v1.4 within an ArcMap (v10.3.1) model, my las data is in State Plane Utah North NAD83 survey feet, vertical is navd88. The input las data does not have the projection information defined.

Additional command –line parameters = -set_version_minor 4 -set_point_type 6 -sp83 UT_N -survey_feet -elevation_survey_feet -vertical_navd88 -set_ogc_wkt

When I run the model everything seem to run fine, when I run lasinfo it is showing that the las data is Meters.

What am I doing wrong?

Following is one of the lasinfo text file outputs:

reporting all LAS header entries:

file signature: 'LASF'

file source ID: 0

global_encoding: 17

project ID GUID data 1-4: 00000000-0000-0000-0000-000000000000

version major.minor: 1.4

system identifier: 'LAStools (c) by rapidlasso GmbH'

generating software: 'las2las (version 160329)'

file creation day/year: 344/2014

header size: 375

offset to point data: 1226

number var. length records: 2

point data format: 6

point data record length: 30

number of point records: 0

number of points by return: 0 0 0 0 0

scale factor x y z: 0.01 0.01 0.01

offset x y z: 0 0 0

min x y z: 100183.20 177000.00 4373.39

max x y z: 100999.99 177999.99 4490.90

start of waveform data packet record: 0

start of first extended variable length record: 0

number of extended_variable length records: 0

extended number of point records: 440531

extended number of points by return: 350371 60210 24100 5850 0 0 0 0 0 0 0 0 0 0 0

variable length header record 1 of 2:

reserved 43707

user ID 'LASF_Projection'

record ID 34735

length after header 48

description 'by LAStools of rapidlasso GmbH'

GeoKeyDirectoryTag version 1.1.0 number of keys 5

key 1024 tiff_tag_location 0 count 1 value_offset 1 - GTModelTypeGeoKey: ModelTypeProjected

key 3072 tiff_tag_location 0 count 1 value_offset 32142 - ProjectedCSTypeGeoKey: NAD83 / Utah North

key 3076 tiff_tag_location 0 count 1 value_offset 9001 - ProjLinearUnitsGeoKey: Linear_Meter

key 4099 tiff_tag_location 0 count 1 value_offset 9003 - VerticalUnitsGeoKey: Linear_Foot_US_Survey

key 4096 tiff_tag_location 0 count 1 value_offset 5103 - VerticalCSTypeGeoKey: VertCS_North_American_Vertical_Datum_1988

variable length header record 2 of 2:

reserved 43707

user ID 'LASF_Projection'

record ID 2112

length after header 693

description 'by LAStools of rapidlasso GmbH'

WKT OGC COORDINATE SYSTEM:

PROJCS["NAD83 / Utah North",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","6269"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.01745329251994328,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4269"]],PROJECTION["Lambert_Conformal_Conic_2SP"],PARAMETER["standard_parallel_1",40.716667],PARAMETER["standard_parallel_2",41.783333],PARAMETER["latitude_of_origin",40.333333],PARAMETER["central_meridian",-111.5],PARAMETER["false_easting",500000],PARAMETER["false_northing",1000000],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["EPSG","32142"]]

the header is followed by 2 user-defined bytes

LAStiling (idx 73, lvl 5, sub 0, bbox 91000 175000 123000 207000)

reporting minimum and maximum for all LAS point record entries ...

X 10018320 10099999

Y 17700000 17799999

Z 437339 449090

intensity 1 4082

return_number 1 4

number_of_returns 1 4

edge_of_flight_line 0 0

scan_direction_flag 0 1

classification 1 2

scan_angle_rank -5 4

user_data 0 0

point_source_ID 1 1

gps_time 100537118.185486 100537124.792723

extended_return_number 1 4

extended_number_of_returns 1 4

extended_classification 1 2

extended_scan_angle -833 667

extended_scanner_channel 0 0

number of first returns: 350371

number of intermediate returns: 29975

number of last returns: 350231

number of single returns: 290046

covered area in square meters/kilometers: 765056/0.77

point density: all returns 0.58 last only 0.46 (per square meter)

spacing: all returns 1.32 last only 1.48 (in meters)

overview over extended number of returns of given pulse: 290046 72260 54803 23422 0 0 0 0 0 0 0 0 0 0 0

histogram of classification of points:

145916 unclassified (1)

294615 ground (2)

Kim Mantey

unread,

Apr 7, 2016, 7:20:06 PM4/7/16

to LAStools - efficient tools for LiDAR processing

Hello!

Instead of defining your spatial reference using a name, try using the EPSG code for this CRS (3650). I tested a 1.2 to 1.4 file using this command:

-set_version 1.4 -set_point_type 6 -epsg 3650 -elevation_surveyfeet -vertical_navd88 -set_ogc_wkt.

When this is completed, it should write out a 1.4 file with the correct spatial referencing in the proper units. However, the las file that is written out will contain spref in both geotiff and WKT in two separate VLRs. The geotiff spatial reference VLR needs to be removed in order to make the file compliant w/the ASPRS LAS 1.4 Specification PDRF 6-10. To correct this do the following in las2las

-remove_vlrs_from_to 0 0

This will take out the first variable length record containing the geotiff spref, leaving your spref section compliant w/the ASPRS LAS 1.4 Specification.

I hope this works for you!

To find EPSG codes: EPSG Registry: http://www.epsg-registry.org/

Andrew Bell

unread,

Apr 7, 2016, 9:35:17 PM4/7/16

to last...@googlegroups.com

On Thu, Apr 7, 2016 at 4:28 PM, Kim Mantey <mante...@gmail.com> wrote:

Hello!

Instead of defining your spatial reference using a name, try using the EPSG code for this CRS (3650). I tested a 1.2 to 1.4 file using this command:

-set_version 1.4 -set_point_type 6 -epsg 3650 -elevation_surveyfeet -vertical_navd88 -set_ogc_wkt.

When this is completed, it should write out a 1.4 file with the correct spatial referencing in the proper units. However, the las file that is written out will contain spref in both geotiff and WKT in two separate VLRs. The geotiff spatial reference VLR needs to be removed in order to make the file compliant w/the ASPRS LAS 1.4 Specification PDRF 6-10. To correct this do the following in las2las

-remove_vlrs_from_to 0 0

This will take out the first variable length record containing the geotiff spref, leaving your spref section compliant w/the ASPRS LAS 1.4 Specification.

I hope this works for you!

The way I read the spec, the GeoTIFF VLR can exist along with the WKT, though the GeoTIFF VLR should be ignored by a reader when the WKT bit is set in the global_encoding byte. Certainly, it hurts nothing to remove the GeoTIFF VLR.

From the document, section 4:

====

It is considered a file error to have more than one GeoTIFF (E)VLR or more than one WKT (E)VLR in the file. A writer can append a new CRS EVLR to a file by “superseding” the existing CRS (E)VLR. Superseding is performed by changing the LAS_Spec ID of the record to “Superseded”, a new LASF_Spec defined in this release.

====

To me this doesn't say that you can't have both a GeoTIFF and WKT VLR, you just can't have more than one of either.

See page 4 of the document for more.

--

Andrew Bell
andrew....@gmail.com

Martin Isenburg

unread,

Apr 9, 2016, 1:51:01 AM4/9/16

to LAStools - efficient command line tools for LIDAR processing

Hello,

given that - for the foreseeable future - there will be lots of software out there that has good or better support for the GeoTIFF tag way of specifying the CRS than for the OGC WKT way, I would personally recommend to leave both ways in the file and just make sure they are really specifying the exact same CRS. LAStools currently only writes but does not (yet) read (or rather parse) the OGC WKT strings.

While we are on the topic. How do I need to modify, for example, this OCG WKT string so that it can subsequently be stored as the contents of a *.prj file to accompany a *.shp file that ArgggghhhGIS can parse properly?

PROJCS["NAD83 / Utah North",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","6269"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.01745329251994328,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4269"]],PROJECTION["Lambert_Conformal_Conic_2SP"],PARAMETER["standard_parallel_1",40.716667],PARAMETER["standard_parallel_2",41.783333],PARAMETER["latitude_of_origin",40.333333],PARAMETER["central_meridian",-111.5],PARAMETER["false_easting",500000],PARAMETER["false_northing",1000000],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["EPSG","32142"]]

Regards,

Martin @rapidlasso

Howard Butler

unread,

Apr 10, 2016, 11:18:09 AM4/10/16

to last...@googlegroups.com

Martin,

https://gist.github.com/hobu/f01aa368e47b4fc4c089c4526e822816 should demonstrate how to use GDAL's Python API to do this task. GDAL's OSR library provides the MorphToESRI and MorphFromESRI methods to allow you to go back and forth between OGC's names and ESRI's names.

As for how to do it yourself, when can we convince you to just use GDAL like the rest of us? ;)

Howard

PS. There is a bunch of awful in the GDAL codebase to map names between the two systems. A lot of it is based on experience, trial and error, and teeth gnashing. The CS-Map codebase also has a way to map between these two systems, but I'm unsure how complete it is. GDAL's has been battle-tested for a number of years though.

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

Reply all

Reply to author

Forward