Hello Edgar,
> I am trying to get a correct understanding of how the
> lasheight.exe tool works and if it can be used for a
> point classification process.
excellent question. lasheight.exe can be used for the same type of
vegetation classification based on the height above ground that you
may have seen in terrasolid's software suite.
> I want to classify data between two elevations above my
> ground surface to eg. high vegetation, class 5, but I would
> also like to be able to classify below ground data to noise,
> class 7.
there are three options you can use to do this: "-classify_below -1 7"
will classify all points with a height below -1 as 7. "-classify_above
100 10" will classify all points with a height above 100 as 10.
"-classify_between 0.5 2 3" will classify all points with a height
between 0.5 and 2.0 as 3, ... you can combine these to cover all the
ranges you are interested in.
the attached screenshots show how to use the GUI of lasheight to do a
typical classification of vegetation into 3 classes (low/mid/high).
if - in addition - you want to "protect" a particular class from being
re-classified (e.g. buildings or wires) you can specify this with
'-ignore_class 6'.
> Without normalizing my data (I would like to keep the
> data intact, maintain the absolute ground elevations and
> absolute above ground elevations) I want to classify my
> above and below ground data based on the relative height
> above ground. Is that at all possible with lasheight or am
> I using the wrong tool?
By default lasheight does *not* normalize the data. You need to
request this explicitely with '-replace_z'. By default the height is
quantized to increments of 0.1 (multiplied by 10 and then quantized to
an integer and clamped to the 0 to 255 interval) so it can be stored
in the 8 bit user data field and re-used by lasclassify.
> And if I would normalise the data, would I loose any accuracy
> in the above ground elevations? If I understand it correct, the
> lasheight.exe tool does not store the actual 'above ground
> height', but it has to store a derived scaled value between 0
> and 255 as an unsigned char as a in the user_data field. If my
> above ground data is ranging between eg. 0.01 and 120m, do
> I still maintain cm accuracy or will that be degraded?
If you use the '-replace_z' option you retain full accuracy of the
height. Only for storage in the 8-bit user data field the height is
scaled and clamped.
Regards,
Martin @lastools