<div dir="ltr">As an example, the new North Carolina data set ( 2014 +) , the LiDAR classes above 12 are being used for roads, (13) and bridges (14) .  I have attached a two page flyer on the current NC project as a pdf.  If it doesn't come through on the email list, let me know and I will email it directly to you<div><br></div><div>Doug</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 29, 2015 at 5:07 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 28/09/15 22:02, Vaclav Petras wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
On Sat, Sep 26, 2015 at 8:40 PM, Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a><br></span><span class="">
<mailto:<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a>>> wrote:<br>
<br>
    Dear all,<br>
<br>
    in r66343 I've added the option to store return or class as<br>
    category. This is much faster than storing them as attributes. Also,<br>
    the further processing will be faster supposing that the subsequent<br>
    workflow can use categories in the same way as attributes.<br>
<br>
    Return and class can be stored at the same time, each in its own<br>
    layer, otherwise they would get mixed. There is no protection<br>
    against specifying same layer for all, perhaps there should be.<br>
<br>
<br>
Another thing which needs further consideration is category number when<br>
class number is 0 (ASPRS: Created, never classified). Is 0 allowed for<br>
category? Library documentation says no [1] but then it says yes for OGR<br>
layers (and I suppose PostGIS as well). So how hard is the requirement?<br>
</span></blockquote>
<br>
I would plead for you to respect the library documentation, i.e. no 0 cats.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If 0 should be changed in case of ASPRS/lidar class 0, then to what?<br>
</blockquote>
<br></span>
In the current specifications anything over 12 is "Reserved for ASPRS Definition". I don't know what this entails, but maybe we can use one of these values.<br>
<br>
On the other hand, 0 means "we've never tried to classify", while 1 means "we tried to classify, but were not able to". I'm not sure if the difference between these two is really important and so maybe we could just regroup all 0's and 1's into class 1 ?<br>
<br>
Moritz<br>
_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><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.</div></div>
</div>