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

[Michael Barton]

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 
 > wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20081007/a76baf72/attachment.html