[GRASS-user] GRASS 7 subpixel shift of imported Landsat data

[Nikos Alexandris]

* Tomáš Brunclík <brunclik at atlas.cz> [2015-05-29 13:34:22 +0200]:

> Dne 27.5.2015 v 18:43 Nikos Alexandris napsal(a):
> > * Tomáš Brunclík <brunclik at atlas.cz> [2015-05-27 12:49:13 +0200]:
> >
> >> Hello all,
> >> working with GRASS GIS 7.0.1svn (r65198) @Linux, I noticed, that when
> >> importing two Landsat images from different dates, I often get them
> >> spatially shifted to each other when comparing them in detail - meaning
> >> when you zoom in to about 1:5000 scale and switch the viewed bands, the
> >> features in the map jump by a fraction of pixel size. For Landsat 8
> >> images LC81910252013208 (reflectance product) and LC81910252013224 (DN
> >> product) the shift is about 15m (half the pixel size) in both horizontal
> >> and vertical direction. The same two products imported in GRASS 6.4.4
> >> have no visible shift at all and the corresponding pixels seem to be
> >> perfectly aligned.
> >>
> >> The procedure to reproduce this:
> >>
> >> 1)Download and uncompress this archive (133 MB):
> >> https://dl.dropboxusercontent.com/u/24062833/pixel_shift_208_224.zip
> >> /
> >> The archive contains band 5 of the two above mentioned Landsat scenes,
> >> where the one with DOY 208 (the last number of the scene code,
> >> day-of-year) is from surface reflectance (SR) product, the other with
> >> DOY 224 is digital number (DN) product (I work on a script to
> >> atmospherically correct DN product based on reference SR image)//.//
> >> /
> >>
> >> 2) Start GRASS 7, create new mapset in location with UTM 33N
> >> (EPSG:32633) spatial reference system.
> >>
> >> 3) Import each image, open them in the map, set colors, zoom in and
> >> compare a distinct feature placement in detail:
> >>
> >> #import
> >> r.in.gdal input="/path/to/data/LC81910252013208LGN00_sr_band5.tif"
> >> output=208_grass7
> >> r.in.gdal input="/path/to/data/LC81910252013224LGN00_B5.TIF"
> >> output=224_grass7
> >>
> >> #set the null pixels of the DN band (helps the bands to get similar
> >> color palette in the next step)
> >> r.null map=224_grass7 setnull=0
> >>
> >> #set colors:
> >> r.colors map=208_grass7
> >> r.colors map=224_grass7
> >>
> >>
> >> 4) Zoom in to a distinct feature in about 1:5000 scale (I have used a
> >> pond at coordinates 542365,554675), switch visibility of both images on,
> >> then repeatedly switch on/off the upper image in the stack. You should
> >> see the shift quite clearly. Zooming in even more, it is possible to
> >> measure the shift.
> >>
> > Tomas,
> >
> > I had a quick look. Pixels are perfectly aligned here (after going
> > through all of the steps you mention here) in G7.
> >
> > Which version of GDAL are you on?
> >
> > Nikos
> >
> > [rest deleted]

Tomas:

> Hello,
> I have GDAL 1.6.3 in GRASS 7, GDAL 1.10.1 in GRASS 6. Could it be it? Is 
> the GDAL part of the binary snapshot download, or does it uses one 
> already on my system? My GRASS 7 is binary snapshot download, GRASS 6 is 
> installed from Debian packages coming from my distro repository.
> Tried again with newly created location and mapset, the same result.
 
> My GRASS 7 details:
> Verze GRASSu: 7.0.1svn
> Revize SVN GRASSu:: 65198
> Datum sestavení: 2015-05-09
> Platforma sestavení: x86_64-unknown-linux-gnu
> GDAL/OGR: 1.6.3
> PROJ.4: 4.7.0
> GEOS: 3.2.0
> SQLite: 3.7.13
> Python: 2.7.5+
> wxPython: 3.0.1.1
> Platforma: Linux-3.11-2-amd64-x86_64-with-LinuxMint-1-debian
> 
> My GRASS 6 details:
> GRASS version: 6.4.4
> GRASS SVN Revision:
> GDAL/OGR: 1.10.1
> PROJ4: Rel. 4.8.0, 6 March 2012
> Python: 2.7.5+
> wxPython: 3.0.1.1
> Platform: Linux-3.11-2-amd64-x86_64-with-LinuxMint-1-debian

I can't tell for sure, unless we test it.  Don't you have access to
GRASS7 with latest GDAL?  Couldn't you simply try the latest OSGeo-Live?
Shouldn't take too much time to install virtualbox, get the virtual
machine, and launch GRASS there.  There is only some small number of
steps to create a shared directory between host and guest.

Anyone else on the matter?

Cheers, Nikos