[GRASS-dev] d.histogram: x axis ticks labels fixed

GRASS GIS GRASS GIS developer
1

On Jan 28, 2008, at 8:32 AM, grass-dev-request@lists.osgeo.org wrote:

Date: Mon, 28 Jan 2008 13:55:34 +0100
From: Moritz Lennert <mlennert@club.worldonline.be>
Subject: Re: [GRASS-dev] d.histogram: x axis ticks labels fixed
To: Hamish <hamish_b@yahoo.com>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Message-ID: <479DD0C6.5080906@club.worldonline.be>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 27/01/08 10:00, Hamish wrote:

Before we spend too much more time on this module, were there plans to
reimplement the module as a wxPython program using one of the python
plotting libs?

ISTR that we had this debate before, but I would plead for some basic
graphing functionality to remain available outside of the GUI. Now since
we have decided that python is going to be the scripting language in the
future, it is probably reasonable to require it as dependency, but
please make sure that you can also get the results of d.histogram into a
ps/png file at the command line.

Moritz

Moritz,

For command line folks, can't you just pipe the results of r.stats into gnuplot? It would probably look better too.

Michael

2

On 28/01/08 16:42, Michael Barton wrote:

On Jan 28, 2008, at 8:32 AM, grass-dev-request@lists.osgeo.org wrote:

Date: Mon, 28 Jan 2008 13:55:34 +0100
From: Moritz Lennert <mlennert@club.worldonline.be>
Subject: Re: [GRASS-dev] d.histogram: x axis ticks labels fixed
To: Hamish <hamish_b@yahoo.com>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Message-ID: <479DD0C6.5080906@club.worldonline.be>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 27/01/08 10:00, Hamish wrote:

Before we spend too much more time on this module, were there plans to
reimplement the module as a wxPython program using one of the python
plotting libs?

ISTR that we had this debate before, but I would plead for some basic
graphing functionality to remain available outside of the GUI. Now since
we have decided that python is going to be the scripting language in the
future, it is probably reasonable to require it as dependency, but
please make sure that you can also get the results of d.histogram into a
ps/png file at the command line.

Moritz

Moritz,

For command line folks, can't you just pipe the results of r.stats into gnuplot? It would probably look better too.

Probably, but it means another dependency and, more importantly, another program to learn.

But don't you think that it would be possible to separate the GUI interface from the actual drawing code (both being in python) and thus make the latter accessible also from the command line ?

Moritz

3

Understood. These python utilities draw to Python canvases, and so normally need the GUI to run. It may be possible for them to output to a graphic file too. But they are designed to work in a GUI environment rather than a command line environment.

I don't advocate ditching d.histogram. In fact, the *easiest* thing from my standpoint, would be to have a sophisticated and slick C-graphing module that I just had to call as a command and presto it creates a graphic file that I can pop into a canvas. But I have some understand of the complexity of writing this in C or anything else. That's why to use high level graphing tools to do this.

Michael
____________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

On Jan 29, 2008, at 4:24 PM, Moritz Lennert wrote:

ISTR that we had this debate before, but I would plead for some basic
graphing functionality to remain available outside of the GUI. Now since
we have decided that python is going to be the scripting language in the
future, it is probably reasonable to require it as dependency, but
please make sure that you can also get the results of d.histogram into a
ps/png file at the command line.

Moritz

Moritz,
For command line folks, can't you just pipe the results of r.stats into gnuplot? It would probably look better too.

Probably, but it means another dependency and, more importantly, another program to learn.

But don't you think that it would be possible to separate the GUI interface from the actual drawing code (both being in python) and thus make the latter accessible also from the command line ?

Moritz

4

On 30/01/08 02:39, Michael Barton wrote:

Understood. These python utilities draw to Python canvases, and so normally need the GUI to run. It may be possible for them to output to a graphic file too. But they are designed to work in a GUI environment rather than a command line environment.

http://matplotlib.sourceforge.net/faq.html#BATCHMODE

I don't advocate ditching d.histogram. In fact, the *easiest* thing from my standpoint, would be to have a sophisticated and slick C-graphing module that I just had to call as a command and presto it creates a graphic file that I can pop into a canvas. But I have some understand of the complexity of writing this in C or anything else. That's why to use high level graphing tools to do this.

