[GRASS-user] Interpreting r.watershed accumulation map

GRASS GRASS user
21

On Sat, 15 Oct 2016, Sören Gebbert wrote:

Please try to put all mapsets that you use in your analysis into the
mapset search path. The temporal framework will only access strds in
mapsets that are located in the current search path.

Soeren,

   I use g.mapsets to add all 5 mapsets to the search path. Regardless,
tomorrow I'll make sure they're all in the search path and run Itzi again.

Many thanks,

Rich

22

On Sat, 15 Oct 2016, Sören Gebbert wrote:

Please try to put all mapsets that you use in your analysis into the
mapset search path. The temporal framework will only access strds in
mapsets that are located in the current search path.

Soeren,

   Current mapset is 'analyses':

g.mapset -p

analyses

   Some maps might be in other mapsets so ...

g.mapsets -p

Accessible mapsets:
analyses PERMANENT features soils topography precipitation

which is all the mapsets in the location.

   The file, itzi-param.txt, contains:

[time]
duration = 2:00:00
record_step = 00:05:00

[input]
dem = be_cropped@topography
friction = n
rain = rain

[output]
prefix = pop
values = h, wse, v, vdir, boundaries

[statistics]
stats_file = pop.csv

   And this is the traceback:

itzi run itzi-param.txt

Starting simulation of itzi-param.txt... WARNING: Error during execution: Traceback (most recent call last):
   File "/usr/lib/python2.7/site-packages/itzi/itzi.py", line 183, in
sim_runner_worker
     sim_runner.run()
   File "/usr/lib/python2.7/site-packages/itzi/itzi.py", line 90, in run
     sim_param=self.conf.sim_param)
   File "/usr/lib/python2.7/site-packages/itzi/simulation.py", line 77, in
__init__
     self.gis.read(self.in_map_names)
   File "/usr/lib/python2.7/site-packages/itzi/gis.py", line 187, in read
     elif self.name_is_stds(self.format_id(map_name)):
   File "/usr/lib/python2.7/site-packages/itzi/gis.py", line 138, in
name_is_stds
     if tgis.SpaceTimeRasterDataset(name).is_in_db():
   File
"/usr/local/grass-7.3.svn/etc/python/grass/temporal/abstract_dataset.py",
line 368, in is_in_db
     return self.base.is_in_db(dbif)
   File "/usr/local/grass-7.3.svn/etc/python/grass/temporal/base.py", line
315, in is_in_db
     dbif.execute(sql, mapset=self.mapset)
   File "/usr/local/grass-7.3.svn/etc/python/grass/temporal/core.py", line
981, in execute
     self._create_mapset_error_message(mapset)))
   File
"/usr/local/grass-7.3.svn/etc/python/grass/pygrass/messages/__init__.py",
line 271, in fatal
     sys.exit(1)
SystemExit: 1

Simulations complete. Elapsed times: itzi-param.txt: 0:00:01 Total: 0:00:01 Average: 0:00:01

   Please suggest what I should try modifying.

Thanks,

Rich

23

Hi,
i don’t know why this happens. It may be a bug in the temporal framework or in itzi. Testing the code in the temporal framework seems to work, but more testing is needed.
However, the traceback is fine, but there must be an error message that will tell you what mapset is missing and what mapsets are in the temporal framework search path.

Something like:
“”"
You have no permission to "
"access mapset <%(mapset)s>, or "
"mapset <%(mapset)s> has no temporal database. "
"Accessable mapsets are: <%(mapsets)s>

“”"

Best regards
Soeren

2016-10-16 22:03 GMT+02:00 Rich Shepard <rshepard@appl-ecosys.com>:

On Sat, 15 Oct 2016, Sören Gebbert wrote:

Please try to put all mapsets that you use in your analysis into the
mapset search path. The temporal framework will only access strds in
mapsets that are located in the current search path.

Soeren,

Current mapset is ‘analyses’:

g.mapset -p

analyses

Some maps might be in other mapsets so …

g.mapsets -p

Accessible mapsets:
analyses PERMANENT features soils topography precipitation

which is all the mapsets in the location.

The file, itzi-param.txt, contains:

[time]
duration = 2:00:00
record_step = 00:05:00

[input]
dem = be_cropped@topography
friction = n
rain = rain

[output]
prefix = pop
values = h, wse, v, vdir, boundaries

[statistics]
stats_file = pop.csv

And this is the traceback:

itzi run itzi-param.txt

