d.vect with z height colors uses a random polygon point for height - patch to fix attached
When you use d.vect with -z and zcolor= options the polygons are colored based on a table of heights and colors. Looking at the source code in display/d.vect/area.c the point (z coordinate) that is used for the color lookup is taken from the first vertex of the area. From the user's point of view this can appear as a random point, especially if the areas are triangles that are created by v.delaunay. For delaunay triangles using a single vertex does not make sense if all three points are at different heights as can often be the case for a TIN model. The current implementation would work in the restricted case that all area points are at the same height.
A "good enough" and quick solution is to use a midpoint of the area bounding box top and bottom as the z coordinate for determining the color. A patch that implements this is attached. The centroid could be the optimal choice for z coordinate.
The patch makes use of the bounding box of the area that is already calculated earlier in the function. The original implementation of this z height color functionality has unfortunately reused the same variable name "box" for map bounding box so I renamed that one to "map_box" to make the area bounding box available.
I have only been able to do very limited testing on Linux but this patch seems to fix the issue that I had with my dataset.
Change History
(11)
| Keywords: |
d.vect added
|
| Resolution: |
→ fixed
|
| Status: |
new → closed
|
patch