[GRASSLIST:10091] Re: GeoTiffs shifted by 360 degrees after processing in GRASS
Markus Neteler
neteler at itc.it
Tue Jan 31 10:54:14 EST 2006
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 work ;) I 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 at 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 GRASS
>
>
> Hi 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: 40320
>
> g.region -c
> Decimal degree (East/North positive, West/South negative): region center
> northing: 9.500000 region center easting: 359.995535
>
> I 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: 1
>
> these 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 output
>
> r.out.tiff -t 0001_NDV out=0001_NDVti
> D0/0: N:75.004464 S:-56.004464
> D0/0: W:179.995536 E:539.995535
>
> we 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 at 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 at 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 at baylor.edu
> > > [mailto:owner-GRASSLIST at baylor.edu]
> > > > > On Behalf Of Markus Neteler
> > > > > Sent: 18 January 2006 16:09
> > > > > To: Gross, Dorit (SDRN)
> > > > > Cc: GRASSLIST at 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 at baylor.edu
> > > > > >[mailto:owner-GRASSLIST at baylor.edu]
> > > > > >On
> > > > > >Behalf Of Markus Neteler
> > > > > >Sent: 16 January 2006 16:53
> > > > > >To: Gross, Dorit (SDRN)
> > > > > >Cc: GRASSLIST at 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
More information about the grass-user
mailing list