Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ScaleControl uses inconsistent earth radius #8777

Closed
exe-dealer opened this issue Sep 19, 2019 · 9 comments
Closed

ScaleControl uses inconsistent earth radius #8777

exe-dealer opened this issue Sep 19, 2019 · 9 comments

Comments

@exe-dealer
Copy link

exe-dealer commented Sep 19, 2019

mapbox-gl-js version: 1.3.1

browser: *

Why scale control uses different earth radius than mercator projection code? Is this ok?

const R = 6371000;

const circumferenceAtEquator = 2 * Math.PI * 6378137;

@ryanhamley
Copy link
Contributor

ryanhamley commented Sep 19, 2019

Hmm, that's a good question. I think the radius in scale_control is fine.

From Wikipedia:

for small scale (large region) applications the variation may be ignored, and mean values of 6,371 km and 40,030 km may be taken for the radius and circumference respectively

@andrewharvey I'm guessing that because you're calculating the circumference at the equator, you wanted a more exact radius than is needed for the spherical approximation in the scale, which I think is also fine. If we want to coordinate values like this, maybe it would be a good idea to pull them into a file that could be included elsewhere so we can define them once and not have inconsistencies in the code.

@andrewharvey
Copy link
Collaborator

The figure in mercator_coordinate came from the EPSG:3857 definition.

@mourner
Copy link
Member

mourner commented Sep 20, 2019

@andrewharvey given how the value is used in MercatorCoordinate, I think we should change it to mean radius value rather than the equator one from EPSG:3857. The latter also defines inverse flattening (298.257223563) which defines how this radius varies across the globe.

@andrewharvey
Copy link
Collaborator

@andrewharvey given how the value is used in MercatorCoordinate, I think we should change it to mean radius value rather than the equator one from EPSG:3857. The latter also defines inverse flattening (298.257223563) which defines how this radius varies across the globe.

@mourner Sorry I don't understand. What does "radius value" mean here?

At the equator (ie. along the semi-major axis) the inverse flattening won't matter or affect it right? And then we use the scale factor to account for larger latitudes being larger on the map.

@mourner
Copy link
Member

mourner commented Sep 21, 2019

@andrewharvey at the equator, it won't, but at other latitudes, it will — the Earth radius (the circumference is calculated from) will be smaller. You can either account for that with complicated formulas, or take a mean value across latitude range for simplicity — super-precision isn't important for the scale control anyway.

@andrewharvey
Copy link
Collaborator

@andrewharvey at the equator, it won't, but at other latitudes, it will — the Earth radius (the circumference is calculated from) will be smaller. You can either account for that with complicated formulas, or take a mean value across latitude range for simplicity — super-precision isn't important for the scale control anyway.

Ok, maybe I misunderstood this then, I thought the scale factor formula I used accounted for this. But maybe that's just for the Mercator projection on a spherical datum instead of on the ellipsoidal datum which EPSG:3857 uses..

@mourner
Copy link
Member

mourner commented Sep 23, 2019

@andrewharvey yes, exactly. Standard Mercator formulas, including the scale factor one, assume spherical earth and so usually use the mean radius value as approximation.

@Meekohi
Copy link
Contributor

Meekohi commented Jan 17, 2020

Proposed correction: #9202

@ryanhamley
Copy link
Contributor

Closed by #9202. Thanks @Meekohi!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants