On Feb 18, 2010, at 2:44 PM, Mateusz Loskot wrote: > It usually is and unnecessary abstraction and it does solve very little if > anything (I'm not speaking of applications like gdalinfo, one sink for all > which are rare though widely used cases). >
I can see this point of view, though I would argue that much of GDAL's success other than Frank's unstoppable force is the ability for lazy people to make great strides quickly with it. GDALOpen, for its faults, is one of those things that enables the laziness. It's not only gdalinfo that it enables, it also allows the meta-processing of VRTs to happen without much friction. For example, Perry shows some advantages of enabling this laziness today <http://www.perrygeo.net/wordpress/?p=141>. In 80% of the cases, the 80% solution is sufficient ;) (oh, wait...) > And LAS mnemonic will become redundant and confusing. I agree, and that's one of the reasons I brought it to the list. There's some balance to be struck between keeping libLAS conceptually clean (I would note that LAS 1.3 tosses that idea totally out the window, btw), and carrying forward the momentum the existing effort has maintained. The mailing list has 60 members right now, and it's taken two years to get to that point. Starting projects from scratch is a lot of very hard work. > To keep my usually long stories short, I would leave libLAS alone > as it is and develop new library with a proper and extensible > data model and bunch of drivers. libLAS would be used by LAS driver. It is becoming quite clear to me there is a strong need for a GDAL- or OGR-like library for the various point cloud data formats that are out there. The ASPRS LAS standard was an attempt to try to get the community to agree on a common set of idioms, and while partially successful, varying implementations and noise on the periphery make true interoperability difficult -- especially for a software developer just looking to add the ability to operate with these kinds of data to their software. LAS hasn't lessened the number of formats at all, and I would argue that just about every LiDAR hardware vendor and the majority of the LiDAR software vendors have their own formats for these kind of data. But these data do not belong in GDAL or in OGR. They are not just OGC Simple Feature points, and they are not merely interpolated floating point arrays. Anything beyond that in either of those libraries is going to be nearly impossible to implement. If there were such a library -- a GDAL for point cloud data -- and it were called something other that libLAS, would they come? Howard _______________________________________________ Liblas-devel mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/liblas-devel