Starting simulation of itzi-param.txt… WARNING: Error during execution: Traceback (most recent call last):
File “/usr/lib/python2.7/site-packages/itzi/itzi.py”, line 183, in
sim_runner_worker
sim_runner.run()
File “/usr/lib/python2.7/site-packages/itzi/itzi.py”, line 90, in run
sim_param=self.conf.sim_param)
File “/usr/lib/python2.7/site-packages/itzi/simulation.py”, line 77, in
init
self.gis.read(self.in_map_names)
File “/usr/lib/python2.7/site-packages/itzi/gis.py”, line 187, in read
elif self.name_is_stds(self.format_id(map_name)):
File “/usr/lib/python2.7/site-packages/itzi/gis.py”, line 138, in
name_is_stds
if tgis.SpaceTimeRasterDataset(name).is_in_db():
File
“/usr/local/grass-7.3.svn/etc/python/grass/temporal/abstract_dataset.py”,
line 368, in is_in_db
return self.base.is_in_db(dbif)
File “/usr/local/grass-7.3.svn/etc/python/grass/temporal/base.py”, line
315, in is_in_db
dbif.execute(sql, mapset=self.mapset)
File “/usr/local/grass-7.3.svn/etc/python/grass/temporal/core.py”, line
981, in execute
self._create_mapset_error_message(mapset)))
File
“/usr/local/grass-7.3.svn/etc/python/grass/pygrass/messages/init.py”,
line 271, in fatal
sys.exit(1)
SystemExit: 1

Simulations complete. Elapsed times: itzi-param.txt: 0:00:01 Total: 0:00:01 Average: 0:00:01

Please suggest what I should try modifying.

Thanks,

Rich

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

24

On Sun, 16 Oct 2016, Sören Gebbert wrote:

I don't know why this happens. It may be a bug in the temporal framework
or in itzi. Testing the code in the temporal framework seems to work, but
more testing is needed.

Soren,

   If I can help test with my data I'll be happy to contribute to getting
this tool working.

However, the traceback is fine, but there must be an error message that
will tell you what mapset is missing and what mapsets are in the temporal
framework search path.

Something like:
"""
You have no permission to "
      "access mapset <%(mapset)s>, or "
      "mapset <%(mapset)s> has no temporal database. "
      "Accessable mapsets are: <%(mapsets)s>

"""

   I sent everything displayed on the console from the command line to the
end. The mapset may not have a temporal database, however ... the mapset's
subdirectory in the location contains two subdirectories: g3dcell and tgis.
g3dcell/ is empty and tgis/ conains 'sqlite.db' holding 462848 bytes:

sqlite> .tables
raster3d_absolute_time str3ds_absolute_time stvds_metadata raster3d_base str3ds_base stvds_relative_time raster3d_metadata str3ds_metadata stvds_spatial_extent raster3d_relative_time str3ds_relative_time stvds_view_abs_time raster3d_spatial_extent str3ds_spatial_extent stvds_view_rel_time raster3d_stds_register str3ds_view_abs_time tgis_metadata raster3d_view_abs_time str3ds_view_rel_time vector_absolute_time raster3d_view_rel_time strds_absolute_time vector_base raster_absolute_time strds_base vector_metadata raster_base strds_metadata vector_relative_time raster_metadata strds_relative_time vector_spatial_extent raster_relative_time strds_spatial_extent vector_stds_register raster_spatial_extent strds_view_abs_time vector_view_abs_time raster_stds_register strds_view_rel_time vector_view_rel_time raster_view_abs_time stvds_absolute_time raster_view_rel_time stvds_base

   The schema's too large to print here.

   Does any of this help?

Rich

25

Hello Sören,

The problem occurs when Itzï is calling:
"tgis.SpaceTimeRasterDataset(name).is_in_db()"

tgis.init() is called just before. "name" is a a formatted map or
strds ID (i.e including mapset)

It is difficult to understand what is happening because I can't
reproduce the problem.

Regards,
Laurent

2016-10-16 16:01 GMT-05:00 Sören Gebbert <soerengebbert@googlemail.com>:

Hi,
i don't know why this happens. It may be a bug in the temporal framework or
in itzi. Testing the code in the temporal framework seems to work, but more
testing is needed.
However, the traceback is fine, but there must be an error message that will
tell you what mapset is missing and what mapsets are in the temporal
framework search path.

Something like:
"""
You have no permission to "
       "access mapset <%(mapset)s>, or "
       "mapset <%(mapset)s> has no temporal database. "
       "Accessable mapsets are: <%(mapsets)s>

"""

Best regards
Soeren

2016-10-16 22:03 GMT+02:00 Rich Shepard <rshepard@appl-ecosys.com>:

On Sat, 15 Oct 2016, Sören Gebbert wrote:

