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

Michael Barton michael.barton at asu.edu
Thu Jan 4 00:42:23 EST 2007


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 at 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... ;-)

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 ;-)
>> 
>> 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 at 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






More information about the grass-dev mailing list