[GRASS-dev] v.in.lidar: store return or class as category

[Moritz Lennert]

On 29/09/15 19:49, Vaclav Petras wrote:
>
> On Tue, Sep 29, 2015 at 9:52 AM, Moritz Lennert
> <mlennert at club.worldonline.be <mailto:mlennert at club.worldonline.be>> wrote:
>
>     On 29/09/15 15:26, Newcomb, Doug wrote:
>
>         As an example, the new North Carolina data set ( 2014 +) , the LiDAR
>         classes above 12 are being used for roads, (13) and bridges (14) .
>
>
>     Maybe if we go for 30 or 31 we have less chance to step on other
>     classifications' toes. But the risk remains, so maybe the idea of
>     regrouping 0 and 1 as 1 is less error prone...
>
>
> 0+1 > 1 sounds like a good idea and reasonable default.
>
> I will actually this again with color.
> It seems reasonable to store the
> color for vector points (if there is a lot of them) as categories.

Is writing a color table (à la v.colors) so inefficient that you want to 
put the colors in categories.

I have the feeling we are starting to abuse the concept of categories, 
here, just because attribute management is slow. If that is the case, 
maybe we should rather look at improving performance of that ?

> But
> of course the range is 0-255, we can surely move it to 1-256

Why would you want to ?

> but it
> little bit inconsistent with everything else in world regarding the RGB
> color handling.

RGB is 0-255 for each of the three colors, non ?


Moritz