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

[Michael Barton]

Thanks for the information Glynn. See below for a question or two.
On Oct 7, 2008, at 4:24 PM, Glynn Clements wrote:

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

I'd guess the main things not included in d.* commands would be layout  
information, such as how to position more than one map on a page, how  
to position a scale or legend--especially if it is supposed to be  
located off the map display area--, and other similar things.

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

A nice shortcut to raster output.

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

It seems originally designed with an xmon in mind, but with your  
changes to display architecture, this is no longer important I guess.

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

Sorry, but I don't understand. It is an external library (like  
gnuplot, but seems a bit easier to work with for me at least). It can  
plot to graphic files or a display canvas it creates, OR it can be  
included in the GUI (though this takes somewhat different programming  
to make it plot to the GUI display canvas). It was fairly easy to  
include this in scrips. But maybe you are thinking of using it in a  
more sophisticated way than I am.

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

This would be excellent. I don't have a feel for how much programming  
effort this would take. If the development and maintenance effort can  
be supported, it would be very good to have a GRASS native plotting  
environment. This focuses on structured graphic output that is  
directly targeted for GIS needs--without the additional baggage of  
graph displays that would rarely or never be used.


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

Great. Thanks.

Michael