Opened 2 years ago

Closed 2 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)

testWGS72.tif (48.5 KB) - added by ccjklppp 2 years ago.
testWGS84.tif (48.4 KB) - added by ccjklppp 2 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 2 years 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 2 years 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 2 years ago by ccjklppp (previous) (diff)

comment:3 Changed 2 years 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 2 years 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 2 years 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 2 years 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 2 years 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 2 years 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 2 years 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 2 years ago by ccjklppp

Attachment: testWGS72.tif added

Changed 2 years ago by ccjklppp

Attachment: testWGS84.tif added

comment:10 Changed 2 years 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 2 years 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 2 years 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 2 years ago by ccjklppp (previous) (diff)

comment:13 Changed 2 years 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 2 years ago by Even Rouault

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