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

[Moritz Lennert]

On 28/09/15 22:02, Vaclav Petras wrote:
>
> On Sat, Sep 26, 2015 at 8:40 PM, Vaclav Petras <wenzeslaus at gmail.com
> <mailto:wenzeslaus at gmail.com>> wrote:
>
>     Dear all,
>
>     in r66343 I've added the option to store return or class as
>     category. This is much faster than storing them as attributes. Also,
>     the further processing will be faster supposing that the subsequent
>     workflow can use categories in the same way as attributes.
>
>     Return and class can be stored at the same time, each in its own
>     layer, otherwise they would get mixed. There is no protection
>     against specifying same layer for all, perhaps there should be.
>
>
> Another thing which needs further consideration is category number when
> class number is 0 (ASPRS: Created, never classified). Is 0 allowed for
> category? Library documentation says no [1] but then it says yes for OGR
> layers (and I suppose PostGIS as well). So how hard is the requirement?

I would plead for you to respect the library documentation, i.e. no 0 cats.

> If 0 should be changed in case of ASPRS/lidar class 0, then to what?

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.

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 ?

Moritz