Opened 8 years ago
Closed 7 years ago
#3048 closed defect (duplicate)
r.out.gdal does not write EPSG code of the projection
Reported by: | sbl | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 7.4.0 |
Component: | Raster | Version: | svn-trunk |
Keywords: | r.out.gdal | Cc: | |
CPU: | Unspecified | Platform: | All |
Description
GeoTiffs produced with GRASS GIS 6.4, 7.0.4 and 7.1.svn do not contain the AUTHORITY parameter for the projection, which is thus not properly recognized by other tools (e.g. QGIS, but esp. GeoServer).
Related discussion on the GDAL mailinglist can be found here: http://thread.gmane.org/gmane.comp.gis.gdal.devel/43019
g.proj -w gave the projection information as in the GeoTIFF, though without any AUTHORITY parameters (as it is supposed to according to the manual). The AUTHORITY tags seem to be added by r.out.gdal, except for the authority parameter for the entire projection. Even if g.proj -g returns epsg=25832.
Compared to GDALs GeoTIFFs also AXIS parameters are missing (see below).
GRASS 7.0.4svn (ETRS_32N):~ >g.proj -g name=ETRS89 / UTM zone 32N datum=etrs89 ellps=grs80 proj=utm zone=32 towgs84=0,0,0,0,0,0,0 no_defs=defined epsg=25832 unit=meter units=meters meters=1 GRASS 7.0.4svn (ETRS_32N):~ > GRASS 7.0.4svn (ETRS_32N):~ >r.out.gdal input=test output=$HOME/test.tif GRASS 7.0.4svn (ETRS_32N):~ >gdalinfo $HOME/test.tif (...) Coordinate System is: PROJCS["UTM Zone 32, Northern Hemisphere", GEOGCS["grs80", DATUM["European_Terrestrial_Reference_System_1989", SPHEROID["Geodetic_Reference_System_1980",6378137,298.257222101, AUTHORITY["EPSG","7019"]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY["EPSG","6258"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",9], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",500000], PARAMETER["false_northing",0], UNIT["metre",1, AUTHORITY["EPSG","9001"]]] Origin = (0.000000000000000,1.000000000000000) Pixel Size = (1.000000000000000,-1.000000000000000) (...) GRASS 7.0.4svn (ETRS_32N):~ > GRASS 7.0.4svn (ETRS_32N):~ >gdal_translate -a_srs EPSG:25832 $HOME/test.tif $HOME/test2.tif GRASS 7.0.4svn (ETRS_32N):~ >gdalinfo $HOME/test2.tif (...) Coordinate System is: PROJCS["ETRS89 / UTM zone 32N", GEOGCS["ETRS89", DATUM["European_Terrestrial_Reference_System_1989", SPHEROID["GRS 1980",6378137,298.257222101, AUTHORITY["EPSG","7019"]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY["EPSG","6258"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4258"]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",9], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",500000], PARAMETER["false_northing",0], UNIT["metre",1, AUTHORITY["EPSG","9001"]], AXIS["Easting",EAST], AXIS["Northing",NORTH], AUTHORITY["EPSG","25832"]] Origin = (0.000000000000000,1.000000000000000) Pixel Size = (1.000000000000000,-1.000000000000000) (...)
Change History (8)
comment:1 by , 8 years ago
follow-up: 3 comment:2 by , 8 years ago
Thinking more about it, I believe that it is not possible to generate the AUTHORITY here because GRASS internally uses the PROJ.4 representation.
Options:
- implement lookup support in GDAL, see http://article.gmane.org/gmane.comp.gis.gdal.devel/43031
- Change libproj to first read PROJ_EPSG (if present), then merge the datum information into that which is maintained in GRASS only, send all to GDAL and get WKT back (something like this).
Note that EPSG codes often don't include the DATUM string since several datums may exist (that's why GRASS comes with a sophisticated lookup mechanism which isn't present in GDAL for example).
Back to the original report:
which is thus not properly recognized by other tools (e.g. QGIS, but esp. GeoServer).
Can you elaborate?
comment:3 by , 8 years ago
To me it seems the issue is also present in your nc_spm_08_grass7 location...
Replying to neteler:
Thinking more about it, I believe that it is not possible to generate the AUTHORITY here because GRASS internally uses the PROJ.4 representation.
In my location the AUTHORITY parameter is present but it is not used in r.out.gdal never the less, so it would not have to be generated.
Note that EPSG codes often don't include the DATUM string since several datums may exist (that's why GRASS comes with a sophisticated lookup mechanism which isn't present in GDAL for example).
Back to the original report:
which is thus not properly recognized by other tools (e.g. QGIS, but esp. GeoServer).
Can you elaborate?
Sure, in QGIS my raster in EPSG:25832 is interpreted as EPSG:3044 (both have equal proj-strings). However, CRS do not match and also in PostGIS SRID would not match, so they have to defined manually for analysis with other data one has in the originally used CRS 25832. In GeoNode / GeoServer the GeoTiffs exported from GRASS are shown as pink boxes as long as one does not define the projection in GeoServer manually. See: http://docs.geonode.org/en/master/tutorials/advanced/geonode_production/adv_gsconfig/crs_handling.html
comment:4 by , 8 years ago
See also possibly related tickets for QGIS processing: https://hub.qgis.org/issues/11884 and https://hub.qgis.org/issues/14499
comment:5 by , 8 years ago
Milestone: | 7.0.5 → 7.0.6 |
---|
comment:7 by , 7 years ago
Milestone: | 7.0.6 → 7.4.0 |
---|
Replying to sbl:
This is also true for r.external.out, see: #3059
Granted that the file PERMANENT/PROJ_EPSG exists, this works for me with relbr74 and trunk, no action required.
Explanation:
The EPSG code of the projection is only written out if it is known. Use g.proj -p
or g.proj -g
to test if the EPSG code is known.
Regarding GDAL/OGR input: if the EPSG code of the projection of the input is known and if a new location is created from that input, this EPSG code is now preserved in PERMANENT/PROJ_EPSG as of trunk r72114.
comment:8 by , 7 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Closing as duplicate. See: #3193
I just tried with the NC dataset on my system, no such issue:
But doing the same in a UTM32N location, the AUTHORITY is missing:
I see differences in the PROJCS, perhaps the text "warping" partially fails?