[josm-dev] projection Mercator, set EPSG 3785 instead of EPSG 3857

[Josh Doe]

I'm not entirely sure what you mean.

Per the OSM wiki, all coordinates are in WGS 84, which certainly
employs an ellipsoid. Data users and providers are responsible for
transforming between WGS84 and whatever coordinate system they are
using. Thankfully WGS84 is the most commonly used system. If I make a
trace with my GPS, and it uses WGS84 (which most if not all do), and I
then upload it to OSM, all is well. So far there has been no need to
transform coordinates, or even know a single thing about spheres,
ellipsoids, or anything else. Once I pull that trace into JOSM (or any
tool), I need to map those coordinates to the screen. One of the
simplest ways is to use the Mercator projection EPSG:3857, which
transforms the ellipsoidal WGS84 to a square. Note however that when
transforming to the square it is not using an ellipsoid, but rather
treating the coordinates as if they were on a sphere.

Really it doesn't matter what transformation you do, you could even
make up your own. The important thing is that before pushing changes
back to OSM you perform the inverse transformation, and of course if
you're using other data or imagery you need to make sure you are using
the same coordinate system.

And as far as OSM putting "both datums on the same level", I have to
disagree. OSM itself explicitly says all coordinates are in WGS84.
There may be certain applications which mix things up, but that's not
the fault of OSM.

Trust me, I know this is confusing, and if I'm saying something wrong
please correct me!

-Josh

On Tue, Mar 8, 2011 at 8:29 AM, Tobias Wendorff
<tobias.wendorff at tu-dortmund.de> wrote:
> Am 08.03.2011 13:39, schrieb Josh Doe:
>> Thus the inverse flattening that Martin mentions refers
>> to the WGS 84 datum, not the EPSG:3857 projection from
>> that datum.
>
> Yeah, but change in this datum has big outcome on the
> projection. The formular used is much more complex now.
>
> On a sphere, you can use Pi and spherical geometry to
> calculate the x/y-coordinates. On a ellipsoid, you need
> "expensive" expansion in series.
>
> Right now, OSM puts both datums on the same level, which
> is wrong in geodetic use, but the error is okay for non
> critical applications (1/298,257223563 = 0,0033528106 unity).
>