Hi Even,<br><br> Thanks a lot :-) I'll try the workaround and keep an eye open for when/if the patch goes into trunk.<br><br> Cheers,<br> Simon<br><br><br><div class="gmail_quote">On Mon, Oct 8, 2012 at 10:07 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org" target="_blank">even.rouault@mines-paris.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> However, if I try to run ogr2ogr like:<br>
><br>
> ogr2ogr -s_srs "EPSG:25832" -t_srs "+proj=etmerc +lat_0=0 +lon_0=9<br>
> +k=0.9996<br>
> +units=m +x_0=500000 +datum=WGS84 +nodefs" C:\DHM\analysis\bakke2.shp<br>
> C:\DHM\analysis\shape\<br>
> bakke.shp<br>
><br>
> I get the following error:<br>
><br>
> Failed to process SRS definition: +proj=etmerc +lat_0=0 +lon_0=9 +k=0.9996<br>
> +unit<br>
> s=m +x_0=500000 +datum=WGS84 +nodefs<br>
><br>
> It works fine if I change +proj=etmerc to +proj=tmerc. Seems to me, that<br>
> somehow +proj=etmerc is not build into the "metadata system" of gdal/ogr,<br>
> so that it is not translatable to e.g. a ESRI-wkt definition. Might this be<br>
> that case, and if so, what should I update in order to get this to work?<br>
<br>
</div>Simon,<br>
<br>
When passing a proj.4 string to GDAL/OGR, it will try to construct a<br>
OGRSpatialReference object, which is a model of the WKT representation of the<br>
SRS. To be able to do that, it must recognize projection methods, and this is<br>
consequently hard-coded in ogr/ogr_srs_proj4.cpp.<br>
<br>
There's no code currently to recognized +proj=etmerc, hence the failure.<br>
<br>
However, there's a workaround. In GDAL 2.0dev, you could just add "+wktext" in<br>
the proj.4 string :<br>
<br>
$ testepsg "+proj=etmerc +lat_0=0 +lon_0=9 +k=0.9996 +units=m +x_0=500000<br>
+datum=WGS84 +nodefs +wktext"<br>
Validate Fails.<br>
WKT[+proj=etmerc +lat_0=0 +lon_0=9 +k=0.9996 +units=m +x_0=500000 +datum=WGS84<br>
+nodefs +wktext] =<br>
<br>
PROJCS["unnamed",<br>
GEOGCS["WGS 84",<br>
DATUM["WGS_1984",<br>
SPHEROID["WGS 84",6378137,298.257223563,<br>
AUTHORITY["EPSG","7030"]],<br>
TOWGS84[0,0,0,0,0,0,0],<br>
AUTHORITY["EPSG","6326"]],<br>
PRIMEM["Greenwich",0,<br>
AUTHORITY["EPSG","8901"]],<br>
UNIT["degree",0.0174532925199433,<br>
AUTHORITY["EPSG","9108"]],<br>
AUTHORITY["EPSG","4326"]],<br>
PROJECTION["custom_proj4"],<br>
UNIT["Meter",1],<br>
EXTENSION["PROJ4","+proj=etmerc +lat_0=0 +lon_0=9 +k=0.9996 +units=m<br>
+x_0=500000 +datum=WGS84 +nodefs +wktext"]]<br>
<br>
The WKT representation built is somewhat invalid (see the "custom_proj4"<br>
PROJECTION), but it has a PROJ4 EXTENSION with the correct proj.4 string,<br>
hence the reprojection computations will work as expected.<br>
<br>
That syntaxic sugar is new to GDAL 2.0dev and doesn't work in previous<br>
versions. So for GDAL 1.9, you would have to put the above WKT into a file and<br>
use it as the -t_srs argument.<br>
<br>
The drawback of this is that the "custom_proj4" projection cannot be<br>
translated into something useful in a ESRI .PRJ file.<br>
<br>
The best is then to use a more standard WKT of a TM projection, but with the<br>
appropriate proj.4 extension with etmerc :<br>
<br>
PROJCS["unnamed",<br>
GEOGCS["WGS 84",<br>
DATUM["WGS_1984",<br>
SPHEROID["WGS 84",6378137,298.257223563,<br>
AUTHORITY["EPSG","7030"]],<br>
TOWGS84[0,0,0,0,0,0,0],<br>
AUTHORITY["EPSG","6326"]],<br>
PRIMEM["Greenwich",0,<br>
AUTHORITY["EPSG","8901"]],<br>
UNIT["degree",0.0174532925199433,<br>
AUTHORITY["EPSG","9108"]],<br>
AUTHORITY["EPSG","4326"]],<br>
PROJECTION["Transverse_Mercator"],<br>
PARAMETER["latitude_of_origin",0],<br>
PARAMETER["central_meridian",9],<br>
PARAMETER["scale_factor",0.9996],<br>
PARAMETER["false_easting",500000],<br>
PARAMETER["false_northing",0],<br>
UNIT["Meter",1],<br>
EXTENSION["PROJ4","+proj=etmerc +lat_0=0 +lon_0=9 +k=0.9996 +units=m<br>
+x_0=500000 +datum=WGS84 +nodefs +wktext"]]<br>
<br>
Let's suppose you put it into etmerc.wkt, then you can use :<br>
<br>
ogr2ogr -t_srs etmerc.wkt destination.shp source.shp<br>
<br>
Note that ogrinfo on the destination.shp will report standard TM, and will not<br>
have any more the etmerc method, so if you need to reproject afterwards, you<br>
will need to specify explicitely the etmerc.wkt again.<br>
<br>
I've opened the <a href="http://trac.osgeo.org/gdal/ticket/4853" target="_blank">http://trac.osgeo.org/gdal/ticket/4853</a> ticket with a proposed<br>
patch to make things more user friendly. I haven't applied it yet, because I<br>
would appreciate FrankW's opinion to know if this is the right way of dealing<br>
with that. etmerc is something particular, since it isn't per se a projection,<br>
but rather a projection computation algorithm. I don't think that GDAL has<br>
already dealt with that kind of situation.<br>
<br>
Best regards,<br>
<br>
Even<br>
</blockquote></div><br>