[GRASS-dev] [GRASS GIS] #934: d.vect with z height colors uses a random polygon point for height - patch to fix attached

[GRASS GIS]

#934: d.vect with z height colors uses a random polygon point for height - patch
to fix attached
-----------------------------------+----------------------------------------
 Reporter:  jarim                  |       Owner:  grass-dev at lists.osgeo.org
     Type:  enhancement            |      Status:  new                      
 Priority:  normal                 |   Milestone:  7.0.0                    
Component:  Display                |     Version:  svn-trunk                
 Keywords:  z height color zcolor  |    Platform:  All                      
      Cpu:  x86-32                 |  
-----------------------------------+----------------------------------------
 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.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/934>
GRASS GIS <http://grass.osgeo.org>