ArghGIS fails to load LAS 1.4 because of incorrect OGC WKT string?

Martin Isenburg

unread,

Jul 12, 2017, 7:01:09 AM7/12/17

to LAStools - efficient command line tools for LIDAR processing, The LAS room - a friendly place to discuss specifications of the LAS format

Hello,

a customer of mine uses LAStools to convert LAS 1.2 files with point type 1 to LAS 1.4 files with point type 6 while adding a compound CRS in OGC WKT format as an EVLR. The resulting LAS (not LAZ!!!) file apparently no longer loads into the Argh but fails with this error message

Here is the command line that was used. Can someone confirm that this is indeed the case and maybe explain why the file cannot be loaded? Even if the CRS could not be understood, it should still be possible to parse the LAS file, no? The lasinfo reports are below.

Btw ... this looks like Geiger-mode LiDAR to me. Here are two additional comments for discussion:

(1) the coordinates are stored with 0.1 millimeter precision (scale factors of 0.0001). for an airborne data set a resolution of centimeter (scale factors of 0.01) would be more appropriate and meaningful.

(2) we strongly advise against asking for storing CRS information in the EVLRs (in a tender document). while the use of EVLRs is sometimes convenient the VLRs are more efficient for use in large deliveries because a "peek" into only the beginning 2000 bytes (or so) of the file gives a user access to all metadata. For example, when data is provided on the Web I'll have to download the entire file to know its CRS when it is stored as an EVLR instead of being able to use curl to just "peak" into the beginning of the file only. streaming transmission or piping of processing modules is no longer possible when either (a) points are filtered out or (b) compression is used.

Regards,

Martin

las2las -i Original_1_2.laz ^

-remove_padding ^

-set_point_type 6 ^

-epsg 6424 ^

-vertical_navd88 -elevation_survey_feet ^

-set_ogc_wkt_in_evlr ^

-remove_all_vlrs ^

-o Converted_1_4.las

or compressed with the new "native LAS 1.4 extension" of LASzip

las2las -i Original_1_2.laz ^

-remove_padding ^

-set_point_type 6 ^

-epsg 6424 ^

-vertical_navd88 -elevation_survey_feet ^

-set_ogc_wkt_in_evlr ^

-remove_all_vlrs ^

-native ^

-o Converted_1_4.laz

Can someone confirm that the Argh has issues with the

-----------------

- converted -

-----------------

E:\LAStools\bin>lasinfo -i Converted_1_4.laz

lasinfo (170628) report for Converted_1_4.laz

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

generating software: ''

file creation day/year: 193/2017

header size: 375

offset to point data: 375

number var. length records: 0

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

offset x y z: 6300000 2000000 0

min x y z: 6175927.6583 1922306.6721 12.8102

max x y z: 6176062.8571 1922431.1658 46.0476

start of waveform data packet record: 0

start of first extended variable length record: 165773

number of extended_variable length records: 1

extended number of point records: 18991

extended number of points by return: 18991 0 0 0 0 0 0 0 0 0 0 0 0 0 0

extended variable length header record 1 of 1:

reserved 0

user ID 'LASF_Projection'

record ID 2112

length after header 1037

description 'by LAStools of rapidlasso GmbH'

OGC COORDINATE SYSTEM WKT:

