[GRASS-dev] G.region bug when setting 3d resolution??? Maybe not

GRASS GIS GRASS GIS developer
1

Paulick,

Below I try to answer at least a few questions. Midway through, I think I
figured out what the problem is. There was a long-standing bug in the 3D
settings using g.region. Then again, maybe not. Read on...

On 1/3/07 10:13 PM, "Paulick Consult" <stefan.paulick@urbeli.com> wrote:

Michael,

I found that both PERMANENT WIND and DEFAULT_WIND was set to:

proj: 3
zone: 0
north: 1N
south: 0
east: 1E
west: 0
cols: 1
rows: 1
e-w resol: 1
n-s resol: 1
top: 1
bottom: 0
cols3: 1
rows3: 1
depths: 1
e-w resol3: 1
n-s resol3: 1
t-b resol: 1

When running d.m, it was able do display the entire map while gis.m showed
only the tiny part. (?)

D.m is even more constrained by the 'computational' region. So it may have
displayed fine prior to the region change. But if you tried to use d.m to
display now, you'd get a 1x1 cell display. You can try this by working from
the command line.
##d.mon start=x0
##d.rast map=[your map]

In the new GUI, the display region is uncoupled from the computational
region. That is, you can zoom in or out in the display without changing the
underlying region for gis computations. Vice versa, you can change the
computational region with g.region and have no impact on the display.

That said, the display region needs something to start with when you fire it
up. So it starts with whatever is in your WIND file. You can change this
interactively with the zoom + and - magnifying glass tools, or with the zoom
pull down. Try this. Add your map as a layer in the GIS Manager.

DON'T PUSH THE DISPLAY BUTTON YET

Select 'zoom to selected map' from the zoom pull down in the display window.
This should let you view your entire map.

From the same pull down, you can set the WIND file to match your display. Or

you can use g.region to set the current region to match the map.

I do not understand how the WIND files can change to these values. Looks
like a default setting for initialisation. While working on the dataset, I
do not remember that I changed something.

my start setup was:

proj: 3
zone: 0
north: 90N
south: 90S
east: 180E
west: 180W
cols: 7200
rows: 3600
e-w resol: 0:03
n-s resol: 0:03
top: 1
bottom: 0
cols3: 1
rows3: 1
depths: 1
e-w resol3: 1
n-s resol3: 1
t-b resol: 1

This looks OK.

It seems that more things have been modified inside the data during the
changes in g.region.

The recent changes in g.region are primarily concerned with getting output
of your current region settings. I don't think that anything (or much) has
changed with the part that actually sets region values.

After correcting the WIND files, I still get this error message when drawing
with "Display active layers":

region for current mapset line 7: <e-w resol:0>

This is weird.

****Wait a minute. I think I know what it is. *******

I've hit this too. This is a bug that I thought was fixed.

If you mess with the e-w resol3 and n-s resol3 (and maybe the t-b resol), it
will completely screw up your region. I *think* you can set the region to
match the map and fix it.

while g.region -p at the command line says:

projection : 3 (Latitude-Longitude)
zone : 0
datum : wgs84
ellipsoid : wgs84
north : 90N
south : 90S
west : 180W
east : 180E
nsres : 0:03
ewres : 0:03
rows : 3600
cols : 7200
cells : 25920000

Right. This is correct, but now your WIND file is "corrupted" because a 3D
resolution setting was changed.

I don't think that this is a GUI problem, but a long-standing one in
g.region.

Well, I just tried to get this to fail with Spearfish and I was unable to do
so. Maybe I didn't mess with the 3D settings in the right (i.e., wrong) way.
Or maybe this is fixed and I don't know what is causing your problem. But
just out of curiosity, did you change the 3D resolution or top/bottom
settings in any way?

This is very confusing to me, as graphic screens die instantly without
further notice. Is there a way to run gis.m inside a debugger?

It is possible if you have a TclTk debugger.

spearfish data as new installed work. It is some kind of inbreeding when
working only on this data set. I used
http://grass.itc.it/newsletter/GRASS_OSGeo_News_vol4-usermap.pdf example.

