Showing posts with label lidar. Show all posts
Showing posts with label lidar. Show all posts

Thursday, May 23, 2019

A new HM tool: the las info viewer

In the open source world there are by now several tools to visualize and manage pointclouds. Over the years in our field of study (forestry) we simply found that viewing pointclouds in 3D is fancy, everyone wants it, but in the end it is mostly useless. That is clearly just my opinion, since all the tools out there have a nice 3D view of the data. Still we felt we needed something more suitable for our needs. And since the Hortonmachine already has a lot of tools to handle las data, why not aggregate them into a simple viewer that would allow us to quickly analyze a set of data, visually understand its issues, content, outlayers, intensity variations, etc etc?

Let's have a look at what we came up til now.

The viewer: once you open it, looks like this:


You can load las/laz files and set filters on any of the properties of a las point, as well as define a subregion or some subsampling. This is particularly useful when you load huge datasets as for example terrestrial scans.

First, let's load a aerial scan from our local administration:


Some header information about the file is shown as well as information about the first point of the file.
By default coloring is done based on elevation.

But one can select also intensity:


A popup on the map view shows some stats about the currently visible data. There for example we can see that intensity reaches over 5000.

Let's try to set an intensity range filter between 0 and 500. The result now is:


Hmmm, it seems we still have some "outlayers". Let's check all the points in which intensity is higher than 300 then:


It seems save to filter some more, let's say 0 to 300:


Well, better, but intensity is anyways always a mess in las data :-D

Let's have  a look at classification:


or impulses (they might be handy to understand smaller areas?):


Well, maybe we could add a DTM and have a feeling about the canopy height model (switching back to coloring by elevation)?


Hmmm, coloring looks odd, there might be some outlayers... the stats, now that the DTM is involved, also tell us the height from the ground. It seems we have trees of around 500 meters. Let's have a look where all point with height major than 80 meters are placed:


Oh, look, this seems a border problem coming from the difference with the DTM. Well, let's just get rid of them by selecting a smaller region:


and load it:


Now this looks way better. Maybe let's try to filter away the ground by thresholding the data post DTM difference at 1.3 meters:


Just know that you can export what you see as new las file or shapefile and use that for some further analyses.

But let us see an example with a more dense pointcloud, coming from a terrestrial laser scan done at the University.

Since the las file is of 3 giga, if is safe to first load it with a sumsampling of 1 point every 1000:


Then we can narrow down the area and reload the data without subsampling:


Looking at the first point table we see that the point's color information is available. Let's use that coloring:



By selecting a subregion and pushing the 3D button we can also check where the markers were placed and where we left our bag :-D


or maybe check the scan area:


It is also possible to enable the horizontal slicing mode. Once done and defined the slice interval and the width of each slice, you can load the data. This will populate the slices combobox with the different slice elevations. By selecting one, the map view will update with the slice:


Let's look for a slice where the trees are better identified:


And now push the extract circles button (mind, the tools is highly experimental and will need some love in future):


You will find that the trees extraction is not so bad (there are some false positives and negatives) and it nicely keeps the information about the radius. If your data had a proper referencing you can then export those to a shapefile.

Conclusions

This is a usual tool done without funding to help us doing our daily job. As such you have to know how to use it and maybe get used to it, else it will turn against you and make you crazy. Also it is not particularly memory saving, even if one can decide what to load into memory.

That said, we will put it in the next hortonmachine release, so if you like, enjoy it!





Saturday, June 11, 2011

LIDAR data & jgrasstools and uDig

Well, we always like to look at things from different perspectives. And we are really fast when we use our own tools, that we can bend and change to our needs.

We are slowly bringing some las reader we wrote into the jgrasstools family, so that we then can add some analysis support. Sure thing nothing to do with the great laslib project, but it is handy for us to be able to certain tasks without dependencies and most of all be able to chain results into other modules directly.

So a first test takes 22M of points, filter them down to 12M (only first impulse) and splits them over 1M points shapefiles. I tried to write one single shapefile, but the geotools shp writer simply froze :) Will have to investigate further.

One thing uDig is really one of the best at, is to visualize HUGE amount of features. I am always amazed to see how well it does in that. Here 10M points loaded after properly stiling them by quantiles:



Yes, it already look nice for a first test. Zooming in it looks even better:



Yes, yes, shapefiles are maybe not the best format to use in this case, but hey, I really enjoy to play around with them to have a better feeling about what I am dealing with.

Well, this is a starting point. Let's see were it leads to...

Thursday, February 25, 2010

About 7.000.000 and more lidar points, the quest for Powerline extraction and JGrass asking help to Nasa World Wind

Do you know what this is?


More than 7.000.000 of points rendered in JGrass from a las file. Yes, It does look awsome and is well navigable (with enough ram and videocard :)).

How? By putting Nasa World Wind as a plugin into JGrass and tweak a bit the OpenGL rendering through the jogl libraries.

Why? Prototyping around extraction of powerlines.

Want to know more? What happened next?
Well... we were asked to explore a bit with feature extraction from lidar data, starting fromm the most difficult: powerlines.

While prototyping we added some tools to read las files and filter the signals through intensity, density of points, elevation difference with the dtm and things like that. Well the result up to now is pretty nice...

Ok, first let's extract the data inside a polygon... now can you see the powerlines?


Ok, let's change the coloring... no more elevation based, but intensity based:


And here we zoom in and color based on point density (in 3d), now the powerlines are already colored differently from most of the rest.



Some filtering based on intensity, density and elevation difference with the dtm and here we go (it looks empty, but have a closer look):




Let's get back to 2d using a small partial example, how does that look like?



Hmmmm, looks that one of the two is a bit wrongly placed... let's check:




Seems we are right? Check with the aerial photo:



Aha, so we are right...

Well, this is just the first part, but it already look promising.

Looking forward to mature this plugin to get it into the JGrass plugins that are going to be released.