Opened 11 years ago
Closed 11 years ago
#4853 closed defect (fixed)
How to deal with +proj=etmerc in GDAL ?
Reported by: | Even Rouault | Owned by: | Even Rouault |
---|---|---|---|
Priority: | normal | Milestone: | 1.10.0 |
Component: | OGR_SRS | Version: | unspecified |
Severity: | normal | Keywords: | etmerc |
Cc: | warmerdam |
Description
Issue raised in http://lists.osgeo.org/pipermail/gdal-dev/2012-October/034255.html :
For some transformations of data in Greenland we need the extended precision of the etmerc (Extended Transverse Mercator) projection, which is built into proj4.8. I have succesfully built the proj4.8 library and have gotten a definition like, e.g.: +proj=etmerc +lat_0=0 +lon_0=9 +k=0.9996 +units=m +x_0=500000 +datum=WGS84 +nodefs to work in cs2cs. I am also able to get gdal1.9 to succesfully load my proj.dll and start up (programs like gdalinfo, ogrinfo etc.) 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?
Attachments (1)
Change History (4)
comment:1 by , 11 years ago
by , 11 years ago
Attachment: | ticket4853.patch added |
---|
comment:2 by , 11 years ago
Cc: | added |
---|---|
Owner: | changed from | to
Even,
The proposed approach looks fine to me. Feel free to commit in trunk.
comment:3 by , 11 years ago
Milestone: | → 2.0.0 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
I've attached a proposed patch to deal with etmerc. It does 2 things :
1) When converting a proj.4 string to a OGRSpatialReference object, it will detect the etmerc projection method, and will generate a OSR object with standard definition of TM, but with a PROJ.4 EXTENSION that will keep the original proj.4 string, to be used if reprojection is needed
2) If the OSR_USE_ETMERC configuration option / environmenet variable is defined to TRUE, then OSR object that have the TM projection will be translated into a "+proj=etmerc [...]" proj.4 string instead of "+proj=tmerc [...]"