Hi, I think this has been mentioned before, but can't find the email. When running some functions or addons, e.g., r.forestfrag, I get the warning:
"WARNING: No data base element files found"
This seems to happen in some mapsets only. What is this warning about, and how to avoid it / remove it?
Best wishes
Paulo
On 21/03/16 11:38, Paulo van Breugel wrote:
Hi, I think this has been mentioned before, but can't find the email.
When running some functions or addons, e.g., r.forestfrag, I get the
warning:"WARNING: No data base element files found"
This seems to happen in some mapsets only. What is this warning about,
and how to avoid it / remove it?
In my experience it comes from a g.remove call that tries to remove a file that doesn't exist. So generally, testing for its existence before removing avoids the warning.
Moritz
On 21-03-16 11:41, Moritz Lennert wrote:
On 21/03/16 11:38, Paulo van Breugel wrote:
Hi, I think this has been mentioned before, but can't find the email.
When running some functions or addons, e.g., r.forestfrag, I get the
warning:"WARNING: No data base element files found"
This seems to happen in some mapsets only. What is this warning about,
and how to avoid it / remove it?In my experience it comes from a g.remove call that tries to remove a file that doesn't exist. So generally, testing for its existence before removing avoids the warning.
I see, in my script I remove temporary layers using g.remove, but I am also using the procedure with atexit.register(cleanup)), which will (attempt to) clean up the layers at the end of the script.
Moritz
On Mon, Mar 21, 2016 at 11:41 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 21/03/16 11:38, Paulo van Breugel wrote:
...
"WARNING: No data base element files found"
...
In my experience it comes from a g.remove call that tries to remove a file
that doesn't exist. So generally, testing for its existence before removing
avoids the warning.
Also i.colors.enhance suffers from that.
Do we have any "best practice" example for that in an existing core script?
Markus
On 22-03-16 10:59, Markus Neteler wrote:
On Mon, Mar 21, 2016 at 11:41 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:On 21/03/16 11:38, Paulo van Breugel wrote:
...
"WARNING: No data base element files found"
...
In my experience it comes from a g.remove call that tries to remove a file
that doesn't exist. So generally, testing for its existence before removing
avoids the warning.Also i.colors.enhance suffers from that.
Do we have any "best practice" example for that in an existing core script?
Would be good to have a 'best practice' example. I have used before something like:
rast = 'my_raster'
cf = grass.find_file(name=rast, element = 'cell', mapset=grass.gisenv()['MAPSET'])
if not cf['fullname'] == '':
grass.run_command("g.remove", type="raster", name=rast, quiet=True)
But I guess there are better ways to do this?
P.s. in the find_file example above, is it sufficient to use as 'element' 'cell', i.e., does that also find fcell and cellhd layers?
Markus
On Tue, Mar 22, 2016 at 7:22 AM, Paulo van Breugel
<p.vanbreugel@gmail.com> wrote:
On 22-03-16 10:59, Markus Neteler wrote:
On Mon, Mar 21, 2016 at 11:41 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:On 21/03/16 11:38, Paulo van Breugel wrote:
...
"WARNING: No data base element files found"
...
In my experience it comes from a g.remove call that tries to remove a
file
that doesn't exist. So generally, testing for its existence before
removing
avoids the warning.Also i.colors.enhance suffers from that.
Do we have any "best practice" example for that in an existing core
script?Would be good to have a 'best practice' example. I have used before
something like:rast = 'my_raster'
cf = grass.find_file(name=rast, element = 'cell',
mapset=grass.gisenv()['MAPSET'])
if not cf['fullname'] == '':
grass.run_command("g.remove", type="raster", name=rast, quiet=True)But I guess there are better ways to do this?
Best practice is just to not remove layers which don't exist. So don't
remove the temporary maps inside the script, but rather inside the
registered cleanup procedure which is called every time. The temporary
maps should be added to a global list as they are used, so when you
interrupt the script in the middle only the already created temporary
maps will be deleted.
P.s. in the find_file example above, is it sufficient to use as 'element'
'cell', i.e., does that also find fcell and cellhd layers?
All of 'raster', 'rast', 'cell' will find raster maps (of all
types),not sure what do you mean with cellhd layer.
Anna
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On 22-03-16 14:19, Anna Petrášová wrote:
On Tue, Mar 22, 2016 at 7:22 AM, Paulo van Breugel
<p.vanbreugel@gmail.com> wrote:On 22-03-16 10:59, Markus Neteler wrote:
On Mon, Mar 21, 2016 at 11:41 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:On 21/03/16 11:38, Paulo van Breugel wrote:
...
"WARNING: No data base element files found"
...
In my experience it comes from a g.remove call that tries to remove a
file
that doesn't exist. So generally, testing for its existence before
removing
avoids the warning.Also i.colors.enhance suffers from that.
Do we have any "best practice" example for that in an existing core
script?Would be good to have a 'best practice' example. I have used before
something like:rast = 'my_raster'
cf = grass.find_file(name=rast, element = 'cell',
mapset=grass.gisenv()['MAPSET'])
if not cf['fullname'] == '':
grass.run_command("g.remove", type="raster", name=rast, quiet=True)But I guess there are better ways to do this?
Best practice is just to not remove layers which don't exist. So don't
remove the temporary maps inside the script, but rather inside the
registered cleanup procedure which is called every time. The temporary
maps should be added to a global list as they are used, so when you
interrupt the script in the middle only the already created temporary
maps will be deleted.
That is what I am doing now, using atexit.register(). But if a script generates a very large number of layers, it might be worthwhile removing them in between to save disk space (I recently had to such a case at hand, where keeping the intermediate layers would have taken up too much space). But generally yes, following the cleanup procedure makes absolutely more sense. In the script I referred to in the initial email, I used both because at the time of writing the script, I misunderstood the working of atexit.register().
P.s. in the find_file example above, is it sufficient to use as 'element'
'cell', i.e., does that also find fcell and cellhd layers?All of 'raster', 'rast', 'cell' will find raster maps (of all
types),not sure what do you mean with cellhd layer.
I was looking at the possible element types for the find_file function at https://grass.osgeo.org/programming7/find__file_8c.html, and cellhd was mentioned as one possible element type (I couldn't find a list though of all possible database elements)
Anna
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On Tue, Mar 22, 2016 at 3:02 PM, Paulo van Breugel
<p.vanbreugel@gmail.com> wrote:
...
I was looking at the possible element types for the find_file function at
https://grass.osgeo.org/programming7/find__file_8c.html, and cellhd was
mentioned as one possible element type (I couldn't find a list though of all
possible database elements)
Do you mean
g.findfile -l
List of available elements:
raster (raster map(s))
raster_3d (3D raster map(s))
vector (vector map(s))
label (paint label file(s))
region (region definition(s))
group (imagery group(s))
?
It is also in
lib/manage/element_list
Markus