Opened 15 years ago
Last modified 11 years ago
#802 new defect
v.vol.rst reverts mask coordinates
Reported by: | helena | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 6.5.0 |
Component: | Raster3D | Version: | svn-develbranch6 |
Keywords: | mask, 3D interpolation | Cc: | |
CPU: | x86-64 | Platform: | All |
Description
v.vol.rst does not apply mask correctly, for example, mask that is NW-SE diagonal strip is applied as NE-SW diagonal strip, I need to look at the code to find what exactly is happening
Helena
Change History (3)
comment:1 by , 15 years ago
comment:2 by , 13 years ago
Platform: | Linux → All |
---|
Both 2D and 3D masks have problems.
v.vol.rst has option maskmap to define a 2D raster as a mask for volume. It appears that when output is a 2D raster (e.g. example from grassbook for precipitation with influence of topography) the result is correct. However, for the 3D raster output the result is not written correctly - it looks like wrong order of rows or columns discussed by Soeren recently.
So if v.vol.rst is run with the mask shown in pink in the linked image, the result when converted to 2D series is like the yellow strip and the isosurfaces are shown in the second image.
Mask and result in 2D
Masked isosurfaces
if a 2d MASK or 3d G3D_MASK is set, v.vol.rst finishes with segfault before writing the output. It finishes without segfault in GRASS7 but the mask is not applied.
Helena
comment:3 by , 11 years ago
Component: | Default → Raster3D |
---|
Is this still an issue in 6.4? If yes, any changeset from G7 which could be backported?
Is this the 2D or 3D mask you are speaking about?
Markus