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
