|
|
|
|
LAStools IIRC encodes the non-standard HAG field into the 'user bytes' portion of the LAS file. It's special-sauce approach to encoding that information into a user-expandable portion of the LAS standard.
To keep in mind: the HAG field (again, IIRC) is based on an internal integer representation - it quantizes the data into the binned integers to store them. You want to ensure the resolution of the storage is appropriate for your application (though for most tree sizes, in most units, it's probably fine).
I don't think you'll find any tools outside of LASTools that support that feature. You may also not be aware that the 'free' or non-licensed version of LASTools imposes noise on output.
Daryl
_______________________________________________
Liblas-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
|
|
|
Hi,
I believe that Alex talks about the HAG stored as an additional point atttribute to an "Extra Bytes" field via the '-store_as_extra_bytes' switch.
There was a discussion on this in the LAStools user forum whether cm resolution with a scale factor of 0.01 and a 16 bits signed integer storage are enough for most trees.
"Extra Bytes" fields are described in the LAS 1.4 specification and are therefore also more and more readable in other software.
Regards from Brazil,
Martin @rapidlasso _______________________________________________
Liblas-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
|
|
|
All of this is accurate information.
Additionally, libLAS does not support LAS 1.4 or support writing LAS 1.4 extra bytes descriptor VLRs. You'll need to use LAStools or PDAL or LASpy to achieve this task if open source is a priority for you.
Howard
_______________________________________________
Liblas-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
|
|
|
Hi,
Thanks for your help. Actually, I havent' specified any switch in lasheight.
My file is in LAS 1.2 and effectively has the HAG value as it can be read by some commercial software such as GlobalMapper (as "HEIGHT_ABOVE_GROUND" attribute).
Is it therefore stored somewhere else than in extra-bytes or was LAS 1.2 already using extra-bytes ?
Thanks, Alex
All of this is accurate information. Additionally, libLAS does not support LAS 1.4 or support writing LAS 1.4 extra bytes descriptor VLRs. You'll need to use LAStools or PDAL or LASpy to achieve this task if open source is a priority for you. Howard _______________________________________________
Liblas-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
|
|
|
Hi,
in this case you are indeed just be storing HAG as a quantized value in decimeters (or decifeet) in the 8 bit unsigned user_data field that ranges from 0 to 255 (e.g. 0 to 25.5 meters or feet). See the README file of lasheight for details.
Furthermore you seem then to merely visualize the user_data field in Global Mapper and not a dedicated HAG field.
Regards,
Martin _______________________________________________
Liblas-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
|
|
|
Hi Martin,
I've actually add a look at this user_data field but have a single value of '2' for all my points when reading with libLAS while the HEIGHT_ABOVE_GROUND attribute showing in GlobalMapper is ranging from -0.002 to 33.909.
Cheers,
Alex
Hi,
in this case you are indeed just be storing HAG as a quantized value in decimeters (or decifeet) in the 8 bit unsigned user_data field that ranges from 0 to 255 (e.g. 0 to 25.5 meters or feet). See the README file of lasheight for details.
Furthermore you seem then to merely visualize the user_data field in Global Mapper and not a dedicated HAG field.
Regards,
Martin _______________________________________________
Liblas-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
|
|
|
Hi Martin,
The output of lasinfo is at the bottom of my message.
Actually, I've also done it with the '-histo user_data' switch and I get an output confirming your point (average of ~38.4 for the user_data field = an average HAG of 3.8m) :
-->
user data histogram with bin size 0
bin [0,0) has 994185
average user data 38.4314 for 994185 element(s) <--
So the issue seems to come from my use of the libLAS python API for which I only get a "user_data = 2" for all my points.
I am simply doing :
from liblas import file
cloud = file.File(las_file, mode='r')
for point in cloud :
print(point.user_data)
There's probably something I'm not getting.
Cheers, Alex
------------------
reporting all LAS header entries:
file signature: 'LASF'
file source ID: 1321
global_encoding: 0
project ID GUID data 1-4: 00000000-0000-0000-0000-000000000000
version major.minor: 1.2
system identifier: 'LAStools (c) by rapidlasso GmbH'
generating software: 'lasclassify (160921) unlicensed'
file creation day/year: 296/2015
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: 994185
number of points by return: 865554 116711 11586 341 0
scale factor x y z: 0.01 0.01 0.01
offset x y z: 0 0 0
min x y z: 597225.00 5331425.00 -6.10
max x y z: 597500.00 5331675.00 67.05
the header is followed by 2 user-defined bytes
LASzip compression (version 2.4r1 c2 50000): POINT10 2 GPSTIME11 2
reporting minimum and maximum for all LAS point record entries ...
X 59722500 59750000
Y 533142500 533167500
Z 1206 6705
intensity 1 4085
return_number 1 4
number_of_returns 1 4
edge_of_flight_line 0 1
scan_direction_flag 0 1
classification 1 6
scan_angle_rank -10 2
user_data 0 255
point_source_ID 212 213
gps_time 293715.352716 294035.308603
number of first returns: 865554
number of intermediate returns: 11938
number of last returns: 865515
number of single returns: 748822
WARNING: for return 2 real number of points by return (116706) is different from header entry (116711).
WARNING: for return 3 real number of points by return (11585) is different from header entry (11586).
WARNING: for return 4 real number of points by return (340) is different from header entry (341).
overview over number of returns of given pulse: 748822 210241 33761 1361 0 0 0
histogram of classification of points:
224735 unclassified (1)
358860 ground (2)
342265 high vegetation (5)
68325 building (6) user data histogram with bin size 0
bin [0,0) has 994185
average user data 38.4314 for 994185 element(s)
------------------ Hi,
We created lasinfo so you can share an overview of the contents of LAS / LAZ files without having to send the whole file ...
lasinfo -i sample.laz -odix _info -otxt
Regards,
Martin _______________________________________________
Liblas-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
|
|
Locked
