[gdal-dev] +proj=etmerc in ogr2ogr

[Simon Lyngby Kokkendorff]

Hi Even,

  Thanks a lot :-) I'll try the workaround and keep an eye open for when/if
the patch goes into trunk.

  Cheers,
  Simon


On Mon, Oct 8, 2012 at 10:07 PM, Even Rouault
<even.rouault at mines-paris.org>wrote:

> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20121008/6bc22ec7/attachment.html>