<div dir="ltr"><div><div>[Was: v.in.lidar: store return or class as category]<br></div><br>Changing the subject as this is more general than just v.in.lidar.</div><br><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 30, 2015 at 4:20 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On 29/09/15 19:49, Vaclav Petras wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
<br>
On Tue, Sep 29, 2015 at 9:52 AM, Moritz Lennert<br></span><span class="">
<<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a> <mailto:<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>>> wrote:<br>
<br>
    On 29/09/15 15:26, Newcomb, Doug wrote:<br>
<br>
        As an example, the new North Carolina data set ( 2014 +) , the LiDAR<br>
        classes above 12 are being used for roads, (13) and bridges (14) .<br>
<br>
<br>
    Maybe if we go for 30 or 31 we have less chance to step on other<br>
    classifications' toes. But the risk remains, so maybe the idea of<br>
    regrouping 0 and 1 as 1 is less error prone...<br>
<br>
<br>
0+1 > 1 sounds like a good idea and reasonable default.<br>
<br>
I will actually this again with color.<br>
It seems reasonable to store the<br>
color for vector points (if there is a lot of them) as categories.<br>
</span></blockquote>
<br>
Is writing a color table (à la v.colors) so inefficient that you want to put the colors in categories.<br></blockquote><div><br></div><div>I did no benchmark, but I suppose that setting for case of lidar data with colors (lots of point and each point has its own RGB) text color table won't cut it unless we employ some reduction as in case of r.composite [1].<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I have the feeling we are starting to abuse the concept of categories, here,</blockquote><div><br></div><div>Maybe, but maybe not. I don't think that we've defined how layers and categories should be used. Using categories in layer 1 as user-visible feature IDs and categories in layer 2 as class(ification) is an obvious use case, but I don't think we should limit ourselves to this one. After realizing what information I can potential store as layers and categories, I think that layers and categories are heavily underused. The system has a lot of potential and there is just few cases when it is used fully (e.g., with temporal framework one can store different positions of a point in one vector map but mark the individual time steps using layers).<br><br></div><div>Another point of view is that categories used as IDs are useless for lidar (since you can't work with the attribute table anyway) and there might not be enough of them (hitting limit of 32bit signed integer). So, the solution is to not use categories at all (and loose all info about the point except for xyz and possible processing), or to use categories for something else. Return number and class are low hanging fruit here. RGB requires more support but it seems feasible to me.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">just because attribute management is slow. If that is the case, maybe we should rather look at improving performance of that ?</blockquote><div><br></div><div>That's right it is slow. For the lidar case prohibitively slow. I don't see an easy way how it could be faster. Different attribute storage backends such as PostgreSQL may work better but still you have two separated storages for coordinates and attributes which means two searches (that's a naive view but I think it works). Then perhaps alternative drivers are the way. PostGIS might be but perhaps a new vector driver such as PDAL might be more appropriate (and is advantageous also for other reasons). However, all this requires significant development effort (new driver, optimization) or increases demand for user infrastructure (running a db server).<br><br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But<br>
of course the range is 0-255, we can surely move it to 1-256<br>
</blockquote>
<br></span>
Why would you want to ?</blockquote><div> <br>
</div><div>If we want to store RGB as category and we don't want to to use category 0, we need to store 0  (e.g., white, 0:0:0) somehow. Adding 1 to all color values solves the issue as long as we subtract them when reading them for the actual rendering.<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"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
but it<br>
little bit inconsistent with everything else in world regarding the RGB<br>
color handling.<br>
</blockquote>
<br></span>
RGB is 0-255 for each of the three colors, non ?</blockquote><div><br></div><div>Yes. 256 numbers for each color in three layers. So you would specify (e.g. in d.vect):<br><br></div><div>...red_layer=1 green_layer=2 blue_layer=3...</div><div><br></div><div>Other option is to combine RGB to one integer (using bit shifts), so it would be stored as one category, so<br><br></div><div>...rgb_layer=1...<br></div><div><br></div><div>The need to shift from category 0 is in both cases. So we would always subtract or add one before/after writing the category. Advanced users may appreciate a flag to store the GRASS-invalid but common/expected range of values.<br></div><div><br>[1] <a href="https://grass.osgeo.org/grass71/manuals/r.composite.html">https://grass.osgeo.org/grass71/manuals/r.composite.html</a><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><font color="#888888"><br>
<br>
<br>
Moritz<br>
</font></span></blockquote></div><br></div></div></div>