On Jul 1, 2010, at 5:13 AM, Mike Grant wrote: > On 30/06/10 22:04, Howard Butler wrote: >> * interpret its raw data *on-the-fly* for each fixed attribute call >> (GetIntensity, GetX, GetClassification, etc) we currently support. > > The only thing that slightly scares me is that doing everything on the > fly might be a lot slower for (probably) the most common use case of > trawling through every point in a file. Any idea how much slower it'll be?
It *should* be exactly the same for this use case (reading through the file one point at a time to fetch data a single time). The point is interpreted as it is read currently, and you're given a reference to it (if the point is to be reprojected, a copy is made). *Subsequent* calls to GetIntensity on the same point (bad example actually, as there's no transformation needed for GetIntensity ... GetX where we apply the scale and offset might be more appropriate to consider) would take on the computation hit. > > If it is slow, it might make sense to provide a bulk interpretation > method of some kind. Obviously one could take the raw array and > interpret it oneself, but that's the point of using a library. Yes, that's the balance to be maintained here. I want the easy use supported (ie, interpret the bytes for me and do most of the work), but there are cases where the custom usage is desired as well. One of the strongest cases for raw data access is rescaling the X, Y, Z data without additional quantization error from transforming back/through the scale and offset additional times (impossible with libLAS currently). Another strong case is the committee can keep adding crap and we can provide support for it without a lot of code changes (ideally, just providing an additional XML file that lays out the fields). This same mechanism would allow you to provide custom types as well, storing things like derivatives, 64 bit time values, etc :) Another thing to balance is not making liblas::Point too beefy. Maybe we're already too far down that road, I don't know. The proposal would definitely beef up liblas::Point, especially if we were to cache interpreted X, Y, Z in an effort to speed up subsequent calls to GetX, GetY, etc. Thanks for the feedback! Howard _______________________________________________ Liblas-devel mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/liblas-devel
