[GRASS-dev] [GRASS GIS] #2143: d.legend: add option to output legend definition as text

GRASS GIS trac at osgeo.org
Fri Feb 7 18:08:34 PST 2014


#2143: d.legend: add option to output legend definition as text
-----------------------------------+----------------------------------------
 Reporter:  wenzeslaus             |       Owner:  grass-dev@…              
     Type:  enhancement            |      Status:  new                      
 Priority:  trivial                |   Milestone:  7.0.0                    
Component:  Display                |     Version:  svn-trunk                
 Keywords:  d.legend, text output  |    Platform:  All                      
      Cpu:  All                    |  
-----------------------------------+----------------------------------------

Comment(by hamish):

 Hi,

 see r.colors.out (which does most of you are asking for in this ticket I
 think) and the approach taken by various grass6 addon modules:
 r.colors.out_sld (Mapserver), r.colors.out_vtk (Paraview/VisIt), r.out.gmt
 (also creates the GMT color table), and r.out.gdal.

 .. or for something local/custom just parse the $MAPSET/colr/ file
 directly.

 I haven't looked at it in a while, but I imagine the HTML display driver
 might have some web-friendly code in it too?

 Do you have specific plans on how you'd use the output? or is this more a
 general idea?


 As the primary author of the current d.legend I'm not exactly enthusiastic
 about messing too much with what is already working well. It's a
 complicated monolith, and I'd appreciate anyone thinking about changing it
 to please contact me first for advice. (or the change will risk be dropped
 like the fontscale option soon will be)

 I could be sold on renaming it to d.rast.legend, renaming the d.rast.leg
 script something else, and coming up with a new separate d.vect.legend
 module to make display driver vector legends similar to what ps.map has.
 Some parts of the current d.legend could share library functions with
 d.vect.legend, but since much of it is just drawing rectangles and much of
 the rest is heuristics, I'm not sure how much is actually reusable.

 enhancements to d.vect in taking size, rotation, color, etc. from
 attribute columns has made much of the thematic legend code redundant
 AFAIK, so those can be simplified to a wrapper around d.vect and v.univar.

 The 747 cockpit approach of 'd.vect --help' is a big reason why I'd favour
 two separate d.rast.legend and d.vect.legend modules instead of combining
 two code objects into a common frontend. That distinction would be
 invisible to the GUI users and not overwhelming to the command line users.


 regards,
 Hamish

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2143#comment:1>
GRASS GIS <http://grass.osgeo.org>



More information about the grass-dev mailing list