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