Please try to put all mapsets that you use in your analysis into the
mapset search path. The temporal framework will only access strds in
mapsets that are located in the current search path.

Soeren,

  Current mapset is 'analyses':

g.mapset -p

analyses

  Some maps might be in other mapsets so ...

g.mapsets -p

Accessible mapsets:
analyses PERMANENT features soils topography precipitation

which is all the mapsets in the location.

  The file, itzi-param.txt, contains:

[time]
duration = 2:00:00
record_step = 00:05:00

[input]
dem = be_cropped@topography
friction = n
rain = rain

[output]
prefix = pop
values = h, wse, v, vdir, boundaries

[statistics]
stats_file = pop.csv

  And this is the traceback:

itzi run itzi-param.txt

Starting simulation of itzi-param.txt... WARNING: Error during execution:
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/itzi/itzi.py", line 183, in
sim_runner_worker
    sim_runner.run()
  File "/usr/lib/python2.7/site-packages/itzi/itzi.py", line 90, in run
    sim_param=self.conf.sim_param)
  File "/usr/lib/python2.7/site-packages/itzi/simulation.py", line 77, in
__init__
    self.gis.read(self.in_map_names)
  File "/usr/lib/python2.7/site-packages/itzi/gis.py", line 187, in read
    elif self.name_is_stds(self.format_id(map_name)):
  File "/usr/lib/python2.7/site-packages/itzi/gis.py", line 138, in
name_is_stds
    if tgis.SpaceTimeRasterDataset(name).is_in_db():
  File
"/usr/local/grass-7.3.svn/etc/python/grass/temporal/abstract_dataset.py",
line 368, in is_in_db
    return self.base.is_in_db(dbif)
  File "/usr/local/grass-7.3.svn/etc/python/grass/temporal/base.py", line
315, in is_in_db
    dbif.execute(sql, mapset=self.mapset)
  File "/usr/local/grass-7.3.svn/etc/python/grass/temporal/core.py", line
981, in execute
    self._create_mapset_error_message(mapset)))
  File
"/usr/local/grass-7.3.svn/etc/python/grass/pygrass/messages/__init__.py",
line 271, in fatal
    sys.exit(1)
SystemExit: 1

Simulations complete. Elapsed times: itzi-param.txt: 0:00:01 Total:
0:00:01 Average: 0:00:01

  Please suggest what I should try modifying.

Thanks,

Rich
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

26

On Mon, 17 Oct 2016, Laurent C. wrote:

It is difficult to understand what is happening because I can't reproduce
the problem.

Laurent,

   If it helps I can share pertinent data with you off the mail list. I think
all you need is the DEM map, correct?

   I would appreciate having this work because I anticipate a need for both
Itzi and TGRASS in future projects.

Regards,

Rich

27

On Sun, 16 Oct 2016, Sören Gebbert wrote:

I don't know why this happens.

   I sent Laurant the DEM and the Itzi simulation run worked for him using
grass-7.0.5, but it fails here with grass-7.0.6, 7.2.svn, and 7.3.svn. There
must be something different here on this particular host; I've no idea where
to start looking for differences.

   Also, there are differences in the elevation maps produced by different
grass versions when the same source DEM is re-projected. The same command
was used in each version:

r.proj --o loc=Oregon-Dayton-feet map=topography in=be_cropped out=be_cropped
meth=bilinear

   The output from 7.0.x is smaller, and shows greater elevation differencs,
that those of 7.2.svn and 7.3.svn (the latter two appear the same); copies
attached.

   If anyone has suggestions on identifying what's different on this host
that prevents Itzi from running, please share your expertise with me.

Rich

(attachments)

be_cropped70.png
be_cropped73.png

28

Rich Shepard wrote

On Sun, 16 Oct 2016, Sören Gebbert wrote:

I don't know why this happens.

   I sent Laurant the DEM and the Itzi simulation run worked for him using
grass-7.0.5, but it fails here with grass-7.0.6, 7.2.svn, and 7.3.svn.
There
must be something different here on this particular host; I've no idea
where
to start looking for differences.

   Also, there are differences in the elevation maps produced by different
grass versions when the same source DEM is re-projected. The same command
was used in each version:

r.proj --o loc=Oregon-Dayton-feet map=topography in=be_cropped
out=be_cropped
meth=bilinear

   The output from 7.0.x is smaller, and shows greater elevation
differencs,
that those of 7.2.svn and 7.3.svn (the latter two appear the same); copies
attached.

   If anyone has suggestions on identifying what's different on this host
that prevents Itzi from running, please share your expertise with me.

Rich

_______________________________________________
grass-user mailing list

grass-user@.osgeo

