From mateusz at loskot.net Fri Jul 4 09:16:00 2008 From: mateusz at loskot.net (Mateusz Loskot) Date: Fri Jul 4 09:16:16 2008 Subject: [Liblas-devel] Re: lasmerge in liblas In-Reply-To: <3054411AF4728548AD6D7137190D56B30C4824@admin1.aeromap.com> References: <3054411AF4728548AD6D7137190D56B30C4824@admin1.aeromap.com> Message-ID: On Jun 27, 2008, at 7:37 PM, Gennady Khokhorin wrote: > Hello, Mateusz. > Have couple questions kind of about library design. > > Did receive you liblas Beta 1 announce from one of my college: > http://lidarbb.cr.usgs.gov/index.php?showtopic=3700&pid=4622&st=0&#entry4622 Hi Gennady, I'm glad to hear. > It is a great news that las is finally linked to GDAL. I'm using a lot > of GDAL vector, raster functionality building stand-along apps. Yes, libLAS can link to GDAL but it's optional functionality. So, those who are not interested in using GDAL and OGR features are not required to link against GDAL binaries. > So, as far as liblas is part of GDAL what the purpose of lasmerge > routine? Looks like a small misunderstanding. libLAS is not a part of GDAL, but a standalone library + set of utilities. libLAS can use GDAL as a client, means you can link libLAS against GDAL binaries to be able to use some of GDAL features, but this is optional. > Should it be part of GDAL syntax like "ogr2ogr -append.." ? According to the above, I'd answer: no, it shouldn't. lasmerge is a tool specialized in processing ASPRS LAS data. For merging LAS files, it is not necessary to involve translation between LAS data model and GDAL data model. IMHO, it would be unnecessary overhead. > In the past I did create driver for las (ASPRS), bin (TerraScan), cmp > (Optech), xyz (text) lidar data formats with multiple operations: > logical (merge, split), spatial > (shift, reproject, VLR georeference), extract data (by time, by > prizm). Sounds very interesting. > I'm wonder what are team's plans to extend liblas to create such > features? Or it will be up to GDAL? > As I can tell, we are going to complement current functionality of the libLAS library and utilities with new features like the operations you're listing above, if not implemented yet. The libLAS is a standalone project, not a part of GDAL, so its roadmap is up to us. If you would be willing to contribute some features or share implementation of the features listed above, as an improvement to the current state of libLAS, you're strongly welcome. Greetings -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.hobu.net/pipermail/liblas-devel/attachments/20080704/0d36e7ca/attachment.html