Opened 11 years ago
Closed 11 years ago
#4880 closed defect (invalid)
OSRExportToProj4 drops NAD83 datum in Proj4 string
Reported by: | rsbivand | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | default | Version: | 1.9.2 |
Severity: | normal | Keywords: | |
Cc: | osoong+r@… |
Description (last modified by )
A user of rgdal in R has noted that the WTK string in a file loses its Datum if the datum is NAD83, meaning that if the data is written out to file, the datum is not set. This can be illustrated by comparing the output of gdalinfo -proj4 for WKT and proj4 for input (written):
+proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 +datum=NAD83 +units=m +no_defs +ellps=GRS80 +towgs84=0,0,0
$ gdalinfo img1.tif ... PROJCS["unnamed", GEOGCS["NAD83", DATUM["North_American_Datum_1983", SPHEROID["GRS 1980",6378137,298.2572221010002, ... PROJ.4 string is: '+proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs '
For two other cases, NAD27 and WGS84:
+proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs
$ gdalinfo -proj4 img2.tif ... PROJCS["unnamed", GEOGCS["NAD27", DATUM["North_American_Datum_1927", SPHEROID["Clarke 1866",6378206.4,294.9786982139006, ... PROJ.4 string is: '+proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs '
and
+proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs
$ gdalinfo -proj4 img3.tif ... PROJCS["unnamed", GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, ... PROJ.4 string is: '+proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs '
There does not seem to be any reference to this in:
http://www.gdal.org/ogr/classOGRSpatialReference.html#a28bd9b81856b6a93861576fff0933bb9
Attachments (2)
Change History (5)
by , 11 years ago
Attachment: | img1-3.zip.zip added |
---|
comment:1 by , 11 years ago
Description: | modified (diff) |
---|
This is probably another representation of #3450, as this shows:
$ OVERRIDE_PROJ_DATUM_WITH_TOWGS84=NO gdalinfo -proj4 img1.tif ... PROJCS["unnamed", GEOGCS["NAD83", DATUM["North_American_Datum_1983", SPHEROID["GRS 1980",6378137,298.2572221010002, ... PROJ.4 string is: '+proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 +datum=NAD83 +units=m +no_defs '
but it isn't obvious why the user/calling program should have to intervene in this case. Even when the file is written with:
+proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 +datum=NAD83 +units=m +no_defs
we still see:
$ gdalinfo -proj4 img1a.tif ... PROJCS["unnamed", GEOGCS["NAD83", DATUM["North_American_Datum_1983", SPHEROID["GRS 1980",6378137,298.2572221010002, ... PROJ.4 string is: '+proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs '
that is a conversion to +ellps +towgs84 even though neither were in the input.
$ OVERRIDE_PROJ_DATUM_WITH_TOWGS84=NO gdalinfo -proj4 img1a.tif ... PROJCS["unnamed", GEOGCS["NAD83", DATUM["North_American_Datum_1983", SPHEROID["GRS 1980",6378137,298.2572221010002, ... PROJ.4 string is: '+proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 +datum=NAD83 +units=m +no_defs '
Is the conclusion that calling programs must first find "NAD83" in the input WKT, if it is there set the environment variable, export to Proj4, then remove the environment variable?
comment:2 by , 11 years ago
Email thread where this is discussed : http://lists.osgeo.org/pipermail/gdal-dev/2012-November/034558.html
comment:3 by , 11 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
files for reported case