Opened 9 years ago
Closed 9 years ago
#6027 closed defect (fixed)
WGS 72 GEOGCS name not correctly morphed to ESRI
Reported by: | ccjklppp | Owned by: | warmerdam |
---|---|---|---|
Priority: | high | Milestone: | 2.0.1 |
Component: | OGR_SRS | Version: | unspecified |
Severity: | major | Keywords: | |
Cc: |
Description
some coordinate systems parameters are not taken from gcs.csv (or gcs.override.csv). and changing the parameters in there has no influence on nothing.
for example - WGS 72 (epsg:4322) prj from gdalsrsinfo:
GEOGCS["WGS 72",DATUM["D_WGS_1972",SPHEROID["WGS_1972",6378135,298.26]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]
this prj is constant even if the parameters in the gcs.csv are changed.
Attachments (2)
Change History (16)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
I changed for example the coord_ref_sys_name in gcs.csv from 'WGS 72' to 'WGS_1972' and the prj string is the same as earlier. I also think the reason is that it is hard coded but I dont understand the reason... Isn't gcs.csv/gcs.override.csv purpose is that the coordinate-systems won't be hard coded? I tried to follow the code to see where does the prj string is come from and didn't see it hard coded...
comment:3 by , 9 years ago
I've just tried the following, which looks ok to me
$ svn diff data/gcs.csv Index: data/gcs.csv =================================================================== --- data/gcs.csv (révision 29478) +++ data/gcs.csv (copie de travail) @@ -245,7 +245,7 @@ 4317,Dealul Piscului 1970,6317,Dealul Piscului 1970,6317,9122,7024,8901,1,1,6422,1097,1,9603,28,-121,-77,,,, 4318,NGN,6318,National Geodetic Network,6318,9122,7030,8901,1,0,6422,1060,0,9603,-3.2,-5.7,2.8,,,, 4319,KUDAMS,6319,Kuwait Utility,6319,9122,7019,8901,1,0,6422,1061,1,9603,-20.8,11.3,2.4,,,, -4322,WGS 72,6322,World Geodetic System 1972,6322,9122,7043,8901,1,0,6422,1237,1,9606,0,0,4.5,0,0,0.554,0.2263 +4322,aaWGS 72,6322,World Geodetic System 1972,6322,9122,7043,8901,1,0,6422,1237,1,9606,0,0,4.5,0,0,0.554,0.2263 4324,WGS 72BE,6324,WGS 72 Transit Broadcast Ephemeris,6324,9122,7043,8901,1,0,6422,1240,0,9606,0,0,1.9,0,0,0.814,-0.38 4326,WGS 84,6326,World Geodetic System 1984,6326,9122,7030,8901,1,0,6422,,0,,,,,,,, 4463,RGSPM06,1038,Reseau Geodesique de Saint Pierre et Miquelon 2006,1038,9122,7019,8901,1,0,6422,4477,0,9603,0,0,0,,,, $ gdalsrsinfo EPSG:4322 PROJ.4 : '+proj=longlat +ellps=WGS72 +towgs84=0,0,4.5,0,0,0.554,0.2263 +no_defs ' OGC WKT : GEOGCS["aaWGS 72", DATUM["WGS_1972", SPHEROID["WGS 72",6378135,298.26, AUTHORITY["EPSG","7043"]], TOWGS84[0,0,4.5,0,0,0.554,0.2263], AUTHORITY["EPSG","6322"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4322"]]
follow-up: 5 comment:4 by , 9 years ago
My mistake... Gdalsrsinfo returns the prj as it appears in the gcs.csv/gcs.override.csv. When creating an esri shape file (for example with gdaltindex), the prj created with it is constant and not as appears in the gcs.csv/gcs.override.csv
comment:5 by , 9 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Replying to ccjklppp:
My mistake... Gdalsrsinfo returns the prj as it appears in the gcs.csv/gcs.override.csv. When creating an esri shape file (for example with gdaltindex), the prj created with it is constant and not as appears in the gcs.csv/gcs.override.csv
Ah ok, this is expected since parsing the .prj doesn't imply at all going to the EPSG dictionaries.
comment:6 by , 9 years ago
Why not? So where does it come from? At most coordinate systems the prj string is coming from the gcs.csv parameters...
comment:7 by , 9 years ago
Well the info comes from the .prj file itself.
If I put in wgs72.txt
GEOGCS["WGS 72",DATUM["D_WGS_1972",SPHEROID["WGS_1972",6378135,298.26]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]
and then:
$ gdalsrsinfo ESRI::wgs72.txt PROJ.4 : '+proj=longlat +a=6378135 +b=6356750.591713298 +no_defs ' OGC WKT : GEOGCS["WGS 72", DATUM["WGS_1972", SPHEROID["WGS_72",6378135,298.261]], PRIMEM["Greenwich",0], UNIT["Degree",0.017453292519943295]]
Everything comes from the .prj (just D_WGS_1972 has become WGS_1972 as this is an ESRIsm)
comment:8 by , 9 years ago
I think you misunderstood me.... Gdal itself created the prj file and it isnt match the gcs.csv file.
comment:9 by , 9 years ago
Please provide a clear way of reproducing what you do. I cannot read in your brain and guess what is on your screen.
by , 9 years ago
Attachment: | testWGS72.tif added |
---|
by , 9 years ago
Attachment: | testWGS84.tif added |
---|
comment:10 by , 9 years ago
ok.. again :) I found more simple example that doesn't involve shapes and prjs. tiff files are attached.
first, I changed the WGS72 line in the gcs.csv into:
4322,WGS 72 test!!,6322,World Geodetic System 1972,6322,9122,7043,8901,1,0,6422,1237,1,9606,0,0,4.5,0,0,0.554,0.2263
then, I warped a tiff file into WGS72 coordinate system using the command:
gdalwarp -t_srs epsg:4322 c:\testWGS84.tif c:\testWGS72.tif
now, when using the command:
gdalsrsinfo -o wkt_esri epsg:4322
I get:
GEOGCS["WGS 72 test!!",DATUM["D_WGS_1972",SPHEROID["WGS_1972",6378135,298.26]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]
and when using gdalsrsinfo on the file with the command:
gdalsrsinfo -o wkt_esri c:\testWGS72.tif
I get the following result (not as written in gcs.csv)
GEOGCS["WGS 72",DATUM["D_WGS_1972",SPHEROID["WGS_1972",6378135,298.26]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]
It happenes with some more coordinate systems (e.g. WGS84)
comment:11 by , 9 years ago
This comes from libgeotiff geo_normalize.c that has the following logic :
else if( nGCSCode == GCS_WGS_72 ) { nDatum = Datum_WGS72; pszName = "WGS 72"; }
I fail to see why you would want to change the name of well known and standard GCS/PCS
comment:12 by , 9 years ago
I want to change the names of some coordinate system because they aren't compatible with esri. WGS 74 for example should be GCS_WGS_1972
I found a place where it should be done:
in OGRSpatialReference::morphToESRI()
in ogr_srs_esri.cpp, line ~1102,
the following code should be added:
else if( nGCSCode == 4322 || EQUAL(pszGeogCSName,"WGS72") || EQUAL(pszGeogCSName,"WGS 72") ) { poGeogCS->GetChild(0)->SetValue( "GCS_WGS_1972" ); pszUTMPrefix = "WGS_1972"; }
comment:13 by , 9 years ago
Resolution: | invalid |
---|---|
Status: | closed → reopened |
Summary: | some coordinate systems parameters are not taken from gcs.csv → WGS 72 GEOGCS name not correctly morphed to ESRI |
comment:14 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Can you better describe the issue ? (i.e. show the lines modified in gcs.csv/gcs.override.csv). But I think it might be due that some coordinate systems are hard-coded in the .cpp files and WGS72 is one of them.