Datum EUR not recognized by the AAIGrid/Arc/Info ASCII Grid driver

[alessandro_amici@…]

using gdal-1.1.9 the .prj file:

Projection    UTM
Zone          32
Datum         EUR   <--------------------------
Zunits        NO
Units         METERS
Spheroid      INTERNATIONAL1909
Xshift        0.0000000000
Yshift        0.0000000000
Parameters

results in the following map info:
Coordinate System is:
PROJCS["UTM Zone 32, Northern Hemisphere",
    GEOGCS["WGS 84",
        DATUM["WGS_1984",
            SPHEROID["WGS 84",6378137,298.257223563, <---------------
                AUTHORITY["EPSG","7030"]],
            TOWGS84[0,0,0,0,0,0,0],
            AUTHORITY["EPSG","6326"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9108"]],
        AXIS["Lat",NORTH],
        AXIS["Long",EAST],
        AUTHORITY["EPSG","4326"]],
    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["METERS",1]]

supposedly the data are referred to the ED50 datum
thanks

[alessandro_amici@…]

i tracked the problem to ogr_srs_esri.cpp:OGRSpatialReference::importFromESRI()
where only american data are accepted.

something along the lines of the untested bit:

if( EQUAL(pszDatum,"NAD27") || EQUAL(pszDatum,"NAD83")
    || EQUAL(pszDatum,"WGS84") || EQUAL(pszDatum,"WGS72") )
{
   SetWellKnownGeogCS( pszDatum );
}
+else if( EQUAL(pszDatum,"EUR") )
+{
+   SetWellKnownGeogCS( "EPSG:6230" );
+}
else
{

might be part of the solution. i'm not sure about the epsg number, because
the python bindings to SetWellKnownGeogCS don't work as expected either!

NOTE: i don't know HOW these files have been produced (which software,
version etc.).

[alessandro_amici@…]

 
a better EPSG identifier is 4230! 
 
and the problem with the python bindings was a user error ;) 

[warmerdam]

Alessandro, 

I have applied the patch (with 4230) as suggested without any actual testing. 
I think the solution is good, though in the long term we really need a table
mapping ESRI datums to their EPSG equivelents.