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

[Glynn Clements]

Hamish wrote:

> > > I was planning on leaving those until last ;)
> > 
> > Well, I'm now planning on just leaving them, period ;)
> > 
> > Here's the current status on conversion of scripts to
> > Python:
> > 
> > The following scripts are disabled, and haven't been converted:
> > 
> > 	d.out.gpsdrive   (d.mon)
> 
> (me)
> like the very useful d.out.file module, it dumps current (composed) map
> display to the PNG driver via d.save. I suppose replacing this will
> be a clone/modification of how d.out.file's functionality has been
> replicated.

IOW, it needs to be built into the GUI; now that monitors no longer
exist, nothing else has any notion of a "current" map.

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

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

> > These:
> > 	r.in.wms/r.in.wms
> > 	r.tileset/r.tileset
> 
> I think it is ok for the replacement version to depend on GDAL > 1.5.0.
> A first step will be adding XML+GDAL option to the bash/sh version
> for testing of that method.

It might be simpler to just start from scratch in Python.

> > 	v.in.gpsbabel/v.in.gpsbabel
> > 	v.in.garmin/v.in.garmin
> 
> Certainly v.in.gpsbabel should survive in some form. v.in.garmin is
> useful as the gpsbabel garmin filter does not pass through all fields.
>
> the XML stuff in v.in.gpsbabel is in desperate need of a python
> replacement, otherwise it shouldn't be /too/ different from v.in.mapgen.

Right. v.in.mapgen was another one that I was going to leave, but I
ended up downloading some sample files. That made it much easier to
see what the code was trying to do.

> > are too complex to replace using "rote" conversion (i.e. simply
> > replacing each chunk of code with equivalent Python code).
> 
> > The above scripts really need to be rewritten by someone
> > who understands the overall purpose of the script.
> 
> For v.in.gps I guess that means me, but my python+xml is rather weak.

The Python documentation has an example at:

http://docs.python.org/library/xml.dom.minidom.html

Or I can write the code to parse the XML if you can explain the
overall structure. It's just that trying to deduce the data structure
from a sequence of grep/head/tail/cut commands is rather mind-numbing.

> For a Python version r.in.wms, I defer the larger project to someone
> else, but can try to add GDAL support to the existing sh/bash version
> to demonstrate/verify the method.

That probably isn't much help. It would probably be more useful to
simply describe the process and provide some example URLs. I find
English much easier to read than bash/grep/head/tail/cut/awk/sed.

> [...]
> etc/gui/scripts/d.colors.sh
> etc/gui/scripts/d.path.sh
> etc/gui/scripts/r.colors.rules
> etc/gui/scripts/r.reclass.file
> etc/gui/scripts/r.reclass.rules
> etc/gui/scripts/r.recode.file
> etc/gui/scripts/r.recode.rules
> 
> these are all there as wrapper code between the GUI and command line
> modules, usually WRT piping info from stdin. All should be replaced by
> integrated wxGUI wizards not simply python scripts AFAICT.

Right. The various *.rules scripts plus d.colors.sh invoke xterm,
while the *.file versions just redirect stdin from a file (to
compensate for the lack of a file= option).

So, r.reclass and r.recode each need a file= (G_OPT_F_INPUT) option.

d.path.sh combines d.vect and d.path. The d.vect step was necessary
when d.path used the mouse to obtain the coordinates, so that the user
could see what they were supposed to be clicking on. That's no longer
applicable.

> etc/gui/scripts/r.support.sh  was partially needed because
> 1) non-interactive version did not in the past support all interactive
> functionality, and
> 2) interactive version weirdly exits prematurely when called directly
> from Tcl/Tk.

More generally, is there any intention to fix up gis.m with regard to
the various changes in 7.0, or are we going to abandon it and rely
upon wxgui instead?

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