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 <[email protected]>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 >
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
