[GRASS-user] importing geotif in grass, transformation parameters

GRASS GRASS user
,
1

Hi,

thanks first for all your fast answers, I'm still a bit lost in GRASS. I'll come back to your answers to my other questions later, I have first to work a bit more on your suggestions.

For nearly all data that I try to import with r.in.gdal, I get warnings/error messages like this:

"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."

or

"WARNING: No projection name! Projection parameters likely to be
          meaningless.
A datum name nad83 (North_American_Datum_1983) was specified without transformation parameters. "

or

"WARNING: No projection name! Projection parameters likely to be
          meaningless.
WARNING: Datum 'unknown' not recognised by GRASS and no parameters found.
          Datum transformation will not be possible using this projection
          information."

I don't have any idea to what refers this "transformation parameter". Which information is missing?
And, if I would know which information is missing and get to know it, would there be any possibility to get this information into GRASS after or during the import process?
Even if I can open the files ignoring these warnings, I'm struggling in the most cases later on other operations. For example I can't project the UTM data in LongLat (or viceversa) as Grass complains again about missing parameters.
But my main problem is really that I don't understand with which transformation parameters I'm dealing!

Thanks again for your help,
  Martina

2

Martina Schaefer

I don't have any idea to what refers this
"transformation parameter".
Which information is missing?

datum transform parameters?
some reading:
  http://grass.osgeo.org/wiki/Gis_Concepts#Geodesy_and_Cartography

And, if I would know which information is missing and get
to know it, would there be any possibility to get this
information into GRASS after or during the import process?

it should happen automatically, if there and you are creating a new location based on the data file.

try looking at what projection info is shown by:

  gdalinfo filename.tif

if GRASS doesn't know what projection your data is in (ie your location projection settings happen to be broken), it won't be able to reproject it to something else. maybe g.setproj helps to reset it to something known?

Hamish

3

On Mon, 23 Jun 2008, Martina Schaefer wrote:

Hi,

thanks first for all your fast answers, I'm still a bit lost in GRASS. I'll come back to your answers to my other questions later, I have first to work a bit more on your suggestions.

For nearly all data that I try to import with r.in.gdal, I get warnings/error messages like this:

"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."

That is normal and harmless. Datum transformation parametes are normally defined in terms of their relationship wih WGS84, so if your datum is WGS84 itself then it doesn't matter if the parameters are specified or not: towgs84=0,0,0 is the only possible parameter set.

or

"WARNING: No projection name! Projection parameters likely to be
        meaningless.

That is of much more concern. Can you try running
gdalinfo filename.tif
on the file that has the problem, and posting the results to the list here in the hope that someone can see what is wrong?

Paul

4

Hi Paul,

here the infos that you asked me for:

"WARNING: No projection name! Projection parameters likely to be
        meaningless.

That is of much more concern. Can you try running
gdalinfo filename.tif
on the file that has the problem, and posting the results to the list here in the hope that someone can see what is wrong?

here the output
GRASS 6.2.2 (BelcherBathy):~/Work/Devon-Data/bthy > gdalinfo 00005latlong.tif
Driver: GTiff/GeoTIFF
Size is 15134, 2496
Coordinate System is:
PROJCS["unnamed",
     GEOGCS["unnamed",
         DATUM["unknown",
             SPHEROID["unretrievable - using WGS84",6378137,298.257223563]],
         PRIMEM["Greenwich",0],
         UNIT[,0.0174532925199433]],
     UNIT["unknown",1]]
Origin = (-81.327157999999997,75.767208999999994)
Pixel Size = (0.000049996696181,-0.000049979967949)
Image Structure Metadata:
   COMPRESSION=LZW
Corner Coordinates:
Upper Left ( -81.3271580, 75.7672090)
Lower Left ( -81.3271580, 75.6424590)
Upper Right ( -80.5705080, 75.7672090)
Lower Right ( -80.5705080, 75.6424590)
Center ( -80.9488330, 75.7048340)
Band 1 Block=15134x1 Type=Byte, ColorInterp=Red
Band 2 Block=15134x1 Type=Byte, ColorInterp=Green
Band 3 Block=15134x1 Type=Byte, ColorInterp=Blue
Band 4 Block=15134x1 Type=Byte, ColorInterp=Alpha

in fact, this is the same data as the following one, only transformed to LatLong by ArcGIS

GRASS 6.2.2 (BelcherBathy):~/Work/Devon-Data/bthy > gdalinfo 00005_utm.tif
Driver: GTiff/GeoTIFF
Size is 14805, 2508
Coordinate System is:
PROJCS["WGS 84 / UTM zone 17N",
     GEOGCS["WGS 84",
         DATUM["WGS_1984",
             SPHEROID["WGS 84",6378137,298.2572235630016,
                 AUTHORITY["EPSG","7030"]],
             AUTHORITY["EPSG","6326"]],
         PRIMEM["Greenwich",0],
         UNIT["degree",0.0174532925199433],
         AUTHORITY["EPSG","4326"]],
     PROJECTION["Transverse_Mercator"],
     PARAMETER["latitude_of_origin",0],
     PARAMETER["central_meridian",-81],
     PARAMETER["scale_factor",0.9996],
     PARAMETER["false_easting",500000],
     PARAMETER["false_northing",0],
     UNIT["metre",1,
         AUTHORITY["EPSG","9001"]],
     AUTHORITY["EPSG","32617"]]
