Re: [Liblas-devel] Liblas-devel Digest, Vol 79, Issue 1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Liblas-devel] Liblas-devel Digest, Vol 79, Issue 1

Van Dyke, Daryl
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

On Wed, Nov 9, 2016 at 12:00 PM, <[hidden email]> wrote:
Send Liblas-devel mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.osgeo.org/mailman/listinfo/liblas-devel
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Liblas-devel digest..."

Today's Topics:

   1. libLAS and HEIGHT_ABOVE_GROUND attribute (Alexandre Guyot)


---------- Forwarded message ----------
From: Alexandre Guyot <[hidden email]>
To: "[hidden email]" <[hidden email]>
Cc: 
Date: Tue, 8 Nov 2016 21:00:17 +0000
Subject: [Liblas-devel] libLAS and HEIGHT_ABOVE_GROUND attribute
Hi,

I'm using the liblas python API to read through some LiDAR point clouds.
I can access all the standard point attributes of my dataset, however I can't figure out how to read the HEIGHT_ABOVE_GROUND value of my points.
This HEIGHT_ABOVE_GROUND attribute was computed in LAStools using "lasheight".
This attribute is readable on popular LiDAR viewers (GlobalMapper for instance) but I don't know how to reach it using libLAS.

Any ideas ?

Thanks a lot,
Alex
 
 

_______________________________________________
Liblas-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/liblas-devel



--
_________________________________________
Daryl Van Dyke
GIS Analyst
Klamath Strategic Habitat Conservation Team
US Fish & Wildlife Service - AFWO, R8

_______________________________________________
Liblas-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Liblas-devel] Liblas-devel Digest, Vol 79, Issue 1

isenburg
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

On Wed, Nov 9, 2016 at 9:12 PM, Van Dyke, Daryl <[hidden email]> wrote:
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

On Wed, Nov 9, 2016 at 12:00 PM, <[hidden email]> wrote:
Send Liblas-devel mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.osgeo.org/mailman/listinfo/liblas-devel
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Liblas-devel digest..."

Today's Topics:

   1. libLAS and HEIGHT_ABOVE_GROUND attribute (Alexandre Guyot)


---------- Forwarded message ----------
From: Alexandre Guyot <[hidden email]>
To: "[hidden email]" <[hidden email]>
Cc: 
Date: Tue, 8 Nov 2016 21:00:17 +0000
Subject: [Liblas-devel] libLAS and HEIGHT_ABOVE_GROUND attribute
Hi,

I'm using the liblas python API to read through some LiDAR point clouds.
I can access all the standard point attributes of my dataset, however I can't figure out how to read the HEIGHT_ABOVE_GROUND value of my points.
This HEIGHT_ABOVE_GROUND attribute was computed in LAStools using "lasheight".
This attribute is readable on popular LiDAR viewers (GlobalMapper for instance) but I don't know how to reach it using libLAS.

Any ideas ?

Thanks a lot,
Alex
 
 

_______________________________________________
Liblas-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/liblas-devel



--
_________________________________________
Daryl Van Dyke
GIS Analyst
Klamath Strategic Habitat Conservation Team
US Fish & Wildlife Service - AFWO, R8

_______________________________________________
Liblas-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/liblas-devel


_______________________________________________
Liblas-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Liblas-devel] Liblas-devel Digest, Vol 79, Issue 1

Howard Butler-3

> On Nov 9, 2016, at 2:20 PM, Martin Isenburg <[hidden email]> wrote:
>
> 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.
>
> http://lastools.org/download/lasheight_README.txt
>
> 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.
>
> http://groups.google.com/forum/#!searchin/lastools/lasheight$20store_as_extra_bytes
>
> "Extra Bytes" fields are described in the LAS 1.4 specification and are therefore also more and more readable in other software.

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Liblas-devel] Liblas-devel Digest, Vol 79, Issue 1

alexguyot56
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
 
 



De : Howard Butler <[hidden email]>
À : Martin Isenburg <[hidden email]>
Cc : "Van Dyke, Daryl" <[hidden email]>; "[hidden email]" <[hidden email]>
Envoyé le : Mercredi 9 novembre 2016 21h29
Objet : Re: [Liblas-devel] Liblas-devel Digest, Vol 79, Issue 1


> On Nov 9, 2016, at 2:20 PM, Martin Isenburg <[hidden email]> wrote:
>
> 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.
>
> http://lastools.org/download/lasheight_README.txt
>
> 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.
>
> http://groups.google.com/forum/#!searchin/lastools/lasheight$20store_as_extra_bytes
>
> "Extra Bytes" fields are described in the LAS 1.4 specification and are therefore also more and more readable in other software.

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