We do have some C-code which exists. It's just a question of whether we think that someone will take the time for updating that, or whether we should profit of the efforts done for the GUI to just have the same functions also available on the command line (with the additional advantage of consistency). If python is a required dependency anyhow, I don't have any religion about a module absolutely having to be in C if the python version is just as good.

Moritz

5

Moritz Lennert wrote:

> Understood. These python utilities draw to Python canvases, and so
> normally need the GUI to run. It may be possible for them to output to a
> graphic file too. But they are designed to work in a GUI environment
> rather than a command line environment.

http://matplotlib.sourceforge.net/faq.html#BATCHMODE

> I don't advocate ditching d.histogram. In fact, the *easiest* thing from
> my standpoint, would be to have a sophisticated and slick C-graphing
> module that I just had to call as a command and presto it creates a
> graphic file that I can pop into a canvas. But I have some understand of
> the complexity of writing this in C or anything else. That's why to use
> high level graphing tools to do this.

We do have some C-code which exists. It's just a question of whether we
think that someone will take the time for updating that, or whether we
should profit of the efforts done for the GUI to just have the same
functions also available on the command line (with the additional
advantage of consistency). If python is a required dependency anyhow, I
don't have any religion about a module absolutely having to be in C if
the python version is just as good.

The issue isn't one of C versus Python. It's one of being able to run
a command to generate a PNG/PS/PDF/etc file on a server versus only
being able to generate graphics on a desktop system which is capable
of running a GUI.

It should be possible to use GRASS in a web application (whether CGI
or AJAX or whatever), i.e. in a context where "import wx" is going to
fail because there are no X libraries and/or no X display to connect
to.