Origin = (490944.258245616627391,8409263.051821239292622)
Pixel Size = (1.414845022256486,-5.571261774748564)
Metadata:
   AREA_OR_POINT=Area
   TIFFTAG_SOFTWARE=IMAGINE TIFF Support
Copyright 1991 - 1999 by ERDAS, Inc. All Rights Reserved
@(#)$RCSfile: etif.c $ $Revision: 1.9.1.3 $ $Date: 2002/07/29 15:39:06EDT $
   TIFFTAG_XRESOLUTION=1
   TIFFTAG_YRESOLUTION=1
   TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
Image Structure Metadata:
   COMPRESSION=LZW
Corner Coordinates:
Upper Left ( 490944.258, 8409263.052)
Lower Left ( 490944.258, 8395290.327)
Upper Right ( 511891.039, 8409263.052)
Lower Right ( 511891.039, 8395290.327)
Center ( 501417.649, 8402276.690)
Band 1 Block=14805x1 Type=Byte, ColorInterp=Red
Band 2 Block=14805x1 Type=Byte, ColorInterp=Green
Band 3 Block=14805x1 Type=Byte, ColorInterp=Blue
Band 4 Block=14805x1 Type=Byte, ColorInterp=Undefined

and from the following file I got this error message
"WARNING: No projection name! Projection parameters likely to be
          meaningless.
A datum name nad83 (North_American_Datum_1983) was specified without transformation parameters. "
And even if I can open the file, I can't for example project it to LongLat, everytime I get error messages about this transformation parameter. I suppose the problem is the "unnamed" in the PROJCS, but how could I fill it and with what?
This file is orignially a img file that I can open without problems with ArcGIS, but grass says
"GDALOpen failed - 4
`oa16787_058.img' not recognised as a supported file format."
so I converted it to tif by img2tif

GRASS 6.2.2 (BelcherBathy):~/Work/Devon-Data/new > gdalinfo oa16787_058.tif
Driver: GTiff/GeoTIFF
Size is 2357, 2264
Coordinate System is:
PROJCS["unnamed",
     GEOGCS["NAD83",
         DATUM["North_American_Datum_1983",
             SPHEROID["unnamed",6378137,298.2572220960423],
             AUTHORITY["EPSG","6269"]],
         PRIMEM["Greenwich",0],
         UNIT["degree",0.0174532925199433],
         AUTHORITY["EPSG","4269"]],
     UNIT["metre",1,
         AUTHORITY["EPSG","9001"]],
     AUTHORITY["EPSG","26817"]]
Origin = (489494.411800000001676,8397247.058800000697374)
Pixel Size = (5.000000000000000,-5.000000000000000)
Metadata:
   AREA_OR_POINT=Area
Corner Coordinates:
Upper Left ( 489494.412, 8397247.059)
Lower Left ( 489494.412, 8385927.059)
Upper Right ( 501279.412, 8397247.059)
Lower Right ( 501279.412, 8385927.059)
Center ( 495386.912, 8391587.059)
Band 1 Block=64x64 Type=Byte, ColorInterp=Gray

Thanks for all good ideas!

  Martina

5

On Tue, 24 Jun 2008, Martina Schaefer wrote:

Hi Paul,

here the infos that you asked me for:

[...]

in fact, this is the same data as the following one, only transformed to LatLong by ArcGIS

GRASS 6.2.2 (BelcherBathy):~/Work/Devon-Data/bthy > gdalinfo 00005_utm.tif
Driver: GTiff/GeoTIFF
Size is 14805, 2508
Coordinate System is:
PROJCS["WGS 84 / UTM zone 17N",
   GEOGCS["WGS 84",
       DATUM["WGS_1984",
           SPHEROID["WGS 84",6378137,298.2572235630016,
               AUTHORITY["EPSG","7030"]],
           AUTHORITY["EPSG","6326"]],
       PRIMEM["Greenwich",0],
       UNIT["degree",0.0174532925199433],
       AUTHORITY["EPSG","4326"]],
   PROJECTION["Transverse_Mercator"],
   PARAMETER["latitude_of_origin",0],
   PARAMETER["central_meridian",-81],
   PARAMETER["scale_factor",0.9996],
   PARAMETER["false_easting",500000],
   PARAMETER["false_northing",0],
   UNIT["metre",1,
       AUTHORITY["EPSG","9001"]],
   AUTHORITY["EPSG","32617"]]
Origin = (490944.258245616627391,8409263.051821239292622)
Pixel Size = (1.414845022256486,-5.571261774748564)
Metadata:
AREA_OR_POINT=Area
TIFFTAG_SOFTWARE=IMAGINE TIFF Support
Copyright 1991 - 1999 by ERDAS, Inc. All Rights Reserved
@(#)$RCSfile: etif.c $ $Revision: 1.9.1.3 $ $Date: 2002/07/29 15:39:06EDT $
TIFFTAG_XRESOLUTION=1
TIFFTAG_YRESOLUTION=1
TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
Image Structure Metadata:
COMPRESSION=LZW
Corner Coordinates:
Upper Left ( 490944.258, 8409263.052)
Lower Left ( 490944.258, 8395290.327)
Upper Right ( 511891.039, 8409263.052)
Lower Right ( 511891.039, 8395290.327)
Center ( 501417.649, 8402276.690)
Band 1 Block=14805x1 Type=Byte, ColorInterp=Red
Band 2 Block=14805x1 Type=Byte, ColorInterp=Green
Band 3 Block=14805x1 Type=Byte, ColorInterp=Blue
Band 4 Block=14805x1 Type=Byte, ColorInterp=Undefined

If you run
g.proj -c georef=filename
where filename is the name of the file that contains the correct co-ordinate system info, it will overwrite the current location's projection with the correct values. Although only do this if you are sure the projection is definitely correct, and not just a default value that the other software added into the file.

Add the -i flag as well as -c if you want to be interactively prompted for datum parameters (with some hints on which ones to pick).

Hope this helps a bit

Paul

6

Hi Paul,

If you run
g.proj -c georef=filename
where filename is the name of the file that contains the correct co-ordinate system info, it will overwrite the current location's projection with the correct values. Although only do this if you are sure the projection is definitely correct, and not just a default value that the other software added into the file.
Add the -i flag as well as -c if you want to be interactively prompted for datum parameters (with some hints on which ones to pick).

This worked fine, besides the -i flag which doesn't exist (?) in my version.
But now I have new troubles....
In LatLong the display of my map is distored and when I try to add a grid I get the following error message

PNG: GRASS_TRUECOLOR status: TRUE
PNG: collecting to file: /home/martina/Work/grassdata/BelcherLLnew/Martina/.tmp/berg.physics.mun.ca/31669.3.ppm,
      GRASS_WIDTH=642, GRASS_HEIGHT=110

Border not yet implemented for LatLong locations: border not drawn.

apparently LatLong is not supported by Grass as I would like to!

Thanks anyway, it was a try :-).

Martina

7

Border not yet implemented for LatLong locations: border
not drawn.

apparently LatLong is not supported by Grass as I would
like to!

that just draws a box around the screen with tick marks. just a minor thing which doesn't affect the grid at all.

to get rid of the warning just to 'd.grid -b' or update to a newer version of GRASS which now supports that.

Hamish

8

Hi Hamish,

thanks for your patience :-).

Border not yet implemented for LatLong locations: border
not drawn.
apparently LatLong is not supported by Grass as I would
like to!

that just draws a box around the screen with tick marks. just a minor thing which doesn't affect the grid at all.
to get rid of the warning just to 'd.grid -b' or update to a newer version of GRASS which now supports that.

Ok, I see, I thought that this error message was also linked to the fact that my map is distorted and that I couldn't draw a grid.

For the grid I'm fine now, my error was that the units for the gridlines are not in degrees, but in rad or something like that.

But my graph is twice much larger than I expected it (and looks quite ugly), but probably it's due to the fact that Grass takes the same distance for 1degree in NS and EW in LongLat.
It seams also impossible to draw a North arrow and a scale in LongLat.

Martina

9

Martina:

For the grid I'm fine now, my error was that the units for
the gridlines are not in degrees, but in rad or something like that.

no, they really are in degrees. Like DDD:MM:SS.SSS.
So for a 2' grid you'd do 'size=0:02', for a 1deg grid size=1, etc.

But my graph is twice much larger than I expected it (and
looks quite ugly),

are you working at a high latitude?

but probably it's due to the fact that Grass
takes the same distance for 1degree in NS and EW in LongLat.

for the display window it uses "Plate Carrée" projection, ie equi-rectangular. As for "same distance" that isn't quite right to say it is the same, e.g. d.measure will give a correct result and the "back end" is doing the right thing even if it looks funny in the display.

3D Earth -> 2D raster array/paper ... why map projections were invented.

I suggest you reproject your data into a meter-based coordinate system appropriate for your region of study.

It seams also impossible to draw a North arrow and a scale
in LongLat.

Newer versions of GRASS let you draw the north arrow with d.barscale in a lat/lon location. A scalebar is wrong/impossible in lat/lon as the scale changes with latitude, so just use d.grid there. Also you can add a north arrow with d.graph and the north arrow or compass symbols.
  http://grass.osgeo.org/wiki/IconSymbols

Hamish