reclassify based on Heigh Above Ground gone wrong

37 views
Skip to first unread message

Tom van der Putte

unread,
Nov 24, 2022, 8:53:56 AM11/24/22
to LAStools - efficient tools for LiDAR processing
Hi!

I have an already classified LAS file (manually, with many classes). But low vegetation was a pain to classify. So I set most vegetation to 5 (high) and now I want to use lasheight to calculate the height above ground and based on that reclassify everything 

- in class 3, 4 and 5  (all veg)  
- between 0.25 and 2 above ground

to low vegetation (3).

I used this command:

 lasheight 
-i LMB_cleaned_classified_intensity.las 
-class 2 65 72 
-classify_between 0.0 2.0 3 
-ignore_class 1 2 6 7 9 10 11 12 13 14 15 16 17 18 19 20 21 22 64 65 66 67 68 70 71 72 
-o LMB_cleaned_classified_intensity_hag.las

class 2, 65 and 72 are set to be used for ground because I've made a distinction between normal ground, embankments and depressions. But all three should be regarded as ground for the DTM process.

This is a sample of the input:
before.png

and this is the output:
after.png
Now, the vegetation reclass worked (awesome) but for some reason class 72 (embankment) was also reclassed, whilst it was added to the ignore list.

Any clues on why? 

Best regards,
Tom

Jochen Rapidlasso

unread,
Nov 24, 2022, 11:21:35 AM11/24/22
to LAStools - efficient tools for LiDAR processing
Hi Tom,
after extracting the problem it went away :)

This is my in file (xyz and class) "in.txt":

1 1 2.00 2
1 3 2.00 2
2 2 2.00 2
3 1 2.00 2
3 3 2.00 2
1 2 3.10 3
2 1 3.20 70
2 3 3.30 72
3 2 3.40 5
 
txt2las -i in.txt -o tst.laz -parse xyzc -set_point_data_format 6

makes a laz out of it.

lasinfo -i tst.laz

shows me:

histogram of classification of points:
               5  ground (2)
               1  low vegetation (3)
               1  high vegetation (5)
histogram of extended classification of points:
               1  extended classification (70)
               1  extended classification (72)

which seems ok for me so far.

after

lasheight -i tst.laz -class 2 65 72 -classify_between 0.25 2.0 3 -o out1.laz -ignore_class 1 6 7 9 10 11 12 13 14 15 16 17 18 19 20 21 22 64 66 67 68 70 71
(i did not put the ground classes in the ignore_class, cause they are ground anyway,
but it did not make a difference)

lasinfo -i out1.laz
give me:

histogram of classification of points:
               5  ground (2)
               2  low vegetation (3)
histogram of extended classification of points:
               1  extended classification (70)
               1  extended classification (72)

las2txt -i out1.laz -o out1.txt -parse xyzc
type out1.txt

1.0000000 1.0000000 2.00 2
1.0000000 3.0000000 2.00 2
2.0000000 2.0000000 2.00 2
3.0000000 1.0000000 2.00 2
3.0000000 3.0000000 2.00 2
1.0000000 2.0000000 3.10 3
2.0000000 1.0000000 3.20 70
2.0000000 3.0000000 3.30 72
3.0000000 2.0000000 3.40 3  

so this looks quite ok.

please test again (may with a small sample...)
may you can use "-filtered_transform" as well as I was remembered this morning :)

Best regards,

Jochen @rapidlasso

Tom van der Putte

unread,
Nov 25, 2022, 6:16:46 AM11/25/22
to LAStools - efficient tools for LiDAR processing
Dear Jochen,

thanks for the feedback. I went on and tried with different sections of my point cloud. Started out really small, a few thousand points, and worked my way up. At this scale, it still worked as expected (I recolored class 72, embankments to yellow to make a clearer distinction):
Screenshot 2022-11-25 100839.png

but going back to the original size, the same thing happens.
Screenshot 2022-11-25 101855.png
 A few things do not make sense:

- From your message I gather that the ground classes should never be reclassified, but even if I take them up in the ignore_class, it is still changed
- Another extended class, 64 is also reclassed (see green arrow) (also in ignore list), but other extended classes are not. 
- they are both reclasssified to a value that makes absoluetly no sense: if for some reason it should be classified, it should at least be class 3.

The only thing that all the correct files had in common, was that I extracted the sections with CloudCompare and saved the resulting sections. So I tried simply saving the whole file via CC, and then it worked :o

So there is something in the original file that makes lasheight behave the way it does. Is it possible for you to find out what it is exactly if I send you the file?

regards,
Tom

Tom van der Putte

unread,
Nov 25, 2022, 7:55:36 AM11/25/22
to LAStools - efficient tools for LiDAR processing
Another addition:

allthough CC see's the classifications correctly, running lasinfo shows me a weird histogram:

BEFORE EXPORT WITH CC:
histogram of classification of points:
           11174  never classified (0)
           98019  unclassified (1)
         6933946  ground (2)
          742289  low vegetation (3)
         6146694  high vegetation (5)
          297271  building (6)
           17818  noise (7)
          316035  keypoint (8)
             227  Reserved for ASPRS Definition (18)
           83414  Reserved for ASPRS Definition (20)


AFTER EXPORT WITH CC:
histogram of classification of points:
             825  never classified (0)                                  
         6933245  ground (2)
          742289  low vegetation (3)
         6146694  high vegetation (5)
          255295  building (6)                          
             227  Reserved for ASPRS Definition (18)
           83414  Reserved for ASPRS Definition (20)

histogram of extended classification of points:
           10349  extended classification (64)
           98019  extended classification (65)
             701  extended classification (66)
           41976  extended classification (70)
           17818  extended classification (71)
          316035  extended classification (72)

For some reason it sees extended classes as 'regular' classes (scaled back perhaps?) and other classes are actually added together for the count (the number of points before exporting for class 6 building, is the same number of the actual buildingpoints + class 71 in the after export file)...

Any clues? The original file comes from another pipeline which I'm using for a lot of point clouds, and they all need to be processed in the way described in the first post. Im/exporting them with CloudCompare is not the best way I think. So any help I can get why LasTools is not interpreting them the way I want it, would be appreciated!

Tom

Tom van der Putte

unread,
Nov 25, 2022, 7:56:02 AM11/25/22
to LAStools - efficient tools for LiDAR processing
SOLVED:

OK, the issue has been found (great, talking to myself) but for future reference:

The file was at one time saved in LAS 1.2 and the pipeline keeps the original version as output.  LAS 1.2does not have the 8-bit extended classification. All my other files do not have this issue.

So: make sure to use 1.3 or 1.4 :)



Jochen Rapidlasso

unread,
Nov 25, 2022, 7:59:32 AM11/25/22
to LAStools - efficient tools for LiDAR processing
Hi Tom,
thanks for answering your question :)
You saved my weekend...

Jochen @rapidlasso

Reply all
Reply to author
Forward
0 new messages