IOW, using Python is fine; using libraries which require X (or
Windows' GDI etc) isn't.

IMHO, it's okay to use cairo, as the dependence upon X libraries is a
build-time dependency (you can compile a version which only supports
the PNG/PS/PDF file backends), and dependence upon an X display is a
run-time dependency (it only needs a display to create an X drawing
"surface").

OTOH, wxWidgets won't run without a display (AFAICT), even if you only
wanted to render into an image then save it to a file.

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

6

On 30/01/08 16:19, Glynn Clements wrote:

Moritz Lennert wrote:

Understood. These python utilities draw to Python canvases, and so normally need the GUI to run. It may be possible for them to output to a graphic file too. But they are designed to work in a GUI environment rather than a command line environment.

http://matplotlib.sourceforge.net/faq.html#BATCHMODE

I don't advocate ditching d.histogram. In fact, the *easiest* thing from my standpoint, would be to have a sophisticated and slick C-graphing module that I just had to call as a command and presto it creates a graphic file that I can pop into a canvas. But I have some understand of the complexity of writing this in C or anything else. That's why to use high level graphing tools to do this.

We do have some C-code which exists. It's just a question of whether we think that someone will take the time for updating that, or whether we should profit of the efforts done for the GUI to just have the same functions also available on the command line (with the additional advantage of consistency). If python is a required dependency anyhow, I don't have any religion about a module absolutely having to be in C if the python version is just as good.

The issue isn't one of C versus Python. It's one of being able to run
a command to generate a PNG/PS/PDF/etc file on a server versus only
being able to generate graphics on a desktop system which is capable
of running a GUI.

It should be possible to use GRASS in a web application (whether CGI
or AJAX or whatever), i.e. in a context where "import wx" is going to
fail because there are no X libraries and/or no X display to connect
to.

IOW, using Python is fine; using libraries which require X (or
Windows' GDI etc) isn't.

IMHO, it's okay to use cairo, as the dependence upon X libraries is a
build-time dependency (you can compile a version which only supports
the PNG/PS/PDF file backends), and dependence upon an X display is a
run-time dependency (it only needs a display to create an X drawing
"surface").

OTOH, wxWidgets won't run without a display (AFAICT), even if you only
wanted to render into an image then save it to a file.

That's why I propose to try to code those functions which create histograms, profiles, etc, separating the drawing from the display, i.e. a function which draws a histogram to a given backend which can either be the GUI or a file. Thus we can use the same command with the same parameters in the GUI and on the command line. This means that these functions should be written as separate scripts which can be called from the GUI and not be integrated the way the seem to be now.

But maybe I'm misunderstanding the whole functioning of wxgrass ...

Moritz

7

On Jan 30, 2008, at 8:37 AM, Moritz Lennert wrote:

The issue isn't one of C versus Python. It's one of being able to run
a command to generate a PNG/PS/PDF/etc file on a server versus only
being able to generate graphics on a desktop system which is capable
of running a GUI.
It should be possible to use GRASS in a web application (whether CGI
or AJAX or whatever), i.e. in a context where "import wx" is going to
fail because there are no X libraries and/or no X display to connect
to.
IOW, using Python is fine; using libraries which require X (or
Windows' GDI etc) isn't.
IMHO, it's okay to use cairo, as the dependence upon X libraries is a
build-time dependency (you can compile a version which only supports
the PNG/PS/PDF file backends), and dependence upon an X display is a
run-time dependency (it only needs a display to create an X drawing
"surface").
OTOH, wxWidgets won't run without a display (AFAICT), even if you only
wanted to render into an image then save it to a file.

That's why I propose to try to code those functions which create histograms, profiles, etc, separating the drawing from the display, i.e. a function which draws a histogram to a given backend which can either be the GUI or a file. Thus we can use the same command with the same parameters in the GUI and on the command line. This means that these functions should be written as separate scripts which can be called from the GUI and not be integrated the way the seem to be now.

But maybe I'm misunderstanding the whole functioning of wxgrass ...

In some cases this is very doable. In others it would require either maintaining 2 parallel modules--one for the GUI and a stripped down one for the CLI--or crippling potential abilities of a feature in the GUI. I'm reluctant to commit to either of these options. Probably the most realistic way to have the best of both worlds as much as possible, would be to code complex display functions as a series of small, function-limited 'modules' that could be chained together from the command line or in the GUI. This is is perhaps more easily doable in Python with its structure of classes and methods.

Michael
____________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

8

Michael Barton wrote:

>> The issue isn't one of C versus Python. It's one of being able to run
>> a command to generate a PNG/PS/PDF/etc file on a server versus only
>> being able to generate graphics on a desktop system which is capable
>> of running a GUI.
>> It should be possible to use GRASS in a web application (whether CGI
>> or AJAX or whatever), i.e. in a context where "import wx" is going to
>> fail because there are no X libraries and/or no X display to connect
>> to.
>> IOW, using Python is fine; using libraries which require X (or
>> Windows' GDI etc) isn't.
>> IMHO, it's okay to use cairo, as the dependence upon X libraries is a
>> build-time dependency (you can compile a version which only supports
>> the PNG/PS/PDF file backends), and dependence upon an X display is a
>> run-time dependency (it only needs a display to create an X drawing
>> "surface").
>> OTOH, wxWidgets won't run without a display (AFAICT), even if you
>> only
>> wanted to render into an image then save it to a file.
>
> That's why I propose to try to code those functions which create
> histograms, profiles, etc, separating the drawing from the display,
> i.e. a function which draws a histogram to a given backend which
> can either be the GUI or a file. Thus we can use the same command
> with the same parameters in the GUI and on the command line. This
> means that these functions should be written as separate scripts
> which can be called from the GUI and not be integrated the way the
> seem to be now.
>
> But maybe I'm misunderstanding the whole functioning of wxgrass ...

In some cases this is very doable. In others it would require either
maintaining 2 parallel modules--one for the GUI and a stripped down
one for the CLI--or crippling potential abilities of a feature in the
GUI. I'm reluctant to commit to either of these options. Probably the
most realistic way to have the best of both worlds as much as
possible, would be to code complex display functions as a series of
small, function-limited 'modules' that could be chained together from
the command line or in the GUI. This is is perhaps more easily doable
in Python with its structure of classes and methods.

That's reasonable enough, but the code has to be structured in such a
way that the higher-level components interface to some form of
externally-supplied driver for the actual drawing.

That's where MatPlotLib appears to fall down: the choice of backends
is hard-coded into the library, so there's no way practical way to
redirect the output to the GRASS display system.

Unless the backend interface is made part of the public API, the only
practical way that we can use MatPlotLib is to bundle our own version
with a backend for the GRASS display system.

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