On Oct 8, 2008, at 6:38 PM, <[EMAIL PROTECTED]> wrote:
Date: Wed, 8 Oct 2008 23:50:12 +0100
From: Glynn Clements <[EMAIL PROTECTED]>
Subject: Re: [GRASS-dev] porting r.in.wms to python
To: Michael Barton <[EMAIL PROTECTED]>
Cc: grass-dev@lists.osgeo.org
Message-ID: <[EMAI
Michael Barton wrote:
> >> 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 sim
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 ow
Michael:
> 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.
a plus for matplotlib is that those of us who know Matlab plotting commands
quite well will already be trained i
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
A few comments below.
On Oct 6, 2008, at 1:49 AM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]
> wrote:
Date: Mon, 6 Oct 2008 06:34:41 +0100
From: Glynn Clements <[EMAIL PROTECTED]>
Subject: Re: [GRASS-dev] porting r.in.wms to python
To: [EMAIL PROTECTED]
Cc: grass-dev
M
I'm not sure if it's relevant, but the wxpython GUI requires the pywin32
package to be installed. Perhaps this includes some workarounds for this
sort of thing - I haven't looked into it to see. But I don't like the
idea of requiring lots of extra packages - installing wxpython on top of
Python
Paul Kelly wrote:
> > Oops. It turns out that Python doesn't understand %PATHEXT% (but it
> > least it's consistent; it doesn't work with .bat or .cmd files
> > either).
>
> It looks to me like it doesn't work with .exe either, i.e. it doesn't
> assume the extension - e.g. trying to run a scrip
On Mon, 6 Oct 2008, Glynn Clements wrote:
Oops. It turns out that Python doesn't understand %PATHEXT% (but it
least it's consistent; it doesn't work with .bat or .cmd files
either).
It looks to me like it doesn't work with .exe either, i.e. it doesn't
assume the extension - e.g. trying to run
On 06/10/08 04:16, Hamish wrote:
Glynn wrote:
d.vect.thematic (d.mon)
(somewhat replaced d.thematic.area,v.class? any thoughts Moritz/Michael?)
d.thematic.area works for me, but I have not had any testing feedback
from anyone else.
I still need to finish "d.thematic.points_and_lin
Markus Neteler wrote:
> >> etc/gui/scripts/r.support.sh was partially needed because
> >> 1) non-interactive version did not in the past support all interactive
> >> functionality, and
> >> 2) interactive version weirdly exits prematurely when called directly
> >> from Tcl/Tk.
> >
> > More gener
On Mon, Oct 6, 2008 at 7:34 AM, Glynn Clements <[EMAIL PROTECTED]> wrote:
> Hamish wrote:
...
>> etc/gui/scripts/r.support.sh was partially needed because
>> 1) non-interactive version did not in the past support all interactive
>> functionality, and
>> 2) interactive version weirdly exits prematu
On Mon, Oct 6, 2008 at 4:16 AM, Hamish <[EMAIL PROTECTED]> wrote:
>> d.rast.leg (d.frame)
>
> (any thoughts Markus?)
>
> perhaps replaced by some wxGUI "load cartographic template" tool?
> (users could contribute their own etc..)
d.rast.leg we use on a daily basis. Something similar wo
> > > v.in.gpsbabel/v.in.gpsbabel
> > > v.in.garmin/v.in.garmin
> >
> > Certainly v.in.gpsbabel should survive in some form. v.in.garmin is
> > useful as the gpsbabel garmin filter does not pass through all fields.
> >
> > the XML stuff in v.in.gpsbabel is in desperate need of a python
> > rep
Hamish wrote:
> semi-related-- does anyone know of a libgis function that will return
> the current projection+coordinate's convergence angle WRT true north?
> A method to find that with the `proj` program is given here:
> http://grass.osgeo.org/wiki/Ps.map_scripts#Creating_a_fancy_North_Arrow
Hamish wrote:
> > > I was planning on leaving those until last ;)
> >
> > Well, I'm now planning on just leaving them, period ;)
> >
> > Here's the current status on conversion of scripts to
> > Python:
> >
> > The following scripts are disabled, and haven't been converted:
> >
> > d.out.
Paul Kelly wrote:
> > Also, should we change windows_launch.bat to invoke Python on the
> > scripts, or just install the scripts with a .py extension and add .PY
> > to PATHEXT?
>
> windows_launch.bat was only needed because there was no way to persuade
> Tcl on Windows to execute any files tha
> > d.out.gpsdrive (d.mon)
>
> (me)
> like the very useful d.out.file module, it dumps current (composed) map
> display to the PNG driver via d.save. I suppose replacing this will
> be a clone/modification of how d.out.file's functionality has been
> replicated.
I should mention that while
>>> before anyone spends any time porting r.in.wms/r.tileset to python,
Glynn wrote:
> > I was planning on leaving those until last ;)
>
> Well, I'm now planning on just leaving them, period ;)
>
> Here's the current status on conversion of scripts to
> Python:
>
> The following scripts are disa
On Sun, 5 Oct 2008, Glynn Clements wrote:
Also, should we change windows_launch.bat to invoke Python on the
scripts, or just install the scripts with a .py extension and add .PY
to PATHEXT?
windows_launch.bat was only needed because there was no way to persuade
Tcl on Windows to execute any f
Glynn Clements wrote:
> Here's the current status on conversion of scripts to Python:
Apart from the scripts in the "scripts" directory, various parts of
GRASS install shell scripts. After filtering out the "shell" scripts
which are actually Tcl/Tk scripts using the "exec $GRASS_WISH" trick,
I s
On Sun, Oct 5, 2008 at 9:39 PM, Glynn Clements <[EMAIL PROTECTED]> wrote:
> r.out.gdal.sh is still installed, but hasn't been converted. Is this
> worth keeping around as a backup? If it is, I'll convert it, otherwise
> it should be removed.
It should be removed as incomplete + causing troubles.
Glynn Clements wrote:
> > before anyone spends any time porting r.in.wms/r.tileset to python,
>
> I was planning on leaving those until last ;)
Well, I'm now planning on just leaving them, period ;)
Here's the current status on conversion of scripts to Python:
The following scripts are disabl
Hamish wrote:
> before anyone spends any time porting r.in.wms/r.tileset to python,
I was planning on leaving those until last ;)
Are there any other scripts which don't need to be converted?
g.mlist/g.mremove are low priority now that there is a C version.
Do {r,r3}.mapcalculator need to be
Hi,
before anyone spends any time porting r.in.wms/r.tileset to python, I
would suggest that it be substantially rewritten from the ground up,
requiring GDAL 1.5+'s WMS import filter instead of our own brittle
wget/curl solution. This requires writing a small XML template with the
pararms: http://
25 matches
Mail list logo
