Dear Dorit,
(cc list)
I think that we understood and solved (to some extent) the
problem. It's not the culprit of GDAL, nor of i.in.spotvgt.
When I import the map, I get (I tested the temporal VRT
file which is usually removed):
gdalinfo $HOME/grassdata/latlong/neteler/.tmp/bartok/22083.0.vrt
Driver: VRT/Virtual Raster
Size is 40320, 14673
Coordinate System is:
GEOGCS["wgs84",
DATUM["WGS_1984",
SPHEROID["wgs84",6378137,298.257223563],
TOWGS84[0.000,0.000,0.000]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]]
Origin = (-180.004464,75.004464)
Pixel Size = (0.00892857,-0.00892857)
Corner Coordinates:
Upper Left (-180.0044643, 75.0044643) (180d 0'16.07"W, 75d 0'16.07"N)
Lower Left (-180.0044643, -56.0044639) (180d 0'16.07"W, 56d 0'16.07"S)
Upper Right ( 179.9955346, 75.0044643) (179d59'43.92"E, 75d 0'16.07"N)
Lower Right ( 179.9955346, -56.0044639) (179d59'43.92"E, 56d 0'16.07"S)
Center ( -0.0044649, 9.5000002) ( 0d 0'16.07"W, 9d30'0.00"N)
Band 1 Block=128x128 Type=Byte, ColorInterp=Gray
NoData Value=0
#zoom to map
g.region rast=0001_NDV -p
projection: 3 (Latitude-Longitude)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: 75:00:16.071429N
south: 56:00:16.069919S
west: 179:59:43.928571E
east: 179:59:43.924424E
nsres: 0:00:32.142857
ewres: 0:00:32.142857
rows: 14673
cols: 40320
This is reasonable and correct. The SPOT coordinates refer to
the pixel *center* (see SPOT FAQ), so the i.in.spotvgt performs
a fix for that (GRASS and GDAL want corner coordinates).
The trick to export the data is to reset the region to world view,
then export with a real GRASS command (not the r.out.gdal script which
is a wrapper to gdal_translate which uses the GDAL-GRASS plugin which
doesn't respect the g.region settings...).
To solve the export shift problem:
i.in.spotvgt ...
#reset zoom window:
g.region w=180W e=180E n=75:00:16.071429N s=56:00:16.069919S res=0:00:32.142857 -p
# export:
r.out.tiff -t 0001_NDV out=spotndvi
The resulting spotndvi.tif and spotndvi.tfw nicely overlap (now) with
VMAP0 vector data.
I have no idea how to solve it for r.out.gdal (one could think of
deleting the column with -180.x position which I dislike), it would
be better if someone wrote a C implementation of r.out.gdal
which respects the user region settings.
If you want to have a GeoTIFF or IMG file, simply use gdal_translate
on the result of r.out.tiff.
I hope that this resolves your problem.
Cheers
Markus
On Tue, Jan 31, 2006 at 11:41:29AM +0100, Gross, Dorit (SDRN) wrote:
Dear Markus,
thank you very much for your answer and the time you have spent for testing.
Also many thanks for contacting the developers group and I'm definitively
interested in the outcome. Therefore, I would appreciate it a lot if you
could give me a little note once a solution has been found.
To answer your question: We have started to use Grass for the automatisation
of some image processing that we need here in house and further to set up a
new map service of satellite images that we have available at FAO. Because
data storage is based on geotiffs, we import the images into Grass, do the
processing and export them as geotiffs again. So the import/export thing is
only the frame around the actual workI do it in this way, because I
haven't seen another possibility to process the images directly as geotiffs
in Grass. If you have a better idea how to proceed, your suggestions would be
very much welcome.At the end another short question. You pointed out that GDAL might cause the
troubles. Would you like me to forward the issue also to the GDAL group (I
haven't done yet) or are you maybe in contact about it already?Have a nice day,
Dorit-----Original Message-----
From: Markus Neteler [mailto:neteler@itc.it]
Sent: 26 January 2006 16:47
To: Gross, Dorit (SDRN)
Subject: Re: [GRASSLIST:9903] Re: GeoTiffs shifted by 360 degrees after
processing in GRASSHi Dorit,
sorry for the delay.
I have now imported with i.in.spotvgt the world SPOT and confronted with
VMAP0 vector data. Looks good to me (see screenshot attached). So we can
assume that the import sort of works:g.region rast=0001_NDV -p
projection: 3 (Latitude-Longitude)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: 75:00:16.071429N
south: 56:00:16.069919S
west: 179:59:43.928571E
east: 179:59:43.924424E
nsres: 0:00:32.142857
ewres: 0:00:32.142857
rows: 14673
cols: 40320g.region -c
Decimal degree (East/North positive, West/South negative): region center
northing: 9.500000 region center easting: 359.995535I still see small deviations there, I have to check if the precision is high
enough within the script (IMHO LatLong coordinates are really messy in
general, but well). Upon quick inspection of the GDAL-VRT file (my trick to
geocode it) I cannot see any problem there. Maybe its GDAL or r.in.gdal which
aren't precise enough. Unfortunately I have little time now and suggest to
discuss this in the mailing list again.Now the export story:
r.out.gdal: WARNING: the tool export maps *as they are* in GRASS Since this
maps is stored as cat
/ssi0/ssi/neteler/grassdata/latlong/neteler/cellhd/0001_NDV
proj: 3
zone: 0
north: 75:00:16.071429N
south: 56:00:16.069919S
east: 179:59:43.924424E
west: 179:59:43.928571E
cols: 40320
rows: 14673
e-w resol: 0:00:32.142857
n-s resol: 0:00:32.142857
format: 0
compressed: 1these settings will also be used by r.out.gdal (which is a shell script
wrapper to gdal_translate). If this doesn't work, it's GDAL or the GRASS-GDAL
plugin which may cause troubles. I tried, but after generating more than 2GB
I killed the process.TIFF:
r.out.tiff -t 0001_NDV out=0001_NDVti
does not work. You are right, the coordinates are messed up. Implementing
debug outputr.out.tiff -t 0001_NDV out=0001_NDVti
D0/0: N:75.004464 S:-56.004464
D0/0: W:179.995536 E:539.995535we see that the global wrap around isn't handled correctly. Bad!
BTW: Note that r.out.tiff does not support floating point.I have written to the developers list. Thanks for pointing
that out.One question only: why do you want to import, then export?
Best
Markus
On Mon, Jan 23, 2006 at 02:28:51PM +0100, Gross, Dorit (SDRN) wrote:
> Hi Markus,
>
> Please excuse that I haven't been clear in my previous email. I did
> again some checks and calculations of the corner coordinates (see
> comments below). In my opinion it is not the import that causes the
> shift by 360 degree but the export from Grass to GeoTiff. I did a test
> with a single Spot image, which I imported twice: one time with your
> procedure and another time with mine. The info about the georeference
> for both imported images you have seen already. If both images are
> exported now from Grass into a GeoTiff, both of them get shifted by
> 360 degree ... independently from the way of import. So if I am not
> mistaken, it is the export that causes the shift and not the import.
> Please understand, that I would be happy to use your procedure for the
> import of the Spot Vgt, but it actually doesn't solve my problem of
> the export, since also these images get shifted the same during the
> export.
>
> There is now a SPOT VGT Zip file on your ftp for testing. I also
> uploaded the script that I use in case you would like to have a look.
> Please have also a look at the comments that I made.
>
> Kind regards,
> Dorit
>
>
> > -----Original Message-----
> > From: Markus Neteler [mailto:neteler@itc.it]
> > Sent: 20 January 2006 16:13
> > To: Gross, Dorit (SDRN)
> > Subject: Re: [GRASSLIST:9903] Re: GeoTiffs shifted by 360
> > degrees after processing in GRASS
> >
> >
> > Hi Dorit,
> >
> > On Fri, Jan 20, 2006 at 11:30:37AM +0100, Gross, Dorit (SDRN) wrote:
> > > Hi Markus,
> > >
> > > I used gdal_translate to generate the Geotiff and imported them
> > > afterwards into Grass. Basically I do there the same as you
> > do in the
> > > import part of the i.in.spotvgt script ... just in a more
> > manual way.
> > > That means I take the corner coordinates given by the log
> > file and add
> > > 1/2 a pixel to each coordinate.
> > >
> > > GEO_UPPER_LEFT_LAT +075.000000 -> 75.0044643
> > > GEO_UPPER_LEFT_LONG -180.000000 -> -180.0044643
> >
> > Probably, it should be:
> > GEO_UPPER_LEFT_LONG -180.000000 -> 179.9955
> >
> > > GEO_LOWER_RIGHT_LAT -056.000000 -> -56.0044643
> > > GEO_LOWER_RIGHT_LONG +179.991071 -> 179.9955353
> >
> >
> > > This takes into account that Spot references a pixel in the
> > > centre.
> > > Instead Gdal uses the very much UL and LR corners of the
> > image for the
> > > import. I had a look at your script and it takes into
> > account the same
> > > assumption.
> >
> > Yes, but IMHO you have to take account for the global wrap around
> > *manually* when using the manual procedure.
> >
>
> Also I am aware of the fact that -180.0044643 does not exist and I
> tried already to use 179.9955357 instead of -180.0044643. But have a
> look at what is happening to the pixel size then:
>
> /usr/local/gislibs/bin/gdalinfo dv_temp1.tif
> Driver: GTiff/GeoTIFF
> Size is 40320, 14673
> ...
> Origin = (179.995536,75.004464)
> Pixel Size = (-0.00000000,-0.00892857)
> Metadata:
> AREA_OR_POINT=Area
> valid_range=0, 255
> Corner Coordinates:
> Upper Left ( 179.9955357, 75.0044643) (179d59'43.93"E, 75d
> 0'16.07"N) Lower Left ( 179.9955357, -56.0044643) (179d59'43.93"E,
> 56d 0'16.07"S) Upper Right ( 179.9955353, 75.0044643)
> (179d59'43.93"E, 75d 0'16.07"N) Lower Right ( 179.9955353, -56.0044643)
(179d59'43.93"E, 56d 0'16.07"S)
> Center ( 179.9955355, 9.5000000) (179d59'43.93"E, 9d30'0.00"N)
>
> The image gets squeesed into a fraction of a degree. The only way to
> work it around was to use the -180.xx degrees.
>
> > >
> > > I made a test by importing a Spot-Veg image into Grass
> > using both ways
> > > ... your script and the one that I generated. I compared then the
> > > georeference of both images in Grass with r.info. They are
> > basically
> > > the same:
> > >
> > > Corner coordinates using i.in.spotvgt:
> > > | Rows: 14673
> >
> > > | Columns: 40320
> >
> > > | Total Cells: 591615360
> >
> > > | Projection: Latitude-Longitude (zone 0)
> >
> > > | N: 75:00:16.071429N S: 56:00:16.069919S
> > Res: 0:00:32.14285
> > > | E: 179:59:43.924424E W: 179:59:43.928571E
> > Res: 0:00:32.142
> > >
> > > Corner coordinates using gdal_translate and r.in.gdal:
> > > | Rows: 14673
> > > |
> > > | Columns: 40320
> > > |
> > > | Total Cells: 591615360
> > > |
> > > | Projection: Latitude-Longitude (zone 0)
> > > |
> > > | N: 75:00:16.071429N S: 56:00:16.071429S
> > Res: 0:00:32.14285
> > > |
> > > | E: 179:59:43.927029E W: 179:59:43.928571E
> > Res: 0:00:32.142
> > > |
> >
> > But you see that they are not identical.
> >
>
> You are right that they are not identical. Also I have seen that the
> South and East coordinates are not the same. OK so lets calculate the
> corner coordinates taking resolution and coordinates from the Log
> file:
>
> Resolution:
> 0.008928571 (decimal degrees from Log file)
> it equals to: 0:00:32.14285704 --> 1/2 pix = 16.07142852 (in dd:mm:ss)
>
> Resulting corner coordinates:
> N: 75:00:00N --> 75:00:16.07142852N
> S: 56:00:00S --> 56:00:16.07142852S
> E: 179:59:27.8556E --> 179:59:43.92702852E
> W: 180:00:00W --> 179:59:43.92857148E
>
> Maybe I am completely mistaken but to me the coordinates of the second
> approach look correct. Still it is the West coordinate that causes the
> problems and this coordinate is identical in both cases.
>
>
> > I have imported lots of SPOT VGT and also compared coastlines etc.
> > See references (I started in 2004 to solve SPOT-HDF format
> > problems):
> >
> >
> > http://lists.maptools.org/pipermail/gdal-dev/2004-August/threa
> > d.html#3955
> >
> >
> > > During the export as a Geotiff the same happens to both images and
> > > they get shifted by 360 degrees.
> >
> > In my opinion due to the above missing change to -179.xx degree.
> >
>
> Assuming that you mean +179.xx ... you saw what happens to the pixel
> resolution when converting the HDF into GeoTiff with this coordinate.
> And as far as I understood from the header, Grass interpretates the
> west coordinate -180.xxW correctly and converts it into +179.xxE (see
> the corner coordinates above). This coordinate is the same for both
> imports. It is then the export that shifts the images. Apparently the
> procedure starts exporting from the image's west coordinate, which is
> 179.xxE, and adds the following 360 degrees without considering the
> wrap around.
>
>
> > > Corner coordinates after the export using r.out.gdal: Upper Left
> > > ( 179.9955357, 75.0044643) (179d59'43.93"E, 75d
> > > 0'16.07"N) Lower Left ( 179.9955357, -56.0044643)
> > (179d59'43.93"E, 56d 0'16.07"S)
> > > Upper Right ( 539.996, 75.004) (539d59'43.93"E,
> > 75d 0'16.07"N)
> > > Lower Right ( 539.996, -56.004) (539d59'43.93"E,
> > 56d 0'16.07"S)
> > > Center ( 359.996, 9.500) (359d59'43.93"E,
> > 9d30'0.00"N)
> > >
> > > It seems that Spot-Veg can be imported properly, but the
> > export cannot
> > > handle the -180.0044... West coordinate.
> >
> > Right, because it's non-existing on Earth. Maybe some software
> > packages have tricks implemented to accept it, but it's not right
> > IMHO.
> >
> > > By the way, the longitude of the centre pixel is correct because
> > > of: W = -180.000000 and E = 179.991071 the centre is -0.004464
> > instead of 0.00
> > > You find the centre coordinates also written in the Log file.
> >
> > OK, I have V2KRNS10__20041221_NDVI__Europe.ZIP here:
> >
> > unzip ../V2KRNS10__20041221_NDVI__Europe.ZIP
> > Archive: ../V2KRNS10__20041221_NDVI__Europe.ZIP
> > creating: 0001/
> > inflating: 0001/0001_LOG.TXT
> > inflating: 0001/0001_RIG.TXT
> > inflating: 0001/0001_QL.TIF
> > inflating: 0001/0001_NDV.HDF
> > inflating: 0001/0001_SM.HDF
> > inflating: PHYS_VOL.TXT
> >
> > grep -i CENTER 0001/0001_LOG.TXT
> > CARTO_CENTER_X 25.500000
> > CARTO_CENTER_Y 50.000000
> > IMAGE_CENTER_ROW 2801.0
> > IMAGE_CENTER_COL 4089.0
> >
> > grep CARTO 0001/0001_LOG.TXT
> > CARTO_UPPER_LEFT_X -11.000000
> > CARTO_UPPER_LEFT_Y 75.000000
> > CARTO_UPPER_RIGHT_X 62.000000
> > CARTO_UPPER_RIGHT_Y 75.000000
> > CARTO_LOWER_RIGHT_X 62.000000
> > CARTO_LOWER_RIGHT_Y 25.000000
> > CARTO_LOWER_LEFT_X -11.000000
> > CARTO_LOWER_LEFT_Y 25.000000
> > CARTO_CENTER_X 25.500000
> > CARTO_CENTER_Y 50.000000
> > CARTO_HEIGHT 50.000000
> > CARTO_WIDTH 73.000000
> >
> > Now let's import it:
> >
> > GRASS 6.1.cvs (latlong): > g.proj -w
> > GEOGCS["wgs84",
> > DATUM["WGS_1984",
> > SPHEROID["wgs84",6378137,298.257223563]],
> > PRIMEM["Greenwich",0],
> > UNIT["degree",0.0174532925199433]]
> >
> > i.in.spotvgt -a 0001_NDV.HDF
> > Import SPOT VGT NDVI map...
> > A datum name wgs84 (WGS_1984) was specified without transformation
> > parameters. Note that the GRASS default for wgs84 is
> > towgs84=0.000,0.000,0.000. Projection of input dataset and current
> > location appear to match. Proceeding with import... 100% CREATING
> > SUPPORT FILES FOR 0001_NDV SETTING GREY COLOR TABLE FOR 0001_NDV
> > (8bit, full range) r.in.gdal complete.
> >
> > Imported SPOT VEGETATION NDVI map <0001_NDV>.
> > Remapping digital numbers to NDVI...
> > 100%
> > Import SPOT VGT NDVI quality map...
> > A datum name wgs84 (WGS_1984) was specified without transformation
> > parameters. Note that the GRASS default for wgs84 is
> > towgs84=0.000,0.000,0.000. Projection of input dataset and current
> > location appear to match. Proceeding with import... 100% CREATING
> > SUPPORT FILES FOR 0001_NDV.sm SETTING GREY COLOR TABLE FOR
> > 0001_NDV.sm (8bit, full range) r.in.gdal complete.
> > WARNING: Your color rules do not cover the whole range of
> > data! Color table for [0001_NDV.sm] set to rules
> >
> > Imported SPOT VEGETATION SM quality map <0001_NDV.sm>.
> >
> > Note: A snow map can be extracted by category 252 (d.rast
> > 0001_NDV.sm cat=252) Filtering NDVI map by Status Map quality
> > layer... 100% Filtered SPOT VEGETATION NDVI map <0001_NDV_filt>.
> >
> > Done.
> >
> > ####### cell corners:
> > g.region rast=0001_NDV_filt -pg
> > n=75.00446429
> > s=24.99553587
> > w=-11.00446429
> > e=62.00446405
> > nsres=0.00892857
> > ewres=0.00892857
> > rows=5601
> > cols=8177
> >
>
>
>
> > # are we still centered?
> > g.region -c
> > Decimal degree (East/North positive, West/South negative): region
> > center northing: 50.000000 region center easting: 25.500000
> >
> > # -> YES!
> >
> > d.mon x0
> > d.rast 0001_NDV_filt
> >
> >
> > > I hope you could follow me so far, but you see that the
> > import works
> > > fine (both ways)
> >
> > Only apparently IMHO, it only really works with i.in.spotvgt (or a
> > modified manual procedure) as both ways are not identical.
> >
> > > and also that the images are correctly georeferenced inside
> > Grass. The
> > > shift occurs only in the exported files.
> >
> > In my opinion your data are already shifted during import, when
> > doing it manually.
> >
>
> As I wrote already the shift occurs in both exported files.
>
> > > Therfore, what do you suggest to do now? Do you want me to
> > upload the
> > > ndvi_out.tif or a Spot HDF file to your ftp? Please let me know.
> >
> > Yes, please upload a Spot HDF file, since I don't have a world SPOT
> > here. I would like to test the behaviour of my script also with that
> > map.
> >
> > Best regards
> >
> > Markus
> >
> >
> > > Best regards,
> > > Dorit
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Markus Neteler [mailto:neteler@itc.it]
> > > Sent: 20 January 2006 09:36
> > > To: Gross, Dorit (SDRN)
> > > Subject: Re: [GRASSLIST:9903] Re: GeoTiffs shifted by 360
> > degrees after
> > > processing in GRASS
> > >
> > >
> > > Hi Dorit,
> > >
> > > I have found only ndvi_in.zip, but it shows the problem.
> > Before going
> > > ahead: who has created these data (and which software)?
> > >
> > > The problem is that the corner coordinates are slightly
> > > "unfortunate":
> > >
> > > Corner Coordinates:
> > > Upper Left (-180.0044643, 75.0044643) (180d 0'16.07"W, 75d
> > > 0'16.07"N) Lower Left (-180.0044643, -56.0044643) (180d
> > > 0'16.07"W,
> > > 56d 0'16.07"S) Upper Right ( 179.9955353, 75.0044643)
> > > (179d59'43.93"E, 75d 0'16.07"N) Lower Right ( 179.9955353,
> > -56.0044643) (179d59'43.93"E, 56d 0'16.07"S)
> > > Center ( -0.0044645, 9.5000000) ( 0d 0'16.07"W,
> > 9d30'0.00"N)
> > >
> > > 180d 0'16.07"W does not really exist.
> > >
> > > In the same sense the center is shifted:
> > > 0d 0'16.07"W, 9d30'0.00"N
> > >
> > > I assume that it should be 0d00'0.00"W, right? I feel that the
> > > software which was used introduced
> > >
> > > Pixel Size = (0.00892857,-0.00892857)
> > > which corresponds to:
> > > (0d0'32.143",0d0'32.143")
> > >
> > > as you see, the shift is half pixel size.
> > >
> > > Best regards
> > >
> > > Markus
> > >
> > > On Thu, Jan 19, 2006 at 01:41:16PM +0100, Gross, Dorit (SDRN)
> > > wrote:
> > > > Hi Markus,
> > > >
> > > > I have now uploaded 2 Geotiffs to your ftp:
> > > >
> > > > ndvi_in.tif ... is the file that I import into Grass
> > > > ndvi_out.tif ... is then the exported file.
> > > >
> > > > Thank you very much for your support and please let me know if
> > > > you need anything else.
> > > >
> > > > Ciao, Dorit
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: owner-GRASSLIST@baylor.edu
> > [mailto:owner-GRASSLIST@baylor.edu]
> > > > On Behalf Of Markus Neteler
> > > > Sent: 18 January 2006 16:09
> > > > To: Gross, Dorit (SDRN)
> > > > Cc: GRASSLIST@baylor.edu
> > > > Subject: [GRASSLIST:9903] Re: GeoTiffs shifted by 360
> > degrees after
> > > > processing in GRASS
> > > >
> > > >
> > > > Hi Dorit,
> > > >
> > > > actually I don't know. We have processed tons of SPOT VGT
> > here. Can
> > > > you indicate the URL of a sample data set or upload it to our
> > > > (secured) FTP site (grass.itc.it , cd incoming/)?
> > > > I'll need to have a dataset to test what's going on.
> > > >
> > > > Markus
> > > >
> > > > Gross, Dorit (SDRN) wrote:
> > > >
> > > > >Hi Markus,
> > > > >
> > > > >Unfortunately the i.in.spotvgt script does not solve the
> > problem. I
> > > > >can
> > > > >import the Spot-Veg into Grass with the proper geometric
> > reference.
> > > > >Instead, the export back into GeoTiff (r.out.gdal)
> > cannot handle the
> > > > >global wrap-around and causes a 360 degree shift to the
> > east. So might
> > > > >there be another solution?
> > > > >
> > > > >About i.in.spotvgt itself: I tried the import of the NDVI HDF
> > > > >without status map and it seems to work nicely. Just a
> > little note
> > > > >... and maybe I have overseen it ... it could be stated
> > somewhere
> > > > >that also the log file is need for the import.
> > > > >
> > > > >Dorit
> > > > >
> > > > >-----Original Message-----
> > > > >From: owner-GRASSLIST@baylor.edu
> > > > >[mailto:owner-GRASSLIST@baylor.edu]
> > > > >On
> > > > >Behalf Of Markus Neteler
> > > > >Sent: 16 January 2006 16:53
> > > > >To: Gross, Dorit (SDRN)
> > > > >Cc: GRASSLIST@baylor.edu
> > > > >Subject: [GRASSLIST:9858] Re: GeoTiffs shifted by 360
> > degrees after
> > > > >processing in GRASS
> > > > >
> > > > >
> > > > >On Mon, Jan 16, 2006 at 04:44:57PM +0100, Gross, Dorit (SDRN)
> > > > >wrote:
> > > > >
> > > > >
> > > > >>Dear all,
> > > > >>
> > > > >>I have a set of GeoTiffs that I import into GRASS to do some
> > > > >>processing and export them afterwards as GeoTiffs
> > again. The problem
> > > > >>now is that GRASS exports the images shifted by 360
> > degrees to the
> > > > >>east.
> > > > >>
> > > > >>
> > > > >>Corner Coordinates (before the import into GRASS): Upper Left
> > > > >>(-180.0044643, 75.0044643) (180d 0'16.07"W, 75d
> > > > >>0'16.07"N) Lower Left (-180.0044643, -56.0044643) (180d
> > > > >>0'16.07"W, 56d 0'16.07"S) Upper Right ( 179.9955353,
> > 75.0044643)
> > > > >>(179d59'43.93"E, 75d 0'16.07"N) Lower Right ( 179.9955353,
> > > > >>-56.0044643)
> > > > >>
> > > > >>
> > > > >(179d59'43.93"E, 56d 0'16.07"S)
> > > > >
> > > > >
> > > > >>Center ( -0.0044645, 9.5000000) ( 0d
> > 0'16.07"W, 9d30'0.00"N)
> > > > >>
> > > > >>Corner Coordinates (after the export from GRASS): Upper Left
> > > > >>( 179.9955357, 75.0044643) (179d59'43.93"E, 75d
> > > > >>0'16.07"N) Lower Left ( 179.9955357, -56.0044643)
> > > > >>(179d59'43.93"E,
> > > > >>56d
> > > > >>
> > > > >>
> > > > >0'16.07"S)
> > > > >
> > > > >
> > > > >>Upper Right ( 539.996, 75.004)
> > (539d59'43.93"E, 75d 0'16.07"N)
> > > > >>Lower Right ( 539.996, -56.004)
> > (539d59'43.93"E, 56d 0'16.07"S)
> > > > >>Center ( 359.996, 9.500)
> > (359d59'43.93"E, 9d30'0.00"N)
> > > > >>
> > > > >>
> > > > >>Has someone of you faced a similar problem? How do I receive a
> > > > >>proper georeference when exporting from GRASS?
> > > > >>
> > > > >>The input GeoTiffs are a set of converted Spot-Veg HDF
> > files using
> > > > >>GDAL.
> > > > >>
> > > > >>
> > > > >
> > > > >Did you try to use the dedicated script i.in.spotvgt:
> > > > >
> > > > >
> > http://grass.itc.it/grass61/manuals/html61_user/i.in.spotvgt.html
> > > > >
> > > > >Maybe this solves the problem of the global wrap-around.
> > Please let
> > > > >us
> > > > >know.
> > > > >
> > > > >Markus
> > > > >
> > > > >
> > > > >
> > > > >>The -180.0044... degrees for the upper left X seems a
> > bit odd, but
> > > > >>GDAL imports the Spot-Veg properly with these
> > coordinates. I checked
> > > > >>the images in Erdas and they are correct. I also
> > checked the corner
> > > > >>coordinates of the imported file insight GRASS and also
> > here the
> > > > >>coordinates are correct. So apparently the shift occurs
> > during the
> > > > >>export from GRASS into GeoTiff. At the moment I solve
> > the problem by
> > > > >>reassigning the georeference to the GeoTiff after the
> > export from
> > > > >>GRASS, but I would be more happy with properly exported
> > images right
> > > > >>away.
> > > > >>
> > > > >>Can someone help please?
> > > > >>
> > > > >>Thank you,
> > > > >>Dorit