A few comments below.
On Oct 6, 2008, at 1:49 AM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]
> wrote:
Date: Mon, 6 Oct 2008 06:34:41 +0100
From: Glynn Clements <[EMAIL PROTECTED]>
Subject: Re: [GRASS-dev] porting r.in.wms to python
To: [EMAIL PROTECTED]
Cc: grass-dev <grass-dev@lists.osgeo.org>
Message-ID: <[EMAIL PROTECTED]>
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
more easily.
> > 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 >
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).
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
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?
The TclTk GUI is set to be abandoned in GRASS 7. It will continue to
live in the GRASS 6 series.
Michael
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