And I do not understand why the data exchange over the modules is not
encapsulated. Would be more than helpful for grass 7 to become free of the
position of values inside a text stream - as we have seen... :wink:

Not sure what you mean here.

Hope this helps.

Mit freundlichen Grüßen / With kindest regards

Stefan Paulick

http://www.urbeli.com
mailto://stefan.paulick@urbeli.com
/*----------------------*/

Michael Barton schrieb:

Paulick,

Questions are not a nuisance. I just can't answer all of them :wink:

I have to ask you one. This looks like you are trying to run from the
command line. Is this the case? Are the errors being reported to the
terminal? Or is this summarized from the GUI response? (i.e., it is not a
TclTk error format).

One thing that you can do to help isolate the issue is try it with the
Spearfish demo set. If all works with that, there is something problematic
with your data probably. If it fails with Spearfish too, that suggests a
problem with some part of the program.

Also, given the error you have below, I'd trying running g.region -up to see
what you get for extents, resolution, etc. The map may be fine, but your
region may be problematic. One message below is worrisome. It says that you
have the east-west resolution set to 0.

Michael

On 1/3/07 10:58 AM, "Paulick Consult" <stefan.paulick@urbeli.com> wrote:

Michael Barton schrieb:

I've fixed the issues that arose from the changes to g.region and committed
the updates to the cvs.

Yes, it is working again. Thank you very much!

At the risk of being a nuisance: d.rast map=k1 -o fails on a known good map
as following:

PNG: GRASS_TRUECOLOR status: TRUE
PNG: collecting to file:
/home/grassdata/grassuser/user/.tmp/ucon643/24892.0.ppm,
    GRASS_WIDTH=642, GRASS_HEIGHT=465

region for current mapset line 7: <e-w resol:0>
run "g.region"

Mit freundlichen Grüßen / With kindest regards

Stefan Paulick

http://www.urbeli.com
mailto://stefan.paulick@urbeli.com
/*----------------------*/

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

2

On Wed, 3 Jan 2007, Michael Barton wrote:

On 1/3/07 10:13 PM, "Paulick Consult" <stefan.paulick@urbeli.com> wrote:

[...]

And I do not understand why the data exchange over the modules is not
encapsulated. Would be more than helpful for grass 7 to become free of the
position of values inside a text stream - as we have seen... :wink:

Not sure what you mean here.

I don't think, that the problem is the way the data exchange is handled, just that gis.m should be a *little* bit more robust in its handling of the output from g.region and other commands used in a similar way to get information about the GRASS environment. My two recommendations would be:

1. Merge the output of stdout and stderr for any commands called like this, by adding "|& $env(GISBASE)/etc/grocat" to the end of the command line.
Reason: This will stop Tcl bombing out completely if anything is written to stderr (a warning or message, for example).

2. Make the parsing of the command output more robust by actually checking the return value of the regexp command (or whichever other Tcl command is used to parse the output) before acting on it.
Reason: If an unexpected line occurs in the output (e.g. a warning) and it isn't matched by the regexp, then it will be simply skipped over and no action will be taken.

I'm willing to help with examples for these if necessary. I think improving the robustness of gis.m like this would make debugging problems with the GRASS set-up a lot easier.

Paul

3

Hi Paul,

A few thoughts below.

On 1/4/07 7:54 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

I don't think, that the problem is the way the data exchange is handled,
just that gis.m should be a *little* bit more robust in its handling of
the output from g.region and other commands used in a similar way to get
information about the GRASS environment. My two recommendations would be:

I agree about finding ways to increase the robusticity of the GUI. The more
it is used, the more robust it needs to be. And the more robust it is, the
more it will be used.

While specific errors can be trapped if they can be reliably anticipated,
the general TclTk form for error-trapping is the catch command. It is widely
used in the GUI, but could be used in a more sophisticated way to trap and
report errors. TclTk actually does a pretty good job of catching and
reporting errors, returning real information rather than codes. However, it
would better if users could be spared TclTk errors as much as possible.

