Opened 6 years ago

Closed 18 months ago

#2433 closed defect (fixed)

v.patch doesn't preserve 3D when input 3D points have not built topology

Reported by: annakrat Owned by: wenzeslaus
Priority: normal Milestone: 7.2.4
Component: Vector Version: svn-releasebranch70
Keywords: lidar, v.patch, topology, z-coordinates Cc:
CPU: Unspecified Platform: Unspecified

Description

When I import for example lidar data with v.in.lidar -t (do not build topology) and then patch them, the new vector is not 3D anymore. Is it really necessary to build topology of maps before passing them to v.patch? This is quite inconvenient in case of huge lidar data.

Change History (9)

comment:1 Changed 5 years ago by wenzeslaus

Keywords: z-coordinates added
Milestone: 7.0.07.1.0
Owner: changed from grass-dev@… to wenzeslaus

When I import for example lidar data with v.in.lidar -t (do not build topology) and then patch them, the new vector is not 3D anymore. Is it really necessary to build topology of maps before passing them to v.patch?

It is strange that that it worked at all without topology as the v.patch code required opening at level 2. From the history, I was not able to determine why exactly was the code done in this way but the topology/index/whatever (level 2) is now required for info if the vector map is 3D or not. Perhaps something changed in the library in the past since I had to put building of topology to v.lidar.mcc addon to make v.patch happy (but this is possibly unrelated).

Anyway, in r66822 I added two new flags, one for opening on level one, i.e. not requiring the topology, and the other for forcing reading of z coordinate since the library reports "without z" when on level 1 (as far as I tested that). This is the naming and the description (open for discussion):

  -n   Do not expect input with topology
        Applicable when input is points without topology
  -z   Expect z coordinate even when not using topology
        Applicable when input is points with z coordinate but without topology

Basic tests done for new and old functionality but no automated tests. Documentation is missing as well. Please help.

This is quite inconvenient in case of huge lidar data.

Lidar data and other point clouds can be now merged using (-b is now the standard flag for not building topology):

v.patch input=tile_1,tile_2,tile_3 output=points_all -nzb

comment:2 Changed 4 years ago by neteler

Milestone: 7.1.07.2.0

Milestone renamed

comment:3 Changed 4 years ago by wenzeslaus

It seems that -nzb could be reduced into one flag -c "work with point clouds" flag, but this wouldn't be applicable when you want to not build topology for the output for some other reason (-b). It is also not applicable when you are merging 2D inputs without topology (-n) because v.patch uses Vect_set_open_level, so user must provide a level. I'm not sure if there is a reason for it and whether there is some case I'm missing. According to what I tested, -z is needed when there is no topology because without it, you can't tell if Z is there. If somebody has some better insight, please advise.

comment:4 Changed 4 years ago by neteler

Milestone: 7.2.07.2.1

comment:5 Changed 3 years ago by martinl

Milestone: 7.2.17.2.2

comment:6 Changed 3 years ago by neteler

Milestone: 7.2.27.2.3

Ticket retargeted after milestone closed

comment:7 Changed 2 years ago by martinl

Milestone: 7.2.3

Ticket retargeted after milestone closed

comment:8 Changed 2 years ago by martinl

Milestone: 7.2.4

comment:9 Changed 18 months ago by annakrat

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.