Las2dem extended class (98) problem

[Lui]

Hi

I'm experiencing some interesting problem building a DEM with las2dem. I have a point cloud where ground is in class 2 and redundant ground class in class 98. I would like to build a DEM only from points in class 2, so I'm using -keep_class 2 as an argument in las2dem processing. The problem is that points with class 98 are also taken into a count and resulting DEM is not "optimal". Of course I've tried with -drop_extended_classification 98 argument but it is not possible to use this parameter along with -keep_class 2 argument.

Interesting I also have points in extended class 99 and these are not used in DEM calculation. I'm using latest licensed LAStools version on Windows 10 platform.

Best regards

Lojze

[Jochen Rapidlasso]

Hi Lojze,

please extract and provide a small sample of your data and I will have a closer look.

Also provide exact the commands you did run.

Thanks,

Jochen @rapidlasso

[Lui]

OK I'm sending a small portion of point cloud. The command that ? was running was: las2dem -cores 12 -cpu64 -no_kml -step 0.5 -buffered 20 -keep_class 2 -i LAS_ground\*.las -odir dem_QA -otif

All best

Lojze

[Jochen Rapidlasso]

Hi Lojze,
thanks for the sample!

First I did a extract of class2 only
las2las -i las2dem_98_problems.laz -keep_class 2 -o o02.laz

Then I did the full dem:
las2dem -i las2dem_98_problems.laz -no_kml -step 0.5 -buffered 20 -o oall.tif

Now I did the full thing keeping only class 2 - so this is what you did and want:
las2dem -i las2dem_98_problems.laz -keep_class 2 -no_kml -step 0.5 -buffered 20 -o oall2.tif

And compare this to the definitly-class-2-only file
las2dem -i o02.laz -no_kml -step 0.5 -buffered 20 -o o2.tif

o2.tiff and oall2.tiff looks like they are the same.

So please check this again on your side or tell me if I got you wrong - right now I do not see something wrong.

Best,

Jochen @rapidlasso

[Terje Mathisen]

Lui wrote:

Hi

I'm experiencing some interesting problem building a DEM with las2dem. I have a point cloud where ground is in class 2 and redundant ground class in class 98. I would like to build a DEM only from points in class 2, so I'm using -keep_class 2 as an argument in las2dem processing. The problem is that points with class 98 are also taken into a count and resulting DEM is not "optimal". Of course I've tried with

