Opened 9 years ago
Closed 8 years ago
#5857 closed defect (invalid)
Invalid coordinate transformation using radian units in GEOGCS inside PROJCS
Reported by: | drons | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | OGR_SRS | Version: | 1.11.1 |
Severity: | normal | Keywords: | |
Cc: |
Description
Hello!
I encountered the file (r.prj) with the projection that follows:
PROJCS["GK_Zone_59", GEOGCS["CS-1942",DATUM["Pulkovo 1942", SPHEROID["Krasovsky",6378245,298.3]], TOWGS84[23.9,-141.3,-80.9,-0,0.371276651,0.849811002,-0.12], PRIMEM["Greenwich",0], UNIT["radian",1]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",351], PARAMETER["scale_factor",1], PARAMETER["false_easting",59500000.0000000000000000], PARAMETER["false_northing",0], UNIT["Meter",1], AXIS["Y", EAST],AXIS["X", NORTH] ]
Export to proj4 format looks fine exportToProj4(r.prj):
+proj=tmerc +lat_0=0 +lon_0=351 +k=1 +x_0=59500000 +y_0=0 +ellps=krass +towgs84=23.9,-141.3,-80.9,-0,0.371276651,0.849811002,-0.12 +units=m +no_defs
But transformation to any other coordinate system produces wrong result. If we change angular unit to degree (d.prj) coordinate transform works properly.
It's strange that exportToProj4(d.prj) is equal to exportToProj4(r.prj).
exportToProj4(d.prj):
+proj=tmerc +lat_0=0 +lon_0=351 +k=1 +x_0=59500000 +y_0=0 +ellps=krass +towgs84=23.9,-141.3,-80.9,-0,0.371276651,0.849811002,-0.12 +units=m +no_defs
Change History (2)
comment:1 by , 9 years ago
comment:2 by , 8 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
I think ticket may be closed as invalid.
Note:
See TracTickets
for help on using tickets.
I think the .prj file is broken. central_meridian=351 makes no sense. Either if you interpret it as deegrees (351 degrees) or as radians (which should be the interpretation. but 351 radians = 20110 deegrees !)
Then what you indicate as the result of exportToProj4(r.prj) is not at all what I get with
Note: the lon_0=20110... which is the transform from radians to deegrees, since proj always assume deegrees for angular values
So I think OGR does the right job here.