[OSM-dev] Earth radius
Stadin, Benjamin
Benjamin.Stadin at heidelberg-mobil.com
Sun Jun 19 02:01:34 UTC 2016
For my purpose I can ignore flattening and can assume a radius, because I
need fast math. My requirement is it must not be smaller, and it should be
consistent for conceptional reasons (but not for mathematical or
technical).
Note that the mentioned values come from OSM (as most other maps) using a
"tile pyramid" scheme where tiles of each higher zoom level are exactly
half the size (in m / pixel) compared to the previous zoom level. So the
math behind this is much simpler.
You can check the mod_tile sources for example [1]. See that for example
tile2prjbounds() simply shifts x0 by the zoom level, and x0 is
-20037508.3428 which is the exact half of a the WGS84 radius (or
semi-major axis): 6378137 * 2 * pi = 40075016.6856 / 2 = 20037508.3428. So
these are the actual values used, which is close but not the same as on
the website.
[1]
https://github.com/openstreetmap/mod_tile/blob/6b9611aaf763f4f776d1fd363433
aac7e25cb34b/src/gen_tile.cpp
Am 19.06.16, 03:09 schrieb "Greg Troxel" unter <gdt at ir.bbn.com>:
>
>"Stadin, Benjamin" <Benjamin.Stadin at heidelberg-mobil.com> writes:
>
>> I indeed need to express distances in meters. This is a sinusoidal
>> grid with Varying cell resolutions, matching the length of web
>> mercator tiles at the equator. I could use any value greater or equal
>> to the defined sphere radius, but not smaller. To be consistent, it
>> should be equal.
>
>Things to keep in mind:
>
> WGS84 is an ellipsoid, not a sphere. There is a radius and
> flattening, or alternatively different equatorial and polar radii.
>
> "Web Mercator" or "Spherical Mercator" is not actually Mercator, and
> is not conformal. It projects by assuming a sphere, which isn't
> true. So trying to use one radius to get distances on the surface
> from projected coordinates is not going to work well.
>
>So if you want the right answers, use proj.4, use real WGS84
>coordinates, and use the geodesic functions.
>
>If you need fast math within a local region, I would suggest computing a
>few correct values (a point, offset in easting, offest in northing) by
>going from projected back to geodetic and then calculate geodesics,
>finding out the ratio of distance to projected coords, and then building
>a local approximation function. But if you aren't having CPU pain from
>doing it right, I would just use proj.4.
More information about the dev
mailing list