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

[Vaclav Petras]

On Sat, Sep 26, 2015 at 8:40 PM, Vaclav Petras <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? If
0 should be changed in case of ASPRS/lidar class 0, then to what?

[1] https://grass.osgeo.org/programming7/vectorlib.html#vlibCategoriesLayers


>
> Please note that this change lacks test and documentation. The same still
> applies to two recent changes in r.in.lidar and v.in.lidar.
>
> Vaclav
>
>
> v.in.lidar: store return and class as cats or store no cats
> https://trac.osgeo.org/grass/changeset/66343
>
> v.in.lidar: use unsigned long long for counting point counts
> https://trac.osgeo.org/grass/changeset/66255
>
> v.in.lidar: decimation (skip, preserve, offset, limit)
> https://lists.osgeo.org/pipermail/grass-dev/2015-September/076275.html
>
> r.in.lidar: height above ground
> https://lists.osgeo.org/pipermail/grass-dev/2015-September/076147.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20150928/e1666e82/attachment.html>