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

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.

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@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

On Fri, Jun 8, 2012 at 8:26 PM, Michael Barton <michael.barton@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@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev