[GRASS-dev] shifting maps created with r.mapcalc

Markus Metz markus.metz.giswork at googlemail.com
Fri Jun 8 11:53:57 PDT 2012


On Fri, Jun 8, 2012 at 8:26 PM, Michael Barton <michael.barton at asu.edu> wrote:
> I've run into an odd issue that could be a problem for anyone needing precise calculations from a landsat (or possibly other) image.
>
> I have a landsat ETM image with a resolution of 28.5m for the bands 1-5, 7 and resolution of of 14.25m for band 8. If I set the region to exactly match one of the landsat channels (g.region rast=landsat_band8, for example) and copy the image with r.mapcalc (r.mapcalc expression='new_band8=landsat_band8'), GRASS produces an exact copy.
>
> However, if I set the region in other ways (e.g., via g.region setting the bounds, interactively in the GUI) any copy of the image made with r.mapcalc is shifted by half a cell. This happens whether or not I set the -a (align) flag.

Since r.mapcalc operates on the current region, and r.mapcalc produces
a correct result with g.region rast=landsat_band8, I would recommend
not to use the -a flag, but use g.region align=landsat_band8 after
setting the region in other ways. The GUI can not make use of the
align option itself because it does not know how the previous region
has been set.

HTH,

Markus M

>
> This does not seem to be a problem for another landsat with a 15m resolution (that is, not a fraction of a meter).
>
> Has anyone else run into this? Any ideas?
>
> I'm working with GRASS 7 compiled a couple days ago.
>
> Michael
>
>
> On Jun 8, 2012, at 1:26 AM, Markus Neteler wrote:
>
>> This is definitely for grass-dev. Perhaps an issue in the Python interface?
>> But it would be important to know what " if I set the region any other way"
>> exactly means.
>>
>> Markus
>>
>> On Fri, Jun 8, 2012 at 6:54 AM, Michael Barton <michael.barton at asu.edu> wrote:
>>> In trying to figure out why I was getting some odd results in the sharpening
>>> algorithms, I discovered a weird problem.
>>>
>>> I've zoomed in on a landsat to run the pan sharpening routines faster (to
>>> test various changes in the code) and see in better detail the results. When
>>> I make a copy of the panchromatic map, I find that the copy is shifted by
>>> 1/2 cell from the original. If I set region to exactly match all of the pan
>>> map (g.region rast=pan), there is no shift. But if I set the region any
>>> other way, there is a 1/2 cell shift. This means that every map I make will
>>> not align with my original landsats. This causes problems in the sharpening
>>> algorithms in different places. The worst seems to be in the PCA
>>> sharpening. I've quit GRASS and restarted and this shift is still there. It
>>> doesn't seem to matter whether I use the -a flag or not in g.region.
>>>
>>> Is this a known issue? Is there some way around it?
>>>
>>> Michael
>>> _____________________
>>> C. Michael Barton
>>> Visiting Scientist, Integrated Science Program
>>> National Center for Atmospheric Research &
>>> University Consortium for Atmospheric Research
>>> 303-497-2889 (voice)
>>>
>>> Director, Center for Social Dynamics & Complexity
>>> Professor of Anthropology, School of Human Evolution & Social Change
>>> Arizona State University
>>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>>>
>>>
>>>
>>>
>>>
>
> _____________________
> C. Michael Barton
> Visiting Scientist, Integrated Science Program
> National Center for Atmospheric Research &
> University Corporation for Atmospheric Research
> 303-497-2889 (voice)
>
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Arizona State University
> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev


More information about the grass-dev mailing list