[GRASS-user] v.to.rast in a python loop, error
mlennert at club.worldonline.be
Mon Feb 13 07:18:58 EST 2012
On 13/02/12 12:26, Johannes Radinger wrote:
> -------- Original-Nachricht --------
>> Datum: Mon, 13 Feb 2012 11:46:21 +0100 Von: Moritz
>> Lennert<mlennert at club.worldonline.be> An: Johannes
>> Radinger<JRadinger at gmx.at> CC: grass-user at lists.osgeo.org,
>> glynn at gclements.plus.com Betreff: Re: [GRASS-user] v.to.rast in a
>> python loop, error
>> On 13/02/12 11:32, Johannes Radinger wrote:
>>> And my output with although all maps were removed manually with
>> and cross checked:
>>> Launching script '/Users/Johannes Radinger/Desktop/test2.py'...
>>> (Mon Feb 13 11:12:27 2012) /Users/Johannes
>>> ---------------------------------------------- raster files
>>> available in mapset<PERMANENT>: basins elevation_shade
>>> lakes soils elevation geology landuse
>>> raster files available in mapset<user1>: rast_FULL_HYDRO
>> ^^^^^^^^^^^^^^^ ^^^^^^^^^^^
>> Both maps _do_ exist in mapset user1. So it is normal that the
>> error appears.
> That is the strange behavior I am describing: Although g.list is
> first in the script, v.to.rast is processed first (at least
> partly)...or something like that...
Sounds weird to me. You could try to suspend execution after each line
Note that in the last version of the script you posted the line with
g.remove is commented out.
> Yes I am sure... That is the strange thing...I run g.remove (select
> all raster maps available for user1)...I can even run g.list manually
> before and there is no map... The maps are there as soon as I start
> the script (and then found by the g.list)
Nothing in your script creates these maps except for v.to.rast and its
v.to.rast that complains about them existing...
Maybe by using several time.sleep() and g.list calls you can check
exactly when this happens.
More information about the grass-user