1. Merge the output of stdout and stderr for any commands called like
this, by adding "|& $env(GISBASE)/etc/grocat" to the end of the command
line.
Reason: This will stop Tcl bombing out completely if anything is written
to stderr (a warning or message, for example).

I think some other solution would be better for two reasons. First, this
construction calls a *nix command from within TclTk. This is problematic for
Windows. A pure TclTk construction would be better. Second, in the most
recent set of problems with g.region, I'm not sure if this would help all
that much anyway. The GUI was reading the text output from g.region -g OK,
the problem is that it was the wrong output. It was expecting [key]=[value].
The first [key] included the warning message. This gave a key that was not
recognizable by the subsequent routine that tried to process the key to get
region values. For this particular routine, a 'catch' command is already in
place to trap real errors and move on. In fact, an error will cause the GUI
to quit relatively gracefully with the GRASS error printed to the terminal.
I implemented this, working with Hamish to solve a recurrent problem that
caused the GUI to give somewhat misleading error messages when GRASS was
improperly installed (usually a gdal installation problem).

This construction probably needs to be used more widely as we identify
potential problem spots. Maybe it is useful wherever a GRASS command is run.
If you have any suggestions or want to check through the code for places you
see as potentially problematic, we can try to beef them up.

2. Make the parsing of the command output more robust by actually checking
the return value of the regexp command (or whichever other Tcl command is
used to parse the output) before acting on it.
Reason: If an unexpected line occurs in the output (e.g. a warning) and it
isn't matched by the regexp, then it will be simply skipped over and no
action will be taken.

This is a good plan if you know what return value you are expecting. In some
places this makes a lot of sense. It is implemented in some places, but
could probably be expanded. It would be worthwhile to identify such spots.

In this particular case, however, g.region produces a lot of possible return
[key][separator][value] lines. The TclTk routine loops through all of them
and puts them into a list that it later uses for all sorts of things. I'm
not sure if it's efficient to check each line against all possible valid
g.region outputs. The loop read the output 'correctly', it just got output
that was subsequently unusable. Moreover, the new warning is in a difficult
to parse location for reading information. IMHO, it should not be there for
'script' style output.

I'm willing to help with examples for these if necessary. I think
improving the robustness of gis.m like this would make debugging problems
with the GRASS set-up a lot easier.

Thanks. This would be very much appreciated. Now that the GUI code is itself
is pretty robust, if we can identify the most likely spots that can result
in crashes when there are other problems, and solve these with pure TclTk
methods (i.e., cross-platform) it will make for a much better piece of
software.

Michael

Paul

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

4

Michael Barton wrote:

> 1. Merge the output of stdout and stderr for any commands called like
> this, by adding "|& $env(GISBASE)/etc/grocat" to the end of the command
> line.
> Reason: This will stop Tcl bombing out completely if anything is written
> to stderr (a warning or message, for example).

I think some other solution would be better for two reasons. First, this
construction calls a *nix command from within TclTk. This is problematic for
Windows. A pure TclTk construction would be better. Second, in the most
recent set of problems with g.region, I'm not sure if this would help all
that much anyway. The GUI was reading the text output from g.region -g OK,
the problem is that it was the wrong output. It was expecting [key]=[value].
The first [key] included the warning message. This gave a key that was not
recognizable by the subsequent routine that tried to process the key to get
region values. For this particular routine, a 'catch' command is already in
place to trap real errors and move on. In fact, an error will cause the GUI
to quit relatively gracefully with the GRASS error printed to the terminal.
I implemented this, working with Hamish to solve a recurrent problem that
caused the GUI to give somewhat misleading error messages when GRASS was
improperly installed (usually a gdal installation problem).

Part of the problem here is that you're running into the limitations
of Tcl/Tk's process management.

AFAICT, Python provides more powerful process management, e.g.
os.popen3 returns separate pipes for each of stdin, stdout, and
stderr, so you don't have to merge or discard stderr.

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