Re: [LAStools] ESRI Las to Multipoint Error

[Martin Isenburg]

Hello Rick,

seems like the problem is not with the 2 bytes (that originated in the
LAS 1.0 specification) that some LAS exporters still write, but rather
that the procedure for parsing the GeoTIFF tags containing the
projection information bails and then causes the entire import to
abort. Should that be the case you should file an error ticket with
ESRI. You can find out if this is indeed the case by removing all
VLRs:

las2las -i in.las ^
-remove_extra :: gets rid of those 2 addition user
defined bytes ^
-remove_all_vlrs :: gets rid of the projection VLRs ^
-o out.las

which software did you use to produce that LAS file? Looks terrible
and could use a run through this procedure to satisfy my aesthetic
needs ... (-;

http://groups.google.com/group/lastools/browse_thread/thread/a0af35104afb5b76

Cheers,

Martin @rapidlasso

--
http://rapidlasso.com - fast tools for fixing LiDARs

On Mon, Apr 8, 2013 at 5:04 AM, Rick W <rick.w...@cna.nl.ca> wrote:
> Hi there,
>
> I have an issue which I hope someone might shed some light on. I use a tool
> in ArcGIS to create a multipoint featureclass. As of 10.1 it now complains
> about the header.(Note this works in 10.0!)
>
> Error as follows................
>
> “Error running Las to multipoint.
>
> <Error>ERROR 999999: Error executing function.</Error> <Error>Failed to read
> LAS linear unit geo-key.</Error> <Error>Failed to execute
> (LASToMultipoint).</Error>”
>
>
>
> ESRI has identified it as a bug with the following vague description…..
>
> "The problem has been figured out. It is because the dataset contains 2
> additional user defined bytes in the header. The current Las SR support does
> not take the user defined bytes into account when checking the total number
> of bytes after geo tags.
>
>
>
> Apparently, we should be letting these user defined bytes slide – like,
> they’re ok, but we’re complaining about them. Is the user aware of these
> bytes? We are looking into altering the code to not complain about them."
>
> Lasinfo……………
>
> L:\Data\LiDAR\LiDAR2010\ALLHITS_CGVD28\LAS\CORNERBROOK>lasinfo
> CONA_CornerBrook_426000_5419000_ALLHITS_CGVD28.las
> reporting all LAS header entries:
> file signature: 'LASF'
> file source ID: 0
> global_encoding: 0
> project ID GUID data 1-4: 0 0 0 ''
> version major.minor: 1.2
> system identifier: 'Virtual Geomatics'
> generating software: 'GeoCore LAS Direct Transformer'
> file creation day/year: 285/2010
> header size: 227
> offset to point data: 511
> number var. length records: 2
> point data format: 1
> point data record length: 28
> number of point records: 109380
> number of points by return: 80550 23870 4546 403 11
> scale factor x y z: 2.01249e-008 1.88671e-007 1.93053e-008
> offset x y z: 426964.98499999969 5419635.3300000001
> 234.51141994157703
> min x y z: 426928.96999999939 5419297.6899999995
> 199.96328831456941
> max x y z: 427001 5419972.9700000007 269.05955156858465
> variable length header record 1 of 2:
> reserved 43707
> user ID 'LASF_Projection'
> record ID 34735
> length after header 48
> description 'Georeferencing Information'
> GeoKeyDirectoryTag version 1.1.0 number of keys 5
> key 1024 tiff_tag_location 0 count 1 value_offset 1 -
> GTModelTypeGeoKey: ModelTypeProjected
> key 1025 tiff_tag_location 0 count 1 value_offset 2 -
> GTRasterTypeGeoKey: RasterPixelIsPoint
> key 3072 tiff_tag_location 0 count 1 value_offset 2962 -
> ProjectedCSTypeGeoKey: look-up for 2962 not implemented
> key 4097 tiff_tag_location 34737 count 128 value_offset 0 -
> VerticalCitationGeoKey: CGVD28 via HTv2; Height Model: Canadian Height
> Transformation v2
>
> Information v2 Model
>
> key 4099 tiff_tag_location 0 count 1 value_offset 9001 -
> VerticalUnitsGeoKey: Linear_Meter
> variable length header record 2 of 2:
> reserved 43707
> user ID 'LASF_Projection'
> record ID 34737
> length after header 128
> description 'Georeferencing Parameters'
> GeoAsciiParamsTag (number of characters 128)
> CGVD28 via HTv2; Height Model: Canadian Height Transformation v2
> Model; Vertical Datum: Canadian Height Transformation v2 Model|
> reporting minimum and maximum for all LAS point record entries ...
> X -1789569706 1789569706
> Y -1789569706 1789569706
> Z -1788797930 1788331394
> intensity 10 424
> edge_of_flight_line 0 0
> scan_direction_flag 0 0
> number_of_returns_of_given_pulse 1 5
> return_number 1 5
> classification 2 5
> scan_angle_rank 0 0
> user_data 2 13
> point_source_ID 1 5
> gps_time 565268.991098 566383.269676
>
> overview over number of returns of given pulse: 56612 38651 12482 1580 55 0
> 0
>
> histogram of classification of points:
>
> 47558 Ground (2)
>
> 20030 Low Vegetation (3)
>
> 41792 High Vegetation (5)
>
> -----------------------------------------------------------------------------------------
>
>
>
> Any idea what ESRI means when they say “It is because the dataset contains 2
> additional user defined bytes in the header” and can it be fixed with
> lastools?
>
>
> Thanks
>
> --
> 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
>
>

[Wheeler, Rick]

Thanks,

 

I will give that a try.

 

The readme for las2las states

" >> las2las -i in.las -o out.las -clip_intensity_below 1000 -remove_extra_header

 

clips all points of in.las whose intensity is below 1000 and

stores surviving points to out.las. in addition all variable headers

and any additional user headers are stripped from the file."

 

Should this be ">> las2las -i in.las -o out.las -clip_intensity_below 1000 -remove_extra" instead?

 

The las file was generated by Virtual Geomatics.

 

Rick Wheeler

Data/Systems Specialist

Geospatial Research Facility(GRF)

Ph:709-637-8558

Fax:709-634-8767