<div>All,</div><div><br></div>I wrote some python to pipe las2txt to GRASS's r.in.xyz on using subprocess which is what most of the GRASS python scripts use. Its not very sophisticated at all but seems to work decently well however I suspect Howard's point about it not being much better than the text file approach is true. Its based on the GRASS LIDAR wiki page(<a href="http://grass.osgeo.org/wiki/LIDAR">http://grass.osgeo.org/wiki/LIDAR</a>): Heres an example:<div>
<br></div><div>from liblas import file, header </div><div>import subprocess as sub</div><div>import grass.script as grass</div><div><br></div><div><div>def run(cmd, **kwargs):</div><div> grass.run_command(cmd, quiet = True, **kwargs)</div>
<div><br></div><div>path='../data/las/ucd_01.las'</div><div>dbname='ucd_01.las'</div><div><div>h=file.File(path).header</div><div>run("g.region", e=h.max[0], w=h.min[0], s=h.min[1], n=h.max[1])</div>
<div>pts=sub.Popen('las2txt -i %s --parse xyz --delimiter "|" --keep-classes 2 --stdout'%path, shell=True, stdout=sub.PIPE)</div><div>mkInRast=grass.feed_command("r.in.xyz", input="-", output=dbname, method='mean')</div>
<div>mkInRast.stdin.write(pts.communicate()[0])</div><div>mkInRast.stdin.close()</div><div>mkInRast.wait()</div><div><br></div><div>#this stuff is based on the wiki page for interpolating/filtering the resulting GRASS dataset</div>
<div><br></div><div>run("r.to.vect", flags='z', input=dbname, output=dbname+'_pt', feature='point') </div><div>run("v.surf.rst", layer='0', input=dbname+'_pt', elev= dbname+'_rst')</div>
<div>run("g.remove", vect='%s_pt'%dbname)</div><div>run("g.remove", rast=dbname)</div></div><div><br></div><div>Best,</div><div><br></div><div>Peter</div><div><br></div><br><div class="gmail_quote">
On Fri, Mar 4, 2011 at 11:10 AM, Howard Butler <span dir="ltr"><<a href="mailto:hobu.inc@gmail.com">hobu.inc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Mar 4, 2011, at 12:24 PM, Stuart Edwards wrote:<br>
<br>
><br>
> On Mar 4, 2011, at 9:27 AM, Howard Butler wrote:<br>
><br>
>><br>
>> On Mar 4, 2011, at 8:29 AM, francesco wrote:<br>
>><br>
>>> I use GRASS quite a lot, but always thought that it would be slow on vector points. I know Brovelli and her team developed some modules, I'll check on that. Good idea to use LibLAS as "driver" to turn LAS to xyz.<br>
>><br>
>> It would be much, much, much faster if someone wrote some glue between libLAS and GRASS (proposed here quite a while ago, but still not done <<a href="http://lists.osgeo.org/pipermail/grass-dev/2008-May/037687.html" target="_blank">http://lists.osgeo.org/pipermail/grass-dev/2008-May/037687.html</a>>). I would guess it would be an order of magnitude faster to ingest data if you didn't have to go through text formats to do it.<br>
><br>
> This may be possible since Liblas has a las2ogr tool and GRASS uses ogr for vector input - seems there's an opportunity to script output from the former and pipe it as input to v.in.ogr ? Beyond my skills unfortunately ....<br>
<br>
</div>that's not really much better. What needs to happen is for someone to write some code in GRASS that utilizes libLAS directly. Surely a manpower/desire thing.<br>
<font color="#888888"><br>
Howard_______________________________________________<br>
</font><div><div></div><div class="h5">Liblas-devel mailing list<br>
<a href="mailto:Liblas-devel@lists.osgeo.org">Liblas-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/liblas-devel" target="_blank">http://lists.osgeo.org/mailman/listinfo/liblas-devel</a><br>
</div></div></blockquote></div><br></div>