Thanks for the information Glynn. See below for a question or two.
On Oct 7, 2008, at 4:24 PM, Glynn Clements wrote:
Michael Barton wrote:
d.rast.leg (d.frame)
(any thoughts Markus?)
perhaps replaced by some wxGUI "load cartographic template" tool?
(users could contribute their own etc..)
Note that it is possible to set a drawing frame by setting
GRASS_FRAME=t,b,l,r (see d.polar for an example).
Actually, this should be salvageable without too much effort. I just
saw the d.frame calls and didn't look much further.
Could this be wrapped into ps.map?
Well, I'm planning on making ps.map obsolete. It's just a matter of
determining what functionality is only available via ps.map and adding
or extending d.* commands to provide that functionality.
I'd guess the main things not included in d.* commands would be layout
information, such as how to position more than one map on a page, how
to position a scale or legend--especially if it is supposed to be
located off the map display area--, and other similar things.
If I remember, this simply puts a
raster on the screen in one frame, a title in another, and a legend
in
a third. Doing this in the wxPython canvas is doable, but I wonder if
a script is the best way to go with it. That is, building it into a
wxPython class in the display module seems to make more sense. An
alternative is to have a script combine a raster, title, and legend
in
an output graphic file (png, pdf, or something). This could be done
more easily.
FWIW, I've converted d.rast.leg to Python as described above.
A nice shortcut to raster output.
i.spectral (d.mon, d.where)
It would be very easy to add a coord=x,y[,x2,y2,...] option to feed
r.what instead of using d.where. The d.mon check is just to ensure
that d.where will work.
That sounds simple enough.
More work would be to replace gnuplot with d.graph or whatever,
like
is done for d.polar.
Is d.linegraph suitable?
There is a simple graphing module that comes with wxPython that is
much more sophisticated than d.linegraph--which still assumes an
xterm
(although it can output to a graphic file I suppose).
d.linegraph doesn't require an xmon.
It seems originally designed with an xmon in mind, but with your
changes to display architecture, this is no longer important I guess.
AFAICT, d.linegraph can be used for i.spectral.
However, I
suggested that matplotlib might be quite suitable for this kind of
task. It is a free, pure Python library that can do very
sophisticated
graphing very easily. It can be 1) wrapped into the GUI display, 2)
set to create it's own simple display in a couple of GUI toolkits, or
2) set to output to a graphic file. It is scriptable. I submitted a
couple of test scripts to show how this might be accomplished.
We would need to determine how to make it respect the various
environment variables so that commands which use matplotlib can be
mixed with those which use the display/raster libraries.
Sorry, but I don't understand. It is an external library (like
gnuplot, but seems a bit easier to work with for me at least). It can
plot to graphic files or a display canvas it creates, OR it can be
included in the GUI (though this takes somewhat different programming
to make it plot to the GUI display canvas). It was fairly easy to
include this in scrips. But maybe you are thinking of using it in a
more sophisticated way than I am.
So far as "graphs" are concerned, I'd rather have a completely new
class of modules/scripts (e.g. st.*) which output structured data
rather than graphics. That way, the user would be able control the
display (scaling, tick intervals, log/linear scale, sybmology, ...)
without requiring each module to have a hundred options (or worse,
each module having some entirely arbitrary subset of the available
options).
This would be excellent. I don't have a feel for how much programming
effort this would take. If the development and maintenance effort can
be supported, it would be very good to have a GRASS native plotting
environment. This focuses on structured graphic output that is
directly targeted for GIS needs--without the additional baggage of
graph displays that would rarely or never be used.
So, r.reclass and r.recode each need a file= (G_OPT_F_INPUT) option.
I thought this was already done.
It is; I've removed the wrapper scripts.
Great. Thanks.
Michael
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
