Change the layer options in v.in.lidar to flag or flags with predefined categories

[wenzeslaus]

The current version of G7:v.in.lidar in trunk (7.1) has several parameters related to storing return, class and color for lidar points.

         id_layer   Layer number to store generated point ID as category
     return_layer   Layer number to store return number as category
  n_returns_layer   Layer number to store number of returns as category
      class_layer   Layer number to store class number as category
        rgb_layer   Layer number where RBG colors is stored as category
        red_layer   Layer number where red color is stored as category
      green_layer   Layer number where red color is stored as category
       blue_layer   Layer number where blue color is stored as category

However, this is too many parameters. It seems that it might be more advantageous to store all these in predefined layers which would be also expected by some other modules. User would use a flag or more flags to enable this behavior.

Interface will be decided here, so it is blocker for the next release (preferable its branching).

More discussion also here:

• ​https://lists.osgeo.org/pipermail/grass-dev/2015-September/076552.html

[wenzeslaus]

In the end, I decided to leave the layers there as they give most control: user can decide what to store and where. However, I reduced number of possible layers to minimum:

• id_layer: auto-generated ID - the classic cat(egory)
• return_layer: stores first/mid/last return information as 1/2/3
• class_layer: stores class (0 is merged into 1 - cat must be >1)
• rgb_layer: stores RGB as one number using bit-shift operators (1 is added to the result - cat must be >1)

We might need to add some in the future (I have near infra-red in mind).

The reduction and unification was done in r68469 for v.in.lidar, v.out.lidar and v.in.pdal. r68470 standardizes values stored in return_layer and r68472 ensures that cat is not 0. r68476 improves the behavior in command line and in GUI by adding -c flag which disables creating of unique category/ID for each point (there was similar flag before r68469 with slightly different meaning).

Some testing is need. We might need to somehow mark those as experimental to not make them stable part of API just yet. I don't remember any precedence for it, but it might be appropriate now.

[martinl]

Are you planning any backports to relbr72?

[wenzeslaus]

This is open because of marking that experimental and need for user testing. But I'm closing it because this is already in 72 code.