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

[Glynn Clements]

Paul Kelly wrote:

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

Idea, currently. I need to introduce non-trivial API breakage in order
to go much further. Mainly, switching to floating-point coordinates
and adding begin/end operations to the move/cont and raster
primitives.

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

Certainly, I want (decent) PostScript output to at least be an option. 

The main question is whether we can abandon other formats, i.e. 
whether modules can rely upon being able to use the full feature set
(e.g. arbitrary clip paths, rotation/scaling of all output, pattern
fills etc), or whether they will be limited to a common-denominator
subset.

> 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 quite. I'm assuming that lines, polygons etc wouldn't be
rasterised when using a print DC, but you're still stuck with
coordinates on integer boundaries (and a fairly primitive API).

This is one of the main distinctions between an "ideal" graphics API
(PostScript, OpenGL) and an "adequate for GUI use" API (X11, Windows
GDI).

[FWIW, the wx API is heavily based upon Windows' GDI, which hasn't
really changed much since Windows 1.0.]

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

wx has PostScriptDC and PrinterDC, which allow you to use the same
code as for drawing on a screen DC. Not all operations will work on
such contexts, e.g. you can't use raster ops (XOR-plotting etc) in
PostScript. And you're still limited to the standard DC methods, e.g. 
no rotated images (NT/2K/XP has this, 95/98/ME doesn't, nor does X).

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

+1 ;)

-- 
Glynn Clements <glynn at gclements.plus.com>