<div dir="ltr">v.lidar.mcc seems to be running fine without attributes or topology.  Not sure why I thought it needed a regular point vector layer.  Sorry for the noise.<div><br></div><div>Doug</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 22, 2016 at 11:27 AM, Moritz Lennert <span dir="ltr"><<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 22/07/16 16:05, Newcomb, Doug wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Folks,<br>
My goal is to import a LiDAR point cloud from an LAS file with 152<br>
million points.  I would like to use v.lidar.mcc to extract bare earth<br>
points from the point cloud for generating a DEM  However, v.lidar.mcc<br>
requires that the point layer have an attribute table<br>
</blockquote>
<br></span>
Are you sure ? The example in the v.lidar.mcc man page says:<br>
<br>
v.in.lidar -tr input=points.las output=points<br>
v.lidar.mcc points ground=ground_points nonground=non_ground_points<br>
<br>
the -t in v.in.lidar means "Do not create attribute table".<span class=""><br>
<br>
> rather than just<br>
> the raw x,y,z points without topography.<br>
<br></span>
Do you mean topology ?<br>
<br>
Attribute table and topology are two seperate issues.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So using v.in.lidar, I am importing  the lidar points as normal points,<br>
and the memory usage is steadily climbing.  Less than 1/4 of the points<br>
are imported and memory usage is at 5GB . This on a Windows 7 64 bit<br>
system with GRASS 7.2 svn<br>
<br>
I'm suspecting this is not the expected behavior.<br>
</blockquote>
<br></span>
I would say that it is expected. YMMMV with different database backends, but attribute handling can be memory-heavy.<br>
<br>
What does v.in.lidar -t give you ?<br>
<br>
If some attribute really need to be conserver, maybe this a good case to test Vaclav's additions to v.in.lidar, storing attributes as cat values, instead of attributes in a table:<br>
<br>
<a href="https://lists.osgeo.org/pipermail/grass-dev/2015-September/076490.html" rel="noreferrer" target="_blank">https://lists.osgeo.org/pipermail/grass-dev/2015-September/076490.html</a><br>
<a href="https://trac.osgeo.org/grass/changeset/66343" rel="noreferrer" target="_blank">https://trac.osgeo.org/grass/changeset/66343</a><span class="HOEnZb"><font color="#888888"><br>
<br>
Moritz<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div>Doug Newcomb</div><div>USFWS</div><div>Raleigh, NC</div><div>919-856-4520 ext. 14 <a href="mailto:doug_newcomb@fws.gov" target="_blank">doug_newcomb@fws.gov</a></div><div>---------------------------------------------------------------------------------------------------------</div><div>The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior.   Life is too short for undocumented, proprietary data formats. As a federal employee, my email may be subject to FOIA request.</div></div></div></div>
</div>