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

[Michael Barton]

A couple thoughts to add to the good discussion below.

Using native GUI graphics can make for much nicer output. Look at the TclTk
text layer in the current GUI. I is the only thing that currently outputs in
postscript/eps. The best example is the thematic vector legend.

OTOH, if a nice GRASS plotting routine could serve the relatively simple GIS
needs, I've been rethinking on how I could do it in wxPython without having
to go through the kind of complex rendering system. Using a single line
GRASS command like d.histogram is a lot easier than having to program
graphic primitives with data from r.stat--even if I can use the wxPython
plot routine. It simply needs to go to a PNG file and be picked up again by
a display window. No need to worry about georeferencing. The one
complication is changing window size. The GRASS command would need to be
rerun and the graphic rendered. With the new PS driver, we might not be
stuck with a rasterized version. The fonts are still ugly (to me at least)
and remain difficult to change. But maybe recent changes have improved this.

If writing C code for simple native GRASS plotting is as straightforward as
Glynn suggests, it might be worth a look. d.histogram already can render to
a graphics file that can be displayed in a canvas. An equivalent
(non-interactive) d.profile does not exist (perhaps a flag added to
r.profile?) I haven't looked at d.graph closely since Hamish upgraded it,
but will do so.

Michael


On 4/23/07 2:31 AM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

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

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton