[GRASSLIST:10247] Re: GeoTiffs shifted by 360 degrees after
processing in GRASS
Gross, Dorit (SDRN)
Dorit.Gross at fao.org
Fri Feb 10 11:16:29 EST 2006
Dear Markus,
Sorry for taking me so long to reply.
I followed the steps you suggested and changed the region settings before
exporting the Spot VGT into Geotiff. Yes, the exported image is not shifted
by 360 degrees anymore. Still there is a shift of half a pixel compared to
the original image and I guess this is due to the resetting of the region. It
was possible to avoid the shifting by setting the west coordinate to
-179.99553xx (that is 1 pix less than the original coord) and leaving the
east coordinate unchanged before the export. But it means that we cut off 1
column from the west edge of the image. At the end also this solution is not
really satisfactory.
For now, I will solve the problem by reassigning the georeference to the
Geotiff after the Grass export. If there might be a better solution (maybe in
the future??) I will be very happy to hear about it.
Thank you for everything!
Cheers, Dorit
-----Original Message-----
From: Markus Neteler [mailto:neteler at itc.it]
Sent: 31 January 2006 16:54
To: Gross, Dorit (SDRN)
Cc: GRASS user list
Subject: Re: [GRASSLIST:9903] Re: GeoTiffs shifted by 360 degrees after
processing in GRASS
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