Which LAS version are your files? Originally we only had 15 (or 31, I don't remember just now), so the LAS header use less than a full byte for this info. If you take 98 and AND it with the class mask (31), then you do get 2.

Make sure to download the latest LAStools version!

I.e. it seems like either your points are in fact class 2, you are just reading the headers wrong, or your las2dem version does not know how to handle extended range classes.

You should at least be able to filter just class 2 in a separate step.

Can you post the output of lasinfo -i <your_laz_file>?

Terje

-drop_extended_classification 98 argument but it is not possible to use this parameter along with -keep_class 2 argument.

Interesting I also have points in extended class 99 and these are not used in DEM calculation. I'm using latest licensed LAStools version on Windows 10 platform.

Best regards

Lojze

--
Download LAStools at
https://rapidlasso.de
Manage your settings at
https://groups.google.com/g/lastools/membership
---
You received this message because you are subscribed to the Google Groups "LAStools - efficient tools for LiDAR processing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lastools+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lastools/8a168f85-7679-46c7-935f-51dde096b6a7n%40googlegroups.com.

-- 
- <Terje.M...@tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[Lui]

Hi,

I've checked one LAS file with lasinfo and here are results:

lasinfo (221220) report for '329500_5188000.las'
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:     356/2022
  header size:                227
  offset to point data:       2073
  number var. length records: 3
  point data format:          1
  point data record length:   32
  number of point records:    23385059
  number of points by return: 21174031 1992402 208977 9465 184
  scale factor x y z:         0.01 0.01 0.01
  offset x y z:               0 0 0
  min x y z:                  329499.94 5187999.97 642.07
  max x y z:                  330000.07 5188499.99 779.03
variable length header record 1 of 3:
  reserved             0
  user ID              'LASF_Projection'
  record ID            34735
  length after header  16
  description          ''
    GeoKeyDirectoryTag version 1.1.0 number of keys 1
      key 3072 tiff_tag_location 0 count 1 value_offset 32633 - ProjectedCSTypeGeoKey: WGS 84 / UTM 33N
variable length header record 2 of 3:
  reserved             0
  user ID              'LASF_Projection'
  record ID            2112
  length after header  1282
  description          ''
    WKT OGC COORDINATE SYSTEM:
    PROJCRS["WGS 84 / UTM zone 33N",BASEGEOGCRS["WGS 84",ENSEMBLE["World Geodetic System 1984 ensemble", MEMBER["World Geodetic System 1984 (Transit)", ID["EPSG",1166]], MEMBER["World Geodetic System 1984 (G730)", ID["EPSG",1152]], MEMBER["World Geodetic System 1984 (G873)", ID["EPSG",1153]], MEMBER["World Geodetic System 1984 (G1150)", ID["EPSG",1154]], MEMBER["World Geodetic System 1984 (G1674)", ID["EPSG",1155]], MEMBER["World Geodetic System 1984 (G1762)", ID["EPSG",1156]], ELLIPSOID["WGS 84",6378137,298.2572236,LENGTHUNIT["metre",1,ID["EPSG",9001]],ID["EPSG",7030]], ENSEMBLEACCURACY[2],ID["EPSG",6326]],ID["EPSG",4326]],CONVERSION["UTM zone 33N",METHOD["Transverse Mercator",ID["EPSG",9807]],PARAMETER["Latitude of natural origin",0,ANGLEUNIT["degree",0.0174532925199433,ID["EPSG",9102]]],PARAMETER["Longitude of natural origin",15,ANGLEUNIT["degree",0.0174532925199433,ID["EPSG",9102]]],PARAMETER["Scale factor at natural origin",0.9996,SCALEUNIT["unity",1,ID["EPSG",9201]]],PARAMETER["False easting",500000,LENGTHUNIT["metre",1,ID["EPSG",9001]]],PARAMETER["False northing",0,LENGTHUNIT["metre",1,ID["EPSG",9001]]],ID["EPSG",16033]],CS[Cartesian,2,ID["EPSG",4400]],AXIS["Easting (E)",east],AXIS["Northing (N)",north],LENGTHUNIT["metre",1,ID["EPSG",9001]],ID["EPSG",32633]]
variable length header record 3 of 3:
  reserved             0
  user ID              'LASF_Spec'
  record ID            4
  length after header  384
  description          'RIEGL Extra Bytes'
    Extra Byte Descriptions
      data type: 4 (short), name "Reflectance", description: "Echo signal reflectance [dB]", min: -5000, max: 15000, scale: 0.01, offset: 0 (not set)
      data type: 4 (short), name "Deviation", description: "Pulse shape deviation", min: 0, max: 65535, scale: 1 (not set), offset: 0 (not set)
the header is followed by 2 user-defined bytes
reporting minimum and maximum for all LAS point record entries ...
  X            32949994   33000007
  Y           518799997  518849999
  Z               64207      77903
  intensity       23548      65535
  return_number       1          6
  number_of_returns   1          6
  edge_of_flight_line 0          1
  scan_direction_flag 1          1
  classification      2         16
  scan_angle_rank   -38         38
  user_data           0          0
  point_source_ID     8         19
  gps_time 342081605.037826 342094174.786176
  attribute0     -14.22      33.08  ('Reflectance')
  attribute1         -1        397  ('Deviation')
number of first returns:        21174031
number of intermediate returns: 239657
number of last returns:         21031578
number of single returns:       19060207
WARNING: for return 5 real number of points by return (182) is different from header entry (184).
WARNING: there are 2 points with return number 6
overview over number of returns of given pulse: 19060207 3656931 627008 39906 990 17 0
histogram of classification of points:
          208668  ground (2)
        22733183  low vegetation (3)
          284992  medium vegetation (4)
            2585  noise (7)
          129058  rail (10)
             238  road surface (11)
           26335  wire connector (16)
 +-> flagged as synthetic: 22735666
  +--->            2483 of those are ground (2)
  +--->        22733183 of those are low vegetation (3)
 +-> flagged as keypoints: 22735666
  +--->            2483 of those are ground (2)
  +--->        22733183 of those are low vegetation (3)

then I've made a statistics of same point cloud tile in Terra Scan:

ground (2)            206185
medium vegetation (4) 284992
low point (7)         2585
custom (10)           129058
air points(11)        238
custom 3 (16)         26335
temp ground (98)      2483
temp (99)             22733183
------------------------------
sum                   23385059

Well it's quite obvious what is going on. Class 2 has binary value 00000010 (extended class range: 0-255) or 00010 (default range: 0-31) while Class 98 has binary value 01100010 (extended class 0-255) or 00010 (default 0-31), so in non-extended class numbering schema point with classification attribute = 98 has the same class value as point with classification attribute = 2. Same is true for class pair 3:99, as it's obvious from comparing both statistics, where we get values that are reported using lasinfo if we summarize points from default class (3) and extended class (99).

Best regards

Lojze

[Lui]

Hello,

I've checked also las2las behavior with same results. Is there any way to correct this class bit overflow problem?

All best

Lojze