On Feb 25, 2010, at 2:39 PM, Adrien Chauve wrote: > Hi there, > > > lidarformat (they even use libLAS :) ) is pretty much exactly the direction > > I'd like to go except 1) LGPL instead of BSD and 2) source code layout. > What do you mean by "code layout" ?
My layout complaint would be containing headers with the source code instead of as a separate ./include directory. Oh, and tabs instead of spaces :P > > > Ok, I'm not so concerned about license at all as long as there is a > > collaborative project behind it with some weight. I don't know if > > lidarformat (bad name IMO) has that yet. > Actually there is not a strong collaborative project behind lidarformat, and > lidarformat *is* a poor name that I would like to change. Is changing the license of lidarformat to Boost or BSD/MIT something you could consider? I then think renaming it to something like liblidar and standing up project infrastructure (Trac/Wiki/hg) like liblas.org would give it some legs, especially because I strongly need something like this to exist above libLAS. I would expect to put some significant time into it to provide format drivers and a few transformation methods. > > Lidarformat is designed to handle point clouds as vector<Point> where Point > is a data structure known only at runtime. This structure is described in an > xml file (here is an example). I would be curious if there are already some existing standards for something like this. We're really talking about a DMBS-style "table description". I proposed something quite similar to yours <http://lists.osgeo.org/pipermail/liblas-devel/2010-February/000752.html>, but given the option, I would take up yours and extend it as needed. Do you think your lidar description schema has much traction yet? > A few templates are used to have almost the same performances as if the point > cloud was implemented as a real vector, but some parts still need to be > refractored (especially the iterators should be based on boost iterator > facade instead of being hand-coded). > Of course LAS is one of the format that should be supported by the library, > but it is currently broken. > > Is that what you have in mind for liblas ? > Well, for "more than liblas", but yes. On a related note, Boost is going to become a dependency for the next release of libLAS to provide multi-platform support for 64bit stream seeks and its other iostreams. This will open up possibilities for things like boost iterators, etc as well (don't know that they would be implemented in the next immediate release, but we'd take a patch) > Actually lidarformat is the base of another project dedicated to > full-waveform lidar data management and visualization (Fullanalyze), but the > fullwave format is still a draft mainly adapted to Riegl data. So it's still > a part of the FullAnalyze project and is not available as a standalone > library. I don't know if it would fit with Leica data and LAS 1.3. It is my understanding that Riegl data maps very poorly to the Leica-style LAS 1.3. But yes, I think the open source market needs something that is more than LAS but less than a full-fledged application to allow developers to easily work with lidar data (in various formats with various commonly defined transformation and processing steps). lidarformat looks to be a significant start at that effort. _______________________________________________ Liblas-devel mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/liblas-devel
