[GRASS-dev] numeric-numpy-scipy for graphs?

[Paul Kelly]

On Sun, 22 Apr 2007, Michael Barton wrote:

> Thanks Hamish,
>
> In fact, we can do considerably more now with the wxPython (and TclTk)
> drawing commands to than is available in d.graph or d.linegraph, even with
> your nice enhancements.
>
> In the case of histogramming and profiling, it seems a better display to
> have them come up in a separate window (like is now the case with the TclTk
> profiling module) than have them rendered like a map in the main display
> (like we do now for d.histogram in the current TclTk GUI). Rendering maps is
> complex and it doesn't seem efficient to have to go through the same complex
> procedures to draw a histogram or profile that doesn't need to be drawn
> georeferenced.

Another thought - with the enhancements to the display architecture in 
progress/idea stage, it might actually be possible to produce better 
quality graphs for inclusion in reports/papers etc. using the existing 
display architecture. I'm thinking of the move towards PostScript as a 
display output format. I imagine with pop-up Windows in the GUI with 
histograms etc. you would be limited to printing the thing as a raster 
graphic at the same resolution as the screen? Not so good. Unless those 
new python modules you're looking at perhaps have an option to save as 
postscript (I mean proper line-graphics postscript) for printing. And of 
course if you use GRASS modules to produce the graphs then as Glynn says 
it is also possible to produce them from scripts, which is rather 
important. (Rather than having all this functionality tied up in the GUI 
and having to re-implement it if we change the GUI).

> For this reason, it seems better to do these kinds of analyses with the gui
> tools, using underlying GRASS modules like r.profile and r.stats.

I agree it "seemed" better/tidier/neater to me at first, but if we 
consider the display architecture is being enhanced beyond it's old 
clunky state it may not be as logical is it first seemed?

Paul