[gdal-dev] LAS support

Even Rouault even.rouault at mines-paris.org
Fri Nov 29 10:39:18 PST 2013


Le vendredi 29 novembre 2013 18:35:28, Rui L. Pires a écrit :
> On 29 November 2013 11:44, Mateusz Loskot <mateusz at loskot.net> wrote:
> > On 29 November 2013 10:32, Rui L. Pires <rlpires at gmail.com> wrote:
> > > I was approaching this issue and particularly OGR as a solution for
> > > data conversion and reduction. I am quite fond of the functionality
> > > OGRLayer makes possible in a transparent way, such as reprojection and
> > > spatial querying.
> > 
> > Those are valid use cases of course and I don't argue here.
> > Just, since OGR is an abstraction layer and point clouds are enormous,
> > I wouldn't expect high performance.
> > That's why, IMHO, point clouds require dedicated toolkits (PDAL, PCL).
> 
> Hi Mateusz,
> 
> I understand your point regarding performance but I consider that to be a
> driver issue. My point is functionality before speed.
> 
> Perhaps, you can try las2ogr to see how OGR in general will work for your
> 
> > uses.
> > Besides, writing OGR driver with libLAS (or PDAL) should be feasible.
> 
> Indeed it is feasible. It's running fine here! ;-)

I'm not versed in lidar or point clouds to know if it is really relevant, but 
it is true that OGR has drivers for stuff that aren't strictly vector formats.  
And as las2ogr exists, I also imagine that an OGR driver should be doable.
So it would not be completely out of topic to have a OGR driver based on 
libLAS or PDAL (the question is : should it be based on libLAS or PDAL ? Any 
opinion on this ?) if people find it usefull (and this is a matter that comes 
back regularly).

A potential problem is that libLAS and PDAL have GDAL as a build dependency, 
so a OGR driver would need to be compiled as a plugin (same as GRASS plugin 
for example).

Even

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html


More information about the gdal-dev mailing list