@guskov:
I definitely intend to write an article about the Lidar processing I am doing, the only problem is that I am still modifying my code more or less every day, and I would like a somewhat more stable basis for the article.
All the code is pure Perl (i.e. just like Mr. RouteGadget), but since I call various lastools binaries for things like converting .laz files to .txt format and piping the result into my code it needs a Windows platform.
The steps I use today is
a) Contour lines, including extra help lines, depressions, dot knolls, fall line markers and negative contours.
b) DEM (in ASC format, easy to import and relatively compact)
c) Slope image with some extra emphasis on smaller slope angles, i.e. I use the 0.7th power instead of a linear mapping.
After generating the slope angles I also specialize them into B/W cliff images, with cutoffs based on the angles that corresponds to 1,2,3 m altitude change in 1 m horizontal distance. The main problem with this today is that I tend to get missing ground points at the top of cliff faces, I've had the same issue both with lastools' lasground and with mcclidar, the basic Norwegian LAS file ground classification is just about equivalent.
d) Vegetation classification: I use lasheight (also from lastools) to classify vegetation points into classes that are relevant to orienteering:
Low (class 3): 30 cm to 1.2 m. This is low brush which can impact runnability but not the visibility so it will be mapped with green stripes if sufficiently dense.
Medium (class 4): 1.2 to 4 m. This is the kind of vegetation that gives various levels of green on the map.
High (class 5): 4+ m. Classic white forest here in Scandinavia.
I use the relative densities of points in the Ground/Low/Medium/High to determine a probable vegetation class. In order to get a statistically sufficient number of points I've found that I need to sample a circle with a diameter of about 10 m which I centerweight. This is the raw classification for each 2x2m spot on the map.
The idea for the next step is one I've borrowed from Jarrko: A majority vote among all the classifications around each spot in order to reduce the amount of noise and make the result much more useful. (The majority vote is also center-biased via a set of sampling weights.)
The final step here in Norway is a SOSI to DXF converter: SOSI is the Norwegian Geo coding standard, since it uses UTM (usually in cm) for coordinates it is relatively easy to convert it to DXF with 1m floating point UTM coordinates.
Here is a small comparison:
This summer I ran a social event on a small island south of Fredrikstad:
http://tmsw.no/qr/show_map.php?user=terjem&map...Here is the north end of the same island after the automated process I outlined above:
http://tmsw.no/o/rossholmen_sample.jpgThe public path data is obviously pretty bad, but all the cabin outlines are pretty exact.
I use half the normal contour width for those extra help lines (1.25 m), this makes it easier to read the map!