#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)

testWGS72.tif (48.5 KB) - added by ccjklppp 22 months ago.
testWGS84.tif (48.4 KB) - added by ccjklppp 22 months ago.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 22 months ago by Even Rouault

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.

comment:2 Changed 22 months ago by ccjklppp

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

Last edited 22 months ago by ccjklppp (previous) (diff)

comment:3 Changed 22 months ago by Even Rouault

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

comment:4 Changed 22 months ago by 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

comment:5 in reply to:  4 Changed 22 months ago by Even Rouault

Resolution: invalid
Status: newclosed

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 Changed 22 months ago by ccjklppp

Why not? So where does it come from? At most coordinate systems the prj string is coming from the gcs.csv parameters...

comment:7 Changed 22 months ago by Even Rouault

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 Changed 22 months ago by ccjklppp

I think you misunderstood me.... Gdal itself created the prj file and it isnt match the gcs.csv file.

comment:9 Changed 22 months ago by Even Rouault

Please provide a clear way of reproducing what you do. I cannot read in your brain and guess what is on your screen.

Changed 22 months ago by ccjklppp

Attachment: testWGS72.tif added

Changed 22 months ago by ccjklppp

Attachment: testWGS84.tif added

comment:10 Changed 22 months ago by ccjklppp

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 Changed 22 months ago by Even Rouault

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 Changed 22 months ago by ccjklppp

I want to change the names of some coordinate systems 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";
        }
Last edited 22 months ago by ccjklppp (previous) (diff)

comment:13 Changed 22 months ago by Even Rouault

Resolution: invalid
Status: closedreopened
Summary: some coordinate systems parameters are not taken from gcs.csvWGS 72 GEOGCS name not correctly morphed to ESRI

trunk r29517, branches/2.0 r29518 "morphToESRI(): use GCS_WGS_1972 as GCS name for EPSG:4322 (patch by ccjklppp, #6027)"

comment:14 Changed 22 months ago by Even Rouault

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.