[GRASS-user] mosaic with landsat geotiff

GRASS GRASS user
,
1

Hi everyone, i'm a relatively new user of GRASS (version 6.2.2, 2007;
i'm using it since july 2007) and i have the following problems:

I'm trying to join different landsat5 rasters, as in a mosaic
(imported as geotiff, and downloaded from
http://www.dgi.inpe.br/CDSR/). [These images come labeled by the orbit
of the satellite and the "point", which is the number of image of the
sequence of said orbit, and are in UTM projection (resolution 30m x
30m)]

So, my problems are:

1- With r.patch i can join images from the same orbit (eg orbit: 222,
points: 82,83), but the resulting map is not quite right: the
overlapping region of the images are not well positioned (i thought
that r.patch would correct this difference). [See below for different
orbits...]
2- With i.image.mosaic a can't even see the resulting raster map (just
a blank image, even if the Query tool gives normal values in the zone
that's expected).

Also, when i try to import another map, but from a different landsat5
orbit (223), which happens to be in a different UTM zone (-22, being
-21 the zone of my original map) i have this output:

r.in.gdal -e 'input=/home/mastermind/Documents/Proyecto Invasiones/LANDSAT/LANDSAT_5_TM_20070602_222_082_L2_BAND1.tif' output=ejemplo

A datum name sam69 (South_American_Datum_1969) was specified without
transformation parameters.
WARNING: Non-interactive mode: the GRASS default for sam69 is
         towgs84=-57.000,1.000,-41.000.
ERROR: Projection of dataset does not appear to match current location.

       LOCATION PROJ_INFO is:
       name: Universe Transverse Mercator
       proj: utm
       datum: sam69
       towgs84: -60.0,-2.0,-41.0
       a: 6378160
       es: 0.006694605328567784
       zone: 21
       south: defined
       no_defs: defined

       Dataset PROJ_INFO is:
       name: Universe Transverse Mercator
       proj: utm
       datum: sam69
       a: 6378160
       es: 0.006694605328567784
       zone: 22
       south: defined
       no_defs: defined

       ERROR: zone

       You can use the -o flag to r.in.gdal to override this check and use
       the location definition for the dataset.
       Consider generating a new location from the input dataset using the
       'location' parameter.

I've tried with the -o flag but, not surprisingly, the imported map
was in a completely wrong position (far to the west of my original
map, when it was supposed to be eastwards from it). The r.patch option
was tried also in this scenario, in vain of course.

3- I thougth of yet another option: import all these images into
another location, which is big enough to put all others inside* , for
which i tried r.proj, but i get this:

r.proj input=223_B location=landsat5_sriptR mapset=jmb dbase=/home/mastermind/GRASSDATA output=ejemplo2 method=nearest

PROJ_INFO file not found for location worldclim
ERROR: Can't get projection info of output map

(something similar happens when i try using the landsat5 location as
the destination of r.proj)

so i researched and found that g.setproj would create a PROJ_INFO
file, but i got this instead:

g.setproj

XY-location cannot be projected.

*a map from http://www.worldclim.org/, which "... are in geodetic
coordinate system (not projected, i.e., 'GEOGRAPHIC' or 'LATLONG'
system). The datum is WGS84...." and have a resolution of 30 seconds.

here is some more information:

My landsat5 location (again):
projection: 1 (UTM)
zone: -21
datum: sam69
ellipsoid: a=6378160 es=0.006694605328567784
north: 6651449.91031
south: 6160670.08969
west: 158330
east: 827030
nsres: 30.00060032
ewres: 30
rows: 16359
cols: 22290
cells: 364642110

My system (don't think it's relevant, but anyway...):
OS: Linux 2.6.18.2-34-default i686,
System: openSUSE 10.2 (i586), using KDE: 3.5.5 "release 45".
Processor (CPU): Intel(R) Pentium(R) D CPU 2.80GHz
Speed: 2,799.90 MHz
Total memory (RAM): 1,003.06 MB
Free memory: 16.01 MB (+ 549.73 MB Caches)

well, i hope someone can give me any help on this, i would be
immensely grateful for it,

Juan Manuel Barreneche
Zoología de Vertebrados,
Facultad de Ciencias,
Universidad de la República,
Uruguay.

2

Juan,

Have you checked if the georreferencing on those images are correct? I
was once told that the CBERS images available from INPE had only the
center point with the correct georreferencing. The rest was up to the
user. Could that be the problem you are seeing with r.patch? Don't
know if the same is true for the landsat images. Maybe someone that
uses images from INPE could shed more light into the issue.

Cheers
Daniel

On Thu, May 8, 2008 at 9:06 PM, Juan Manuel Barreneche
<jumanbar@gmail.com> wrote:

Hi everyone, i'm a relatively new user of GRASS (version 6.2.2, 2007;
i'm using it since july 2007) and i have the following problems:

I'm trying to join different landsat5 rasters, as in a mosaic
(imported as geotiff, and downloaded from
http://www.dgi.inpe.br/CDSR/). [These images come labeled by the orbit
of the satellite and the "point", which is the number of image of the
sequence of said orbit, and are in UTM projection (resolution 30m x
30m)]

So, my problems are:

1- With r.patch i can join images from the same orbit (eg orbit: 222,
points: 82,83), but the resulting map is not quite right: the
overlapping region of the images are not well positioned (i thought
that r.patch would correct this difference). [See below for different
orbits...]
2- With i.image.mosaic a can't even see the resulting raster map (just
a blank image, even if the Query tool gives normal values in the zone
that's expected).

Also, when i try to import another map, but from a different landsat5
orbit (223), which happens to be in a different UTM zone (-22, being
-21 the zone of my original map) i have this output:

