<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 29 November 2013 11:44, Mateusz Loskot <span dir="ltr"><<a href="mailto:mateusz@loskot.net" target="_blank">mateusz@loskot.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On 29 November 2013 10:32, Rui L. Pires <<a href="mailto:rlpires@gmail.com">rlpires@gmail.com</a>> wrote:<br>

> I was approaching this issue and particularly OGR as a solution for data<br>
> conversion and reduction. I am quite fond of the functionality OGRLayer<br>
> makes possible in a transparent way, such as reprojection and spatial<br>
> querying.<br>
<br>
</div>Those are valid use cases of course and I don't argue here.<br>
Just, since OGR is an abstraction layer and point clouds are enormous,<br>
I wouldn't expect high performance.<br>
That's why, IMHO, point clouds require dedicated toolkits (PDAL, PCL).<br></blockquote><div> <br>Hi Mateusz,<br><br></div><div>I understand your point regarding performance but I consider that to be a driver issue. My point is functionality before speed.<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Perhaps, you can try las2ogr to see how OGR in general will work for your uses.<br>
Besides, writing OGR driver with libLAS (or PDAL) should be feasible.<br></blockquote><div><br></div><div>Indeed it is feasible. It's running fine here! ;-)<br><br></div><div>Regards,<br>Rui<br></div><div><br><br></div>
</div></div></div>