[GRASS-user] GeoTIFF, EPSG and GRASS

Hamish hamish.webmail at gmail.com
Thu Aug 21 21:13:08 PDT 2014


Adrien wrote:
> with GDAL i use EPSG:2972 to reproject any new raster i'm lead to
> work with.
> 
> gdalinfo says:
> 
> Coordinate System is:
> PROJCS["RGFG95 / UTM zone 22N",
>     GEOGCS["RGFG95",
>         DATUM["Reseau_Geodesique_Francais_Guyane_1995",
>             SPHEROID["GRS 1980",6378137,298.2572221010002,
>                 AUTHORITY["EPSG","7019"]],
>             TOWGS84[0,0,0,0,0,0,0],
>             AUTHORITY["EPSG","6624"]],
>         PRIMEM["Greenwich",0],
>         UNIT["degree",0.0174532925199433],
>         AUTHORITY["EPSG","4624"]],
>     PROJECTION["Transverse_Mercator"],
>     PARAMETER["latitude_of_origin",0],
>     PARAMETER["central_meridian",-51],
>     PARAMETER["scale_factor",0.9996],
>     PARAMETER["false_easting",500000],
>     PARAMETER["false_northing",0],
>     UNIT["metre",1,
>         AUTHORITY["EPSG","9001"]],
>     AUTHORITY["EPSG","2972"]]
> 
> I've created the GRASS location from this same code, and all imports
> are successful.
> 
> After exporting, the gdalinfo output is different:
> 
> Coordinate System is:
> PROJCS["UTM Zone 22, Northern Hemisphere",
>     GEOGCS["grs80",
>         DATUM["unknown",
>             SPHEROID["Geodetic_Reference_System_1980", 6378137,
> 298.257222101]],
>         PRIMEM["Greenwich",0],
>         UNIT["degree",0.0174532925199433]],
>     PROJECTION["Transverse_Mercator"],
>     PARAMETER["latitude_of_origin",0],
>     PARAMETER["central_meridian",-51],
>     PARAMETER["scale_factor",0.9996],
>     PARAMETER["false_easting",500000],
>     PARAMETER["false_northing",0],
>     UNIT["metre",1,
>         AUTHORITY["EPSG","9001"]]]
> 
> The PROJCS has lost its AUTHORITY parameter.

GRASS doesn't store the EPSG number in the location settings (well
it can, but that's just for informational purposes) and only uses
the actual coefficients used in the projection math. Literally
the output of the 'g.proj -p' command.

As definitive as EPSG codes are, they aren't always exact representations. (e.g. precision issues or added datum transform
grid selection is sometimes used but not specified in the actual
code definition. If you are lucky in these cases the extra terms
are stored in a PROJ.4 string within the WKT, but that's a non-
official extension AFAIK)

> Would someone know why this happens? Is there a way to fix this?

perhaps this will do it:
  gdal_translate -a_srs +init=epsg:2972 in.tif out.tif



Hamish


More information about the grass-user mailing list