http://lists.osgeo.org/mailman/listinfo/grass-user

be_cropped70.png (135K)
&lt;http://osgeo-org.1560.x6.nabble.com/attachment/5291143/0/be_cropped70.png&gt;
be_cropped73.png (146K)
&lt;http://osgeo-org.1560.x6.nabble.com/attachment/5291143/1/be_cropped73.png&gt;

If a GRASS command gives really different results by different GRASS
versions and the different behaviour isn't documented in the manual or in
the news of the new release, the best way that this will be checked:

- open a ticket at trac (1)
- provide data and used commands to reproduce the issue

otherwise there is a good chance that

- the issue will get lost in the mailing list while the subject of the
threats points to another issue
- devs can't test the issue

(1) https://trac.osgeo.org/grass

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Interpreting-r-watershed-accumulation-map-tp5290054p5291146.html
Sent from the Grass - Users mailing list archive at Nabble.com.

29

On Mon, 17 Oct 2016, Helmut Kudrnovsky wrote:

If a GRASS command gives really different results by different GRASS
versions and the different behaviour isn't documented in the manual or in
the news of the new release, the best way that this will be checked:

- open a ticket at trac (1)

   Done.

Rich

30

On Tue, Oct 18, 2016 at 1:05 AM, Rich Shepard <rshepard@appl-ecosys.com> wrote:

On Mon, 17 Oct 2016, Helmut Kudrnovsky wrote:

If a GRASS command gives really different results by different GRASS
versions

In order to find out:
Calculate a "differences" map to see if the *values* are different by
using r.mapcalc along with the "differences" color table provided by
r.colors.

and the different behaviour isn't documented in the manual or in
the news of the new release,

Is is mentioned
https://trac.osgeo.org/grass/wiki/Release/7.2.0-News#GUIchanges
- cartography in Map Display:
   - new color tables which are perceptually uniform: viridis and grass
   - viridis color table is the new default replacing rainbow (manage
with G7:r.colors)

the best way that this will be checked:

- open a ticket at trac (1)

  Done.

For the email ist archive:

On Tue, Oct 18, 2016 at 1:32 AM, GRASS GIS <trac@osgeo.org> wrote:

#3185: Maps display differently 7.0.x vs 7.2.svn and 7.3.svn

...

* status: new => closed
* resolution: => invalid

Comment:

The default color table changed (see #3043), use r.colors to set different
color table.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3185#comment:1&gt;

cheers,
Markus

31

On Sat, 22 Oct 2016, Markus Neteler wrote:

Is is mentioned
https://trac.osgeo.org/grass/wiki/Release/7.2.0-News#GUIchanges
- cartography in Map Display:
  - new color tables which are perceptually uniform: viridis and grass
  - viridis color table is the new default replacing rainbow (manage
with G7:r.colors)

Markus,

   I should have checked before writing. My apologies to all.

Rich

32

On Sat, Oct 22, 2016 at 11:22 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:

On Sat, 22 Oct 2016, Markus Neteler wrote:

Is is mentioned
https://trac.osgeo.org/grass/wiki/Release/7.2.0-News#GUIchanges
- cartography in Map Display:
  - new color tables which are perceptually uniform: viridis and grass
  - viridis color table is the new default replacing rainbow (manage
with G7:r.colors)

Markus,

  I should have checked before writing. My apologies to all.

Rich,

no problem and nothing to apologize for.

This information was kind of hidden (yesterday I made it bold), yet I
wonder how to better communicate such changes.
If you have suggestions (or anyone else), please let us know!

Markus

33

On 23-10-16 19:18, Markus Neteler wrote:

On Sat, Oct 22, 2016 at 11:22 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:

On Sat, 22 Oct 2016, Markus Neteler wrote:

Is is mentioned
https://trac.osgeo.org/grass/wiki/Release/7.2.0-News#GUIchanges
- cartography in Map Display:
   - new color tables which are perceptually uniform: viridis and grass
   - viridis color table is the new default replacing rainbow (manage
with G7:r.colors)

Markus,

   I should have checked before writing. My apologies to all.

Rich,

no problem and nothing to apologize for.

This information was kind of hidden (yesterday I made it bold), yet I
wonder how to better communicate such changes.
If you have suggestions (or anyone else), please let us know!

What about adding this as a note under 'Notes' in the manual page of r.colors. This is not strictly an output of r.colors, but people might look there first when noticing that the colours of their map differs from what they expect. Perhaps something like: "The default colour table is the viridis colour table. Note that this was changed in GRASS GIS version 7.2. In earlier versions the default colour table was 'rainbow'."

Markus
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

34

On 23-10-16 19:47, Paulo van Breugel wrote:

On 23-10-16 19:18, Markus Neteler wrote:

On Sat, Oct 22, 2016 at 11:22 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:

On Sat, 22 Oct 2016, Markus Neteler wrote:

Is is mentioned
https://trac.osgeo.org/grass/wiki/Release/7.2.0-News#GUIchanges
- cartography in Map Display:
   - new color tables which are perceptually uniform: viridis and grass
   - viridis color table is the new default replacing rainbow (manage
with G7:r.colors)

Just running i.pca and noticed that the output layers are not (all) colored using the viridis color table. In the example on the help page, the colors of the layers are grey scale. Does the i.pca module apply a color scheme explicitly, or how does this work?

Markus,

   I should have checked before writing. My apologies to all.

Rich,

no problem and nothing to apologize for.

This information was kind of hidden (yesterday I made it bold), yet I
wonder how to better communicate such changes.
If you have suggestions (or anyone else), please let us know!

What about adding this as a note under 'Notes' in the manual page of r.colors. This is not strictly an output of r.colors, but people might look there first when noticing that the colours of their map differs from what they expect. Perhaps something like: "The default colour table is the viridis colour table. Note that this was changed in GRASS GIS version 7.2. In earlier versions the default colour table was 'rainbow'."

Markus
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

35

On Sun, 23 Oct 2016, Markus Neteler wrote:

This information was kind of hidden (yesterday I made it bold), yet I
wonder how to better communicate such changes. If you have suggestions (or
anyone else), please let us know!

Markus,

   Perhaps a running CHANGELOG on the download page of the wes site would
help. In there major changes, by release (including development releases)
would be recorded.

   The CHANGELOG could include addition of new features, significant changes
in existing features, file storage structure changes, major updates to
modules, and other information of value to users.

Rich

36

On Sun, 23 Oct 2016, Paulo van Breugel wrote:

What about adding this as a note under 'Notes' in the manual page of
r.colors. This is not strictly an output of r.colors, but people might
look there first when noticing that the colours of their map differs from
what they expect. Perhaps something like: "The default colour table is the
viridis colour table. Note that this was changed in GRASS GIS version 7.2.
In earlier versions the default colour table was 'rainbow'."

Paulo,

   If a user notices shifts in color from what modules in prior versions
produced is it likely for them to think of looking at r.color if they don't
explicitly use that module?

   Writing only for myself, I would not have thought of looking there as I
focused on the modeling required for my current project.

   A better location would be the download page, at the top, in a single file
that maintains a running history of changes.

Regards,

Rich

37

Rich,

On Sun, Oct 23, 2016 at 7:57 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:

On Sun, 23 Oct 2016, Markus Neteler wrote:

This information was kind of hidden (yesterday I made it bold), yet I
wonder how to better communicate such changes. If you have suggestions (or
anyone else), please let us know!

Markus,

  Perhaps a running CHANGELOG on the download page of the wes site would
help. In there major changes, by release (including development releases)
would be recorded.

The ChangeLog is actually there:
https://grass.osgeo.org/grass72/source/snapshot/
--> ChangeLog.gz

but I will link it to the respective download pages for greater visibility.

  The CHANGELOG could include addition of new features, significant changes
in existing features, file storage structure changes, major updates to
modules, and other information of value to users.

Yeah, that we attempted to cover here:
- https://trac.osgeo.org/grass/wiki/Release/7.2.0-News

Shall we restructure these detailed release pages?

Markus

38

On Mon, 24 Oct 2016, Markus Neteler wrote:

Shall we restructure these detailed release pages?

Markus,

   My suggestion: place it on <https://grass.osgeo.org/download/&gt;,
immediately under the line, "Get here your free and full GIS software
copy:". and in all uppercase letters.

   This page is seen by everyone and will encourage readership of the file.
As a matter of fact, including a statement to the effect that reading the
changelog is encouraged, especially when upgrading versions, is strongly
encouraged.

Rich

39

On Mon, Oct 24, 2016 at 8:50 AM, Rich Shepard <rshepard@appl-ecosys.com>
wrote:

and in all uppercase letters.

I usually ignore things in all uppercase; often those things are shouting
and not worth reading. Also, it is a bad typography.

40

On Mon, Oct 24, 2016 at 9:10 AM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Mon, Oct 24, 2016 at 8:50 AM, Rich Shepard <rshepard@appl-ecosys.com>
wrote:

and in all uppercase letters.

I usually ignore things in all uppercase; often those things are shouting
and not worth reading. Also, it is a bad typography.

Yes please, let's try to avoid that.

Anna

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user