All, I have recently undertaken a significant effort to refactor the reader and writer internals of libLAS. The previous implementation used specific reader and writer code for each format (1.0, 1.1, 1.2, ...) and this made adding new versions a bit tedious. A bigger problem, however, was it wasn't really possible to add support for entirely new formats. The new code flips things around a bit into specific readers and writers for headers and points, and it adds two interfaces -- ReaderI and WriterI. A developer can subclass and provide them to libLAS to interact with their own formats. Of course, stuff will still be limited by the LAS abstraction, but wasn't that LAS's point -- commonality (ha!)?
A major impetus for this effort is to be able to provide abstract views to other LAS-like data formats using libLAS more transparently. My experience with GDAL's driver-based approach informs (though Mateusz might say infects :) my sensibilities here, and what I would like to do is mimic its approach but in a much more limited way. There are a number of data formats that are LAS-like that could fit well within this, including things like QFIT, TerraSolid .bin, a simplified Oracle Point Cloud driver, gzip/bzip/zip'd LAS, LizardTech's Lidar format, and ASCII-style ones like XYZ. I plan to build out LASDriver and implement drivers for the Oracle Point Cloud and TerraSolid .bin formats in the next months. Consider this your notice of the work that is going on, and your task to think about other formats you would like implemented in libLAS :) Also, if anyone has any concerns or comments about this idea, I would be excited to hear about them. Howard_______________________________________________ Liblas-devel mailing list Liblas-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/liblas-devel
