[GRASS-dev] porting r.in.wms to python
michael.barton at asu.edu
Tue Oct 7 13:50:13 EDT 2008
A few comments below.
On Oct 6, 2008, at 1:49 AM, <grass-dev-request at lists.osgeo.org> <grass-dev-request at lists.osgeo.org
> Date: Mon, 6 Oct 2008 06:34:41 +0100
> From: Glynn Clements <glynn at gclements.plus.com>
> Subject: Re: [GRASS-dev] porting r.in.wms to python
> To: hamish_b at yahoo.com
> Cc: grass-dev <grass-dev at lists.osgeo.org>
> Message-ID: <18665.41841.122863.646844 at cerise.gclements.plus.com>
> Content-Type: text/plain; charset=us-ascii
> 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.
It already exists in the GUI. It exists in the TclTk GUI too. If
additional output formats are needed they can be added.
> > > 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? 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
> > > 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). 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.
> > > These:
> > > r.in.wms/r.in.wms
> > > r.tileset/r.tileset
> > I think it is ok for the replacement version to depend on GDAL >
> > 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
> > the XML stuff in v.in.gpsbabel is in desperate need of a python
> > replacement, otherwise it shouldn't be /too/ different from
> 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
> The Python documentation has an example at:
> 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
> > 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).
These are unneeded I think.
> So, r.reclass and r.recode each need a file= (G_OPT_F_INPUT) option.
I thought this was already done.
> 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
> > etc/gui/scripts/r.support.sh was partially needed because
> > 1) non-interactive version did not in the past support all
> > functionality, and
> > 2) interactive version weirdly exits prematurely when called
> > 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?
The TclTk GUI is set to be abandoned in GRASS 7. It will continue to
live in the GRASS 6 series.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the grass-dev