[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