Opened 4 years ago

Closed 3 years ago

#3034 closed task (fixed)

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

Reported by: wenzeslaus Owned by: wenzeslaus
Priority: blocker Milestone: 7.2.0
Component: Vector Version: svn-trunk
Keywords: v.in.lidar, categories, returns, classes, interface Cc:
CPU: Unspecified Platform: Unspecified

Description

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:

Change History (6)

comment:1 Changed 4 years ago by wenzeslaus

Summary: Changing the layer options ib .vin.lidar to flag or flagsChange the layer options in v.in.lidar to flag or flags with predefined categories

comment:2 Changed 4 years ago by wenzeslaus

Owner: changed from grass-dev@… to wenzeslaus

comment:3 Changed 4 years ago by wenzeslaus

Status: newassigned

comment:4 Changed 3 years ago by 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.

comment:5 Changed 3 years ago by martinl

Are you planning any backports to relbr72?

comment:6 Changed 3 years ago by wenzeslaus

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.