Opened 21 years ago
Last modified 21 years ago
#355 closed defect (fixed)
OSRImportFromProj4() incorrectly parses some valid PROJ.4 parameter strings
Reported by: | Owned by: | warmerdam | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | OGR_SRS | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: |
Description
===1=== If the string includes a + sign not as the initial character of a parameter, e.g. as part of the exponent of a number, it is incorrectly parsed. e.g. +proj=lcc +x_0=0.6096012192024384e+06 +y_0=0 +lon_0=90dw +lat_0=42dn +lat_1=44d4'n +lat_2=42d44'n +a=6378206.400000 +rf=294.978698 +nadgrids=conus,ntv1_can.dat ===2=== A Transverse Mercator parameter string that uses the 'preferred' +k_0=n rather than +k=n (see http://remotesensing.org/lists/proj_archive/msg00067.html) to indicate the scale on the central meridian has the scale factor set to the default of 1 instead of n in the resulting WKT. e.g. +proj=tmerc +lat_0=53.5000000000 +lon_0=-8.0000000000 +k_0=1.0000350000 +x_0=200000.0000000000 +y_0=250000.0000000000 +a=6377340.189000 +rf=299.324965 +towgs84=482.530,-130.596,564.557,-1.042,-0.214,-0.631,8.15 (both the example strings were created by the GRASS g.setproj program and work fine for use with PROJ.4, but I was trying to add some functions to GRASS to export the co-ordinate system in WKT format and came across these problems). Paul Kelly
Change History (3)
comment:2 by , 21 years ago
I have committed a fix to ogr_srs_proj4.cpp to handle this. The module now has a local custom PROJ.4 parsing function that takes this situation into account. Also added tests for both problems in gdalautotest/osr/osr_proj4.py. I am still looking into the pj_init_plus() function which I think has a similar problem.
comment:3 by , 21 years ago
Similar problem with handling of plus signs existed in proj.4's pj_init_plus(). This has been corrected too.
Note:
See TracTickets
for help on using tickets.