On Thu, 2010-07-01 at 08:16 -0500, Howard Butler wrote: > On Jul 1, 2010, at 5:13 AM, Mike Grant wrote: > > > > 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. > > > 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 :)
It convinces me more to the idea of separating low-level I/O from LAS data source to very basic, so called, raw data from its interpretation which belongs to higher level of processing. C++ types for the raw point data should be easy to implement and will remain fairly stable over time, I imagine. The interpretation/schema engine will be more sophisticated and it could be defined in form of extensible list of properties: type + name + value. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org _______________________________________________ Liblas-devel mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/liblas-devel
