[GRASS-dev] porting r.in.wms to python

[Glynn Clements]

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.

> 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.

> > > >     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.

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.

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).

> > 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.

-- 
Glynn Clements <glynn at gclements.plus.com>