[Liblas-devel] Indexing for point clouds

Etienne Bellemare etiennebr at gmail.com
Wed Apr 22 08:49:52 EDT 2009


I agree with you Hamish, I didn't thought about increasing data sets and
hidden information. But still, I think that if you know what you are doing,
and you do it without erasing the original file (increasing need for storage
-which is the same problem as the index) it might be a simple solution (i.e.
not introducing any other file) that can improve speed.  Is speed
improvement the only virtue of spatial indexing, or am I wrong ?

Etienne

On Wed, Apr 22, 2009 at 6:18 AM, Hamish <hamish_b at yahoo.com> wrote:

>
> just a small argument against re-ordering data.
>
> the raw order gives some information re. time of sample and direction of
> travel for a cost of 0 bytes. if the instrument or navigation goes a bit
> wonky for a short while and this is not noticed until late in the post-
> processing stage (when you're pouring through the data) it provides an
> efficient method or slicing out a chunk of data from a specific length
> of that specific transect. if your swaths overlap and you removed the
> raw order, the best you could do would to be to chop by geographical
> extent, even for the swaths which overlap the region which are fine.
>
> also anything that introduces memory or processing time overheads must
> be built in a way that will scale to much larger datasets than we have
> today (but might in 5 years time, when hopefully this fine library is
> still in active use)
>
>
>
> Also, I've been meaning to send a note about the C/C++ ABI stability
> issues. There was a thread on the DebianGIS list about GDAL's C/C++
> ABI and who should link to what. The result was that the C ABI was
> heavily favoured for external apps to use even though internally
> GDAL is written in C++. Maybe it is just GDAL specific -- you can read
> Frank's comments at the following link, possibly it gives you some ideas
> for how to handle this in libLAS.
>
> http://thread.gmane.org/gmane.comp.gis.grass.pkg.general/1230/focus=1286
>
>
> regards,
> Hamish
>
>
>
>
>
> _______________________________________________
> Liblas-devel mailing list
> Liblas-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/liblas-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/liblas-devel/attachments/20090422/bba8e1e9/attachment-0001.html


More information about the Liblas-devel mailing list