[gdal-dev] +proj=etmerc in ogr2ogr

[Even Rouault]

> However, if I try to run ogr2ogr like:
> 
>  ogr2ogr -s_srs "EPSG:25832" -t_srs "+proj=etmerc +lat_0=0 +lon_0=9
> +k=0.9996
>  +units=m +x_0=500000 +datum=WGS84 +nodefs" C:\DHM\analysis\bakke2.shp
> C:\DHM\analysis\shape\
> bakke.shp
> 
> I get the following error:
> 
> Failed to process SRS definition: +proj=etmerc +lat_0=0 +lon_0=9 +k=0.9996
> +unit
> s=m +x_0=500000 +datum=WGS84 +nodefs
> 
> It works fine if I change +proj=etmerc to +proj=tmerc. Seems to me, that
> somehow +proj=etmerc is not build into the "metadata system" of gdal/ogr,
> so that it is not translatable to e.g. a ESRI-wkt definition. Might this be
> that case, and if so, what should I update in order to get this to work?

Simon,

When passing a proj.4 string to GDAL/OGR, it will try to construct a 
OGRSpatialReference object, which is a model of the WKT representation of the 
SRS. To be able to do that, it must recognize projection methods, and this is 
consequently hard-coded in ogr/ogr_srs_proj4.cpp.

There's no code currently to recognized +proj=etmerc, hence the failure.

However, there's a workaround. In GDAL 2.0dev, you could just add "+wktext" in 
the proj.4 string :

$ testepsg "+proj=etmerc +lat_0=0 +lon_0=9 +k=0.9996 +units=m +x_0=500000 
+datum=WGS84 +nodefs +wktext"
Validate Fails.
WKT[+proj=etmerc +lat_0=0 +lon_0=9 +k=0.9996 +units=m +x_0=500000 +datum=WGS84 
+nodefs +wktext] =

PROJCS["unnamed",
    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"]],
        AUTHORITY["EPSG","4326"]],
    PROJECTION["custom_proj4"],
    UNIT["Meter",1],
    EXTENSION["PROJ4","+proj=etmerc +lat_0=0 +lon_0=9 +k=0.9996 +units=m 
+x_0=500000 +datum=WGS84 +nodefs +wktext"]]

The WKT representation built is somewhat invalid (see the "custom_proj4" 
PROJECTION), but it has a PROJ4 EXTENSION with the correct proj.4 string, 
hence the reprojection computations will work as expected.

That syntaxic sugar is new to GDAL 2.0dev and doesn't work in previous 
versions. So for GDAL 1.9, you would have to put the above WKT into a file and 
use it as the -t_srs argument.

The drawback of this is that the "custom_proj4" projection cannot be 
translated into something useful in a ESRI .PRJ file.

The best is then to use a more standard WKT of a TM projection, but with the 
appropriate proj.4 extension with etmerc :

PROJCS["unnamed",
    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"]],
        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["Meter",1],
    EXTENSION["PROJ4","+proj=etmerc +lat_0=0 +lon_0=9 +k=0.9996 +units=m 
+x_0=500000 +datum=WGS84 +nodefs +wktext"]]

Let's suppose you put it into etmerc.wkt, then you can use :

ogr2ogr -t_srs etmerc.wkt destination.shp source.shp

Note that ogrinfo on the destination.shp will report standard TM, and will not 
have any more the etmerc method, so if you need to reproject afterwards, you 
will need to specify explicitely the etmerc.wkt again.

I've opened the http://trac.osgeo.org/gdal/ticket/4853 ticket with a proposed 
patch to make things more user friendly. I haven't applied it yet, because I 
would appreciate FrankW's opinion to know if this is the right way of dealing 
with that. etmerc is something particular, since it isn't per se a projection, 
but rather a projection computation algorithm. I don't think that GDAL has 
already dealt with that kind of situation.

Best regards,

Even