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 <[email protected]> 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/liblas-devel >
_______________________________________________ Liblas-devel mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/liblas-devel
