Hamish wrote:
Hamish wrote:
Mateusz:
Hamish wrote:
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?
Mateusz:
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.
Helena:
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).
Ok, I think a new -r flag could be added to r.in.xyz to tell the
input= file to expect a LAS file instead of a text file. (I don't
like -l, it is too close to -1 in some fonts)
[...]
I would be happy to hand the vector/raster output question over to
the LIDAR users, as I'm not sure myself what your final output needs
are. e.g. what's the next step after import? v.surf.rst? r.univar?
thresholding?
Helena, Hamish,
Obviously, I'm useless in solving the issues above, so I'm going to
leave the final decision about incorporating (or not) libLAS
support to the GRASS Team.
If there is a positive decision and you will like to implement libLAS
module/support, I'd be happy to help or perhaps contribute in future.
Greetings
--
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