COMPD_CS["NAD83(2011) / California zone 5 (ftUS) + NAVD88 (ftUS)",PROJCS["NAD83(2011) / California zone 5 (ftUS)",GEOGCS["NAD83(2011)",DATUM["NAD_1983_2011"

,SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","1116"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.01

745329251994328,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","6318"]],PROJECTION["Lambert_Conformal_Conic_2SP"],PARAMETER["standard_parallel_1",35.4666666666667],

PARAMETER["standard_parallel_2",34.0333333333333],PARAMETER["latitude_of_origin",33.5],PARAMETER["central_meridian",-118],PARAMETER["false_easting",6561666.667]

,PARAMETER["false_northing",1640416.667],UNIT["US survey foot",0.3048006096012192,AUTHORITY["EPSG","9003"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORIT

Y["EPSG","6424"]]VERT_CS["NAVD88",VERT_DATUM["North American Vertical Datum 1988",2005,AUTHORITY["EPSG","5103"]],UNIT["US survey foot",0.3048006096012192,AUTHOR

ITY["EPSG","9003"]],AXIS["Gravity-related height",UP],AUTHORITY["EPSG","6360"]]]

LASzip compression (version 3.0r1 c3 50000): POINT14 3

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

X -1240723417 -1239371429

Y -776933279 -775688342

Z 128102 460476

intensity 0 30642

return_number 1 1

number_of_returns 1 1

edge_of_flight_line 0 0

scan_direction_flag 0 0

classification 1 2

scan_angle_rank 15 15

user_data 0 0

point_source_ID 0 0

gps_time 147579408.000000 147581072.000000

extended_return_number 1 1

extended_number_of_returns 1 1

extended_classification 1 2

extended_scan_angle 2500 2500

extended_scanner_channel 0 0

number of first returns: 18991

number of intermediate returns: 0

number of last returns: 18991

number of single returns: 18991

overview over extended number of returns of given pulse: 18991 0 0 0 0 0 0 0 0 0 0 0 0 0 0

histogram of classification of points:

8138 unclassified (1)

10853 ground (2)

-----------------

--- original ---

-----------------

E:\LAStools\bin>lasinfo -i Sample_1_2.laz

lasinfo (170628) report for Sample_1_2.laz

reporting all LAS header entries:

file signature: 'LASF'

file source ID: 0

global_encoding: 1

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

version major.minor: 1.2

system identifier: ''

generating software: 'TerraScan'

file creation day/year: 193/2017

header size: 227

offset to point data: 229

number var. length records: 0

point data format: 1

point data record length: 28

number of point records: 18991

number of points by return: 18991 0 0 0 0

scale factor x y z: 0.0001 0.0001 0.0001

offset x y z: 6300000 2000000 0

min x y z: 6175927.6583 1922306.6721 12.8102

max x y z: 6176062.8571 1922431.1658 46.0476

the header is followed by 2 user-defined bytes

LASzip compression (version 3.0r1 c2 50000): POINT10 2 GPSTIME11 2

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

X -1240723417 -1239371429

Y -776933279 -775688342

Z 128102 460476

intensity 0 30642

return_number 1 1

number_of_returns 1 1

edge_of_flight_line 0 0

scan_direction_flag 0 0

classification 1 2

scan_angle_rank 15 15

user_data 0 0

point_source_ID 0 0

gps_time 147579408.000000 147581072.000000

number of first returns: 18991

number of intermediate returns: 0

number of last returns: 18991

number of single returns: 18991

overview over number of returns of given pulse: 18991 0 0 0 0 0 0

histogram of classification of points:

8138 unclassified (1)

10853 ground (2)

Original_1_2.laz

Converted_1_4.laz

Kirk Waters - NOAA Federal

unread,

Jul 12, 2017, 7:39:20 AM7/12/17

to LAStools - efficient command line tools for LIDAR processing, The LAS room - a friendly place to discuss specifications of the LAS format

Martin,

I can confirm that Arc 10.4 gets that error. I can also tell you that it doesn't get the error if I put the following WKT on instead (note that I left vertical as meters, so not quite right for the data):

WKT OGC COORDINATE SYSTEM:

COMPD_CS["NAD83(2011) / California zone 5 (ftUS); NAVD88 height",PROJCS["NAD83(2011) / California zone 5 (ftUS)",GEOGCS["NAD83(2011)",DATUM["NAD83_National_Spatial_Reference_System_2011",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","1116"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","6318"]],PROJECTION["Lambert_Conformal_Conic_2SP"],PARAMETER["standard_parallel_1",35.46666666666667],PARAMETER["standard_parallel_2",34.03333333333333],PARAMETER["latitude_of_origin",33.5],PARAMETER["central_meridian",-118],PARAMETER["false_easting",6561666.667],PARAMETER["false_northing",1640416.667],UNIT["US survey foot",0.3048006096012192,AUTHORITY["EPSG","9003"]],AXIS["X",EAST],AXIS["Y",NORTH],AUTHORITY["EPSG","6424"]],VERT_CS["NAVD88 height",VERT_DATUM["North American Vertical Datum 1988",2005,EXTENSION["PROJ4_GRIDS","g2012a_conus.gtx,g2012a_alaska.gtx,g2012a_guam.gtx,g2012a_hawaii.gtx,g2012a_puertorico.gtx,g2012a_samoa.gtx"],AUTHORITY["EPSG","5103"]],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Up",UP],AUTHORITY["EPSG","5703"]]]

Kirk Waters, PhD | NOAA Office for Coastal Management

Applied Sciences Program | 2234 South Hobson Ave
843-740-1227 | Charleston, SC 29405

coast.noaa.gov/digitalcoast

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

Martin Isenburg

unread,

Jul 13, 2017, 9:40:07 AM7/13/17

to LAStools - efficient command line tools for LIDAR processing

Hello,

the problem was solved. There was a missing "," in the compound versions of the OGC WKT strings produced by las2las just before the VERT_CS tag (see text marked in red below). This will be fixed in the next release (next week) ... let me know if you need a fixed version earlier.

However, I do not understand why the Argh refuses to read the LiDAR from a perfectly fine LAS file altogether only because the geo-referencing string cannot be parsed. A more user friendly behaviour would be to emit a WARNING instead of an ERROR and let the user set the CRS manually ... just saying. (-:

E:\LAStools\bin>lasinfo -i Converted_1_4.laz

lasinfo (170628) report for Converted_1_4.laz

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 170628)'

E:\LAStools\bin>lasinfo -i Converted_1_4_new.laz

lasinfo (170628) report for Converted_1_4_new.laz

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 170713)'

file creation day/year: 193/2017

header size: 375

offset to point data: 375

number var. length records: 0

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

offset x y z: 6300000 2000000 0

min x y z: 6175927.6583 1922306.6721 12.8102

max x y z: 6176062.8571 1922431.1658 46.0476

start of waveform data packet record: 0

start of first extended variable length record: 165773

number of extended_variable length records: 1

extended number of point records: 18991

extended number of points by return: 18991 0 0 0 0 0 0 0 0 0 0 0 0 0 0

extended variable length header record 1 of 1:

reserved 0

user ID 'LASF_Projection'

record ID 2112

length after header 1038

description 'by LAStools of rapidlasso GmbH'

OGC COORDINATE SYSTEM WKT:

COMPD_CS["NAD83(2011) / California zone 5 (ftUS) + NAVD88 (ftUS)",PROJCS["NAD83(2011) / California zone 5 (ftUS)",GEOGCS["NAD83(2011)",DATUM["NAD_1983_2011"

,SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","1116"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.01

745329251994328,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","6318"]],PROJECTION["Lambert_Conformal_Conic_2SP"],PARAMETER["standard_parallel_1",35.4666666666667],

PARAMETER["standard_parallel_2",34.0333333333333],PARAMETER["latitude_of_origin",33.5],PARAMETER["central_meridian",-118],PARAMETER["false_easting",6561666.667]

,PARAMETER["false_northing",1640416.667],UNIT["US survey foot",0.3048006096012192,AUTHORITY["EPSG","9003"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORIT

Y["EPSG","6424"]],VERT_CS["NAVD88",VERT_DATUM["North American Vertical Datum 1988",2005,AUTHORITY["EPSG","5103"]],UNIT["US survey foot",0.3048006096012192,AUTHO

RITY["EPSG","9003"]],AXIS["Gravity-related height",UP],AUTHORITY["EPSG","6360"]]]

Martin Isenburg

unread,

Jul 14, 2017, 5:09:46 AM7/14/17

to LAStools - efficient command line tools for LIDAR processing

Hello,

Here some philosophical musings about software and data in general given the situation that the Argh failed to read perfectly fine point cloud data from a LAS file just because the OGC WKT string containing the CRS was missing a comma (never mind that many LAS files have no CRS info at all and the Argh happily reads those).

Of course I am happy the Argh ERROR informed that i needed to correct my software but for the user of the Argh a WARNING only would have been nicer and not stalled his workflow.

At AGIT 2017 Arnulf Christl gave a talk titled "Software comes and goes but data stays (forever)" and it was an appeal to software engineers to show more acceptance for data. This an excerpt from one of his blog entries with a similar message: "Never ever even think that you have to make the data work with your software. The software has to deal with your data. [...] The data is where the money sits. This is a simple reality. Software should never be more than thin veneer."

http://arnulf.us/sevendipity/archives/61-About-Software-and-Data.html

Regards,

Martin

Stoker, Jason

unread,

Jul 14, 2017, 10:43:03 AM7/14/17

to <lastools@googlegroups.com>

Martin, thanks for the blog philosophical musings. As a data monger who buys data from all types of people and uses many different software programs to do our work, I have personally felt this frustration for years.

LAS 1.4 was approved by ASPRS in November of 2011. We have yet to reach community adoption of this version. I'm not completely sure why. Perhaps people do not care about all the improvements that were added? Perhaps it is because almost all software vendors either had issues with or simply did not want to bother with adopting it, so didn't? Perhaps a bit of both.

I'm hoping between ASPRS and OGC we can avoid this type of problem when it comes to format adoption in the future.

Jason M. Stoker, Ph.D
US Geological Survey
National Geospatial Program
Office: 970-226-9227
Cell: 605-496-3513
My USGS Profile

--

Howard Butler

unread,

Jul 14, 2017, 2:19:24 PM7/14/17

to last...@googlegroups.com

On Jul 14, 2017, at 9:16 AM, Stoker, Jason <jst...@usgs.gov> wrote:

Martin, thanks for the blog philosophical musings. As a data monger who buys data from all types of people and uses many different software programs to do our work, I have personally felt this frustration for years.

LAS 1.4 was approved by ASPRS in November of 2011. We have yet to reach community adoption of this version. I'm not completely sure why. Perhaps people do not care about all the improvements that were added? Perhaps it is because almost all software vendors either had issues with or simply did not want to bother with adopting it, so didn't? Perhaps a bit of both.

IMO, the reason why LAS 1.4 isn't widely adopted is it widely increased the number of decision branches an implementation must go down to provide full support. There's a lot of stuff in LAS 1.4 that is "specialized LiDAR software support stuff", but the format's station in life is "LiDAR point cloud interchange format", and these two things are in conflict. Add in the fact that LAS really models the data of linear systems (and even then specific hardware configurations of linear systems), and the seams are starting to rip apart a little bit.

Software complexity of an LAS implementation by version (Histograms not to scale and drawn for dramatic effect)

-----------------------------------------------------------------------------------------------------------------------------------------

LAS 1.0 XXXXXXXXXXXX

LAS 1.1 XXXXXXXXXXXXXXX

LAS 1.2 XXXXXXXXXXXXXXXXXX

LAS 1.3 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

LAS 1.4 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

LAS 1.4 has the double whammy of being more complex than many need *and* not providing the two most critical format capabilities desired today -- compression and spatially accelerated access. There's three significant open source implementations of LAS 1.4 that I know of -- LAStools, laspy, and PDAL. The LAS 1.4 feature implementation matrix of all three of these are not equivalent.

I think the situation gets better with more format proliferation, not less. The two tasks that LAS 1.4 tries to satisfy are not so well reconciled, and the pressure is to add even more complexity to LAS (a recipe for complete failure). I think it will follow the same pattern of format growth the raster world did in the 80s, 90s, and 00s, with formats focusing on data arrangements that allow them to do special things. GDAL grew to answer the question of how to deal with that growth in a way that was content agnostic, and PDAL is in the same niche for point clouds.

Howard

Martin Isenburg

unread,

Jul 14, 2017, 2:43:43 PM7/14/17

to LAStools - efficient command line tools for LIDAR processing

Hello,

I mildly disagree with Howard's over-negative assessment of LAS 1.4. It is still a fairly easy format to implement and not significantly more complex than LAS 1.2 apart from the "juggling" between the two different ways to specify the CRS. I think the main reason it is not being embraced as quickly is that the added value of the new point types over the old point types is minuscule. LAS 1.2 gave us RGB colored points. LAS 1.4 gave us ... the NIR channel? I think Howard's statement would to be more appropriate for the (hopefully forever shelved) LAS 2.0 specification ... (-:

Both Jason's and Howard's did not continue on my "philosophical musings" which was merely asking for more data embracing implementations of data import modules. Why did the Argh not read the points from that LAS file? The points were fine. Yes, my writer screwed up the OGC WKT representation of the CRS (by omitting a comma) but the points were still valid. My message was: your users are happier if your software is less strict which data it accepts. The moment to be strict with LAS data is when it is delivered and before you make the final payment ... (-:

Martin

Lewis Graham

unread,

Jul 14, 2017, 2:43:54 PM7/14/17

to last...@googlegroups.com

We (GeoCue) did not find LAS 1.4 difficult to implement. I just think it is driven by customer needs. Only USGS is demanding LAS 1.4 so we can pretty much tell whose software they are using based on who has implemented LAS 1.4.

Lewis Graham

GeoCue Group Inc.

9668 Madison Blvd., Suite 202

Madison, AL 35758 USA

256-461-8289

www.geocue.com

Software tools for LIDAR & Drone Mapping

Bespoke Enterprise Workflow Solutions

Drone Mapping Services

Technical Consulting

--

Reply all

Reply to author

Forward