_______________________________________________
Liblas-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Liblas-devel] Liblas-devel Digest, Vol 79, Issue 1

isenburg
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

On Wed, Nov 9, 2016 at 9:55 PM, Alexandre Guyot <[hidden email]> wrote:
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
 
 



De : Howard Butler <[hidden email]>
À : Martin Isenburg <[hidden email]>
Cc : "Van Dyke, Daryl" <[hidden email]>; "[hidden email]" <[hidden email]>
Envoyé le : Mercredi 9 novembre 2016 21h29
Objet : Re: [Liblas-devel] Liblas-devel Digest, Vol 79, Issue 1


> On Nov 9, 2016, at 2:20 PM, Martin Isenburg <[hidden email]> wrote:
>
> 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.
>
> http://lastools.org/download/lasheight_README.txt
>
> 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.
>
> http://groups.google.com/forum/#!searchin/lastools/lasheight$20store_as_extra_bytes
>
> "Extra Bytes" fields are described in the LAS 1.4 specification and are therefore also more and more readable in other software.

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




_______________________________________________
Liblas-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Liblas-devel] Liblas-devel Digest, Vol 79, Issue 1

alexguyot56
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

 
 



De : Martin Isenburg <[hidden email]>
À : Alexandre Guyot <[hidden email]>
Cc : Howard Butler <[hidden email]>; "Van Dyke, Daryl" <[hidden email]>; "[hidden email]" <[hidden email]>
Envoyé le : Mercredi 9 novembre 2016 22h30
Objet : Re: [Liblas-devel] Liblas-devel Digest, Vol 79, Issue 1

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

On Wed, Nov 9, 2016 at 9:55 PM, Alexandre Guyot <[hidden email]> wrote:
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
 
 



De : Howard Butler <[hidden email]>
À : Martin Isenburg <[hidden email]>
Cc : "Van Dyke, Daryl" <[hidden email]>; "[hidden email]" <[hidden email]>
Envoyé le : Mercredi 9 novembre 2016 21h29
Objet : Re: [Liblas-devel] Liblas-devel Digest, Vol 79, Issue 1


> On Nov 9, 2016, at 2:20 PM, Martin Isenburg <[hidden email]> wrote:
>
> 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.
>
> http://lastools.org/download/ lasheight_README.txt
>
> 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.
>
> http://groups.google.com/ forum/#!searchin/lastools/ lasheight$20store_as_extra_ bytes
>
> "Extra Bytes" fields are described in the LAS 1.4 specification and are therefore also more and more readable in other software.

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






_______________________________________________
Liblas-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Liblas-devel] Liblas-devel Digest, Vol 79, Issue 1

isenburg
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

On Wed, Nov 9, 2016 at 10:42 PM, Alexandre Guyot <[hidden email]> wrote:
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

 
 



De : Martin Isenburg <[hidden email]>
À : Alexandre Guyot <[hidden email]>
Cc : Howard Butler <[hidden email]>; "Van Dyke, Daryl" <[hidden email]>; "[hidden email]" <[hidden email]>
Envoyé le : Mercredi 9 novembre 2016 22h30

Objet : Re: [Liblas-devel] Liblas-devel Digest, Vol 79, Issue 1

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

On Wed, Nov 9, 2016 at 9:55 PM, Alexandre Guyot <[hidden email]> wrote:
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
 
 



De : Howard Butler <[hidden email]>
À : Martin Isenburg <[hidden email]>
Cc : "Van Dyke, Daryl" <[hidden email]>; "[hidden email]" <[hidden email]>
Envoyé le : Mercredi 9 novembre 2016 21h29
Objet : Re: [Liblas-devel] Liblas-devel Digest, Vol 79, Issue 1


> On Nov 9, 2016, at 2:20 PM, Martin Isenburg <[hidden email]> wrote:
>
> 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.
>
> http://lastools.org/download/ lasheight_README.txt
>
> 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.
>
> http://groups.google.com/ forum/#!searchin/lastools/ lasheight$20store_as_extra_ bytes
>
> "Extra Bytes" fields are described in the LAS 1.4 specification and are therefore also more and more readable in other software.

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







_______________________________________________
Liblas-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Liblas-devel] Liblas-devel Digest, Vol 79, Issue 1

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



De : Martin Isenburg <[hidden email]>
À : Alexandre Guyot <[hidden email]>
Cc : Howard Butler <[hidden email]>; "Van Dyke, Daryl" <[hidden email]>; "[hidden email]" <[hidden email]>
Envoyé le : Mercredi 9 novembre 2016 22h45
Objet : Re: [Liblas-devel] Liblas-devel Digest, Vol 79, Issue 1

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