r.in.gdal -e 'input=/home/mastermind/Documents/Proyecto Invasiones/LANDSAT/LANDSAT_5_TM_20070602_222_082_L2_BAND1.tif' output=ejemplo

A datum name sam69 (South_American_Datum_1969) was specified without
transformation parameters.
WARNING: Non-interactive mode: the GRASS default for sam69 is
        towgs84=-57.000,1.000,-41.000.
ERROR: Projection of dataset does not appear to match current location.

      LOCATION PROJ_INFO is:
      name: Universe Transverse Mercator
      proj: utm
      datum: sam69
      towgs84: -60.0,-2.0,-41.0
      a: 6378160
      es: 0.006694605328567784
      zone: 21
      south: defined
      no_defs: defined

      Dataset PROJ_INFO is:
      name: Universe Transverse Mercator
      proj: utm
      datum: sam69
      a: 6378160
      es: 0.006694605328567784
      zone: 22
      south: defined
      no_defs: defined

      ERROR: zone

      You can use the -o flag to r.in.gdal to override this check and use
      the location definition for the dataset.
      Consider generating a new location from the input dataset using the
      'location' parameter.

I've tried with the -o flag but, not surprisingly, the imported map
was in a completely wrong position (far to the west of my original
map, when it was supposed to be eastwards from it). The r.patch option
was tried also in this scenario, in vain of course.

3- I thougth of yet another option: import all these images into
another location, which is big enough to put all others inside* , for
which i tried r.proj, but i get this:

r.proj input=223_B location=landsat5_sriptR mapset=jmb dbase=/home/mastermind/GRASSDATA output=ejemplo2 method=nearest

PROJ_INFO file not found for location worldclim
ERROR: Can't get projection info of output map

(something similar happens when i try using the landsat5 location as
the destination of r.proj)

so i researched and found that g.setproj would create a PROJ_INFO
file, but i got this instead:

g.setproj

XY-location cannot be projected.

*a map from http://www.worldclim.org/, which "... are in geodetic
coordinate system (not projected, i.e., 'GEOGRAPHIC' or 'LATLONG'
system). The datum is WGS84...." and have a resolution of 30 seconds.

here is some more information:

My landsat5 location (again):
projection: 1 (UTM)
zone: -21
datum: sam69
ellipsoid: a=6378160 es=0.006694605328567784
north: 6651449.91031
south: 6160670.08969
west: 158330
east: 827030
nsres: 30.00060032
ewres: 30
rows: 16359
cols: 22290
cells: 364642110

My system (don't think it's relevant, but anyway...):
OS: Linux 2.6.18.2-34-default i686,
System: openSUSE 10.2 (i586), using KDE: 3.5.5 "release 45".
Processor (CPU): Intel(R) Pentium(R) D CPU 2.80GHz
Speed: 2,799.90 MHz
Total memory (RAM): 1,003.06 MB
Free memory: 16.01 MB (+ 549.73 MB Caches)

well, i hope someone can give me any help on this, i would be
immensely grateful for it,

Juan Manuel Barreneche
Zoología de Vertebrados,
Facultad de Ciencias,
Universidad de la República,
Uruguay.
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

3

Juan Manuel Barreneche pisze:

[These images come labeled by the orbit
of the satellite and the "point", which is the number of image of the
sequence of said orbit, and are in UTM projection (resolution 30m x
30m)]

Juan,

Different UTM zones are different coordinate systems. If you want to uses data form two different UTM zones you need to reproject them into a common coordinate system first. Finding such a system is up to you.

Reprojection can be accomplished with gdalwarp. If you need to do it in GRASS there is r.proj.

Maciek

4

First i want to thank for all those who tryied to help.

Unfortunately i'm still stucked with the mosaic problem: landsat images taken
in different days won't overlay well, and i can't find a way to force them...
isn't there an easy way to correct this by knowing the date of the image and
how much the satellite shifts it's position each time it passes the same
spot? or maybe another way??

thank you all,

JM

PD.. to the answers of Daniel and Maciej (or Maciek?):

Daniel: seeing that the images taken on the same day (and the same orbit) do
fit perfectly, i tend to think that what happens with CBERS images do not
happen with landsat5 images, but that's just a guess (else, i suppose that
the boundaries wouldn't be goerreferenced and hence, wouldn't fit in the
mosaic).

Maciek: i tryied to deal with that problem and created another location, where
i succesfully reprojected my landsat images. The thing is, i still have the
overlay problem...

El Viernes, 9 de Mayo de 2008 04:10, Maciej Sieczka escribió:

Juan Manuel Barreneche pisze:
> [These images come labeled by the orbit
> of the satellite and the "point", which is the number of image of the
> sequence of said orbit, and are in UTM projection (resolution 30m x
> 30m)]

Juan,

Different UTM zones are different coordinate systems. If you want to
uses data form two different UTM zones you need to reproject them into a
common coordinate system first. Finding such a system is up to you.

Reprojection can be accomplished with gdalwarp. If you need to do it in
GRASS there is r.proj.

Maciek

5

On Tue, 2008-05-20 at 15:19 -0300, Juan Manuel Barreneche wrote:

First i want to thank for all those who tryied to help.

Unfortunately i'm still stucked with the mosaic problem: landsat images taken
in different days won't overlay well, and i can't find a way to force them...

Juan,

as I read in the other thread (entitled: value differences between
landsat images), you already geo-referenced your images but you still
have a significant shift (?).

How did you do your geo-referencing?

Is your area mountainous? Do you have elevation data?

If yes, you could try to incorporate z-data and ortho-rectify the
images. My small experience with SPOT images suggest to use elevation
data to get better results.

Nikos