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.
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
On Sat, Sep 26, 2015 at 8:40 PM, Vaclav Petras <wenzeslaus@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
On 28/09/15 22:02, Vaclav Petras wrote:
On Sat, Sep 26, 2015 at 8:40 PM, Vaclav Petras <wenzeslaus@gmail.com
<mailto:wenzeslaus@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
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
Doug
(attachments)
LiDAR onepager 2015.pdf (420 KB)
···
On Tue, Sep 29, 2015 at 5:07 AM, Moritz Lennert <mlennert@club.worldonline.be> wrote:
On 28/09/15 22:02, Vaclav Petras wrote:
On Sat, Sep 26, 2015 at 8:40 PM, Vaclav Petras <wenzeslaus@gmail.com
mailto:[wenzeslaus@gmail.com](mailto:wenzeslaus@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
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
–
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb@fws.gov
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.
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...
Moritz
On Tue, Sep 29, 2015 at 9:52 AM, Moritz Lennert <
mlennert@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. But of
course the range is 0-255, we can surely move it to 1-256 but it little bit
inconsistent with everything else in world regarding the RGB color handling.
On 29/09/15 19:49, Vaclav Petras wrote:
On Tue, Sep 29, 2015 at 9:52 AM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@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