[GRASS-dev] d.m/d.gis mysteries..

[Michael Barton]

Moritz,

Here's the long story. Skip to the bottom for the short story.

The image in the TclTk canvas is a PPM graphic with a number of pixels
related to your individual screen characteristics, and the size and geometry
of the display window.

To zoom interactively, a box (or the equivalent) is drawn that has extents
in pixels. The ratio between the extents in pixels of the zoom box and the
extents in pixels of the display window is used to calculate the ratio
between the extents (in meters or degrees) of the original display region
and the new, zoomed display region (in meters or degrees). Due to request
from the developer community, g.region is run with the -a flag to align the
new region with the grid, however this is done inside g.region. Also, screen
pixels and grid squares (columns and rows) are always integers, but the
ratio of old to new size and region extents can be floating point numbers.

The new display region extents are used to generate new PPM graphic whose
numbers of pixels and geometry (in pixels) must fit into the display canvas
in pixels. The output graphic must fit into the minimum window dimension so
that you can see all of the displayed region.

An interactive zoom box will usually cut across grid squares--in terms of
its pixel to meter/degree conversion. If the grid squares are very small
relative to a pixel size (maybe even smaller than a pixel, which is often
the case for a displayed map), you won't notice this of course. A new region
will be calculated for display based on the conversion ratios and
calculations, modified by the g.region alignment algorithm.

If grid squares are large relative to display pixels, however, you can see a
zoom box cutting across grid squares. But, of course, the zoom box is only a
graphic object in pixels and "knows" absolutely nothing about grid squares
that you see in the display, because in the canvas they, too, are only bunch
of undifferentiated pixels in the displayed graphic. It still calculates a
ratio of box extent to display canvas extent, and uses this ratio to
calculate the new region from the old region. This is resized and realigned
by g.region -a to what it considers the nearest grid cell border for each
extent. A new graphic image is created that has the proper number of pixels
to fit into the display window. The relevant calculation are handled by the
GRASS PNG display driver. This PPM image (with it's representation of grid
squares as pixel groups) is finally displayed in the canvas.

Given all this, it is not surprising that, if you interactively zoom into a
map to display a few grid squares, you may not see in the display the exact
number of grid squares that you thought you might get. There have been pixel
to grid unit conversions, realignment of the region to fall along grid
square boundaries, and recalculation of the PPM image size into pixels for
display at least. If you really want to know the exact extents, you need to
call up the display region menu item and it will give you correct the
display region extents. These WILL be copied to the WIND file if you set
WIND file from the currently display region. But what gets shown on the
display may indeed vary by a grid square or two.

The rows and columns shown at the bottom are a convenience feature. Because
the text output from g.region that writes out extents in the proper format
to set the display region when in lat/lon does not also write out rows and
columns count, the rows and columns are calculated from the extents divided
by the resolution, and rounded to the nearest integer. Otherwise, g.region
would have to be run and parsed twice for every redisplay (including every
display window resize). This calculation is pretty accurate
(percentage-wise) when a lot of grid squares are represented in the display.
It has an increasing chance of a large percentage error (4 cells instead of
5) when very few cells are represented. Also, it is reporting the number of
rows and columns in the display region, but it cannot know how many grid
squares actually end up on the PPM image that is displayed after g.region -a
is run  and the PNG driver creates an image. Hopefully, this explains what
is going on.

The short answer: 

If you want to know exactly the extents of the display region and the number
of columns and rows, use the display region information from the menu. If
you want to exactly set the region extents, use g.region. Interactive
zooming can get you pretty close, quickly and easily. For high precision,
use the g.region module that was designed for this.


Cheers
Michael
__________________________________________
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



> From: Moritz Lennert <mlennert at club.worldonline.be>
> Date: Sat, 28 Oct 2006 15:32:10 +0200
> To: Maciej Sieczka <tutey at o2.pl>
> Cc: Hamish <hamish_nospam at yahoo.com>, <grass-dev at grass.itc.it>, Michael Barton
> <michael.barton at asu.edu>
> Subject: Re: [GRASS-dev] d.m/d.gis mysteries..
> 
> Maciej Sieczka wrote:
>> Hamish wrote:
>>>> Michael Barton wrote:
>>>>> I'd be in favor of dropping d.m from 6.3.
>>> Maciej Sieczka wrote:
>>>> And I wouldn't. There are continous problems with region handling in
>>>> gis.m that make me use d.m still for production. If d.m is removed
>>>> from 6.3 I would use 6.2 often, which would make me less up to date
>>>> with 6.3 developement and less capable of reporting bugs/fixing minor
>>>> problems.
>>> When 6.2.0 is released, with gis.m as default, we are tacitly declaring
>>> it "ready for production". If you feel there are still significant
>>> region handling problems with 6.2.0rc3, please supply details.
>> 
>> Take the 'slope' raster map from spearfish (for example). Zoom in until
>> you see ~ 8 or 6 cells. You will see:
>> 
>> 1. Cell's shape is distorted (not square).
>> 
>> 2. The number of rows and cols declared in the status bar in the bottom
>> of the Map Display window doens't reflect what is actually displayed.
>> 
>> 3. Now set current WIND to match the Map Display. Display the same
>> raster in X monitor - what you see in X monitor and gis.m's Map Display
>> window is different. Moreover, g.region -p reports a different number
>> of rows and cols than the Map Display's status bar, too.
> 
> A nice exercise to do is to zoom to a few pixels, save the current
> display to the WIND file and then zoom to current region. The latter
> generally has a larger extent than what was displayed...
> 
> Moritz