Am 08.03.2011 16:07, schrieb Josh Doe:
Okay, first of all the proj.4 parameters you gave aren't entirely correct. If you look in the epsg file from proj.4 that I linked to in my earlier message, you'll see that the parameters you claim for EPSG:3785 (sphere) are in fact what proj.4 uses for both EPSG:3785 and EPSG:3857. That's not entirely correct either. If you look at the EPSG definition for 3785 that Martin linked to earlier, you'll see that the _datum_ is spherical. The proj.4 parameter "+nadgrids=@null" (as I linked to earlier) forces proj.4 to NOT convert between the WGS84 (ellipsoidal) and spherical datums. This is all moot since EPSG:3785 is invalid and should never be spoken of again. :)
What do nadgrids have to do here? The transition from an ellipsoid to a sphere can be solved without shift files. Is it a bug of proj4? I've just dropped +nadgrids=@null: it doesn't change anything on the results. EPSG:3785 = uses a sphere with Mercator projection (JOSM is using this) EPSG:3857 = uses an ellipsoid with Mercator projection (we want this)
Also, when you talk about using the inverse transform, you're incorrectly using a different set of coordinate systems to transform between. An application must ensure it is using the correct pair of transforms to ensure no errors are introduced. You're trying to transform with [1], then back with [3], while you should be going back with [4]. Transform [3] should be paired with [2].
But that's what JOSM does! Have a look at JOSM's sourcecode: http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/data/projection/Mercator.java That's the spherical formular. When you draw a point in JOSM (x,y) it gets translated back to the *sphere*, not to the ellipsoid. This spherical information will be stored to the WGS84-database. JOSM identifies its Mercator projection as 3857, but it isn't... _______________________________________________ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
