[GRASS-dev] Announcing libLAS

[Helena Mitasova]

On May 5, 2008, at 10:37 AM, Mateusz Loskot wrote:

> Hamish wrote:
>> Mateusz:
>>> Yes, it confirms what I've read in GRASS docs and Wiki pages,
>>> that there is no direct support to ASPRS LAS format.
>> ...
>>> I'm willing to contribute a module for LAS read/write. However,  
>>> I'm not
>>> an experienced GRASS user nor developer, so I'll likely need to  
>>> prepare
>>> myself a little (read docs and code) before I can start. Means,  
>>> I'm not
>>> sure I can provide you with ready solution very soon.
>> ...
>>> The libLAS building follows well-known *nix patterns and there is  
>>> autotools-based builder. Optionally, users are provided with  
>>> cmake configuration as well as project files for Visual C++ 2005.
>>> The library itself has no external dependencies.
>> Hi,
>> I don't claim to know anything about what libLAS does, so sorry if  
>> this
>> doesn't make sense. But if it is purely vector format I/O would it be
>> better to write it as a new format for GDAL's OGR and have grass  
>> access
>> it with v.in.ogr?
>
> Hamish,
>
> I agree that the LAS format is a vector format by data nature and  
> structure. However, considering how LiDAR clouds are usually  
> processed and analysed, they are closer to rasters and grids:
> 1. It's not uncommon to store millions of points in a single LAS file.
> 2. Mostly we are not interested in a single point feature but in  
> groups/areas of hundreds or thousands
> 3. A feature-oriented seems not very usable
>
> Technically, there is no problem with translating LAS file to OGR  
> datasource and there is a prototype of appropriate tool [1] available,
> but I'm not optimistic in its usability and *performance* in  
> processing
> of large sets of LiDAR data.
>
> [1] http://liblas.org/svn/trunk/apps/las2ogr.cpp
>
>> Or is the dataset size/model such that it is better to directly
>> import/process it in GRASS using fast C modules as a front end to the
>> lib?
>
> Yes, this is my understanding. As a note of explanation, I'm not a  
> very experienced user of LiDAR data, so I'm not able to explain the  
> nature of processing and analysis of "huge clouds of points" datasets.
> However, I understand that speed and performance is a critical factor.

Hamish - what Mateusz is saying is right - in fact the first thing I  
had in mind was to ask both of you to see how to make r.in.xyz read  
the LAS data directly (and maybe even run several of the statistics  
at once, if possible). The data sets usually have millions of points  
(you may remember the email about my colleague running r.in.xyz with  
1.5 billion points) so skipping the ascii conversion may help quite a  
bit.

However, there are applications when it is useful to import the data  
as vector points (at least some smaller data sets or subsets). From  
the point of view of code maintenance doing it through v.in.ogr would  
be the best, if that proves too inefficient,  a new module v.in.las  
is another option. With any import as vector points we would have to  
deal with the issue of skipping the topology and thus having only few  
modules work with the data - but this goes beyond the libLAS.

I just got a new data set for Jockey's ridge acquired by the state-of- 
the-art lidar in 2007 with data in all kinds of formats including  
LAS. I posted one tile LAS and filtered points txt file here:

http://skagit.meas.ncsu.edu/~helena/grasswork/grassbookdat/
JR_442*.txt.gz
c_JR_442*.las.gz

There is also the old GRASS5 Location in UTM nclidar-utm.tar.gz, that  
should have the 1999 data in the same coordinate system (UTM) so the  
2007 data can be imported there (I haven't done it yet)
(note that the 1999 points are in old sites format).
Eventually I will  create a special MAPSET for nc_spm data set with  
time series of coastal data including JR, but this is what I have for  
now.

Mateusz, just FYI, this is more about the place from where the data  
come:
http://skagit.meas.ncsu.edu/~helena/measwork/jockeys/jockey.html

Helena


>
> Greetings
> -- 
> Mateusz Loskot
> http://mateusz.loskot.net