Support up to 1E7 instead of 1E6

[osmdroid]

Support up to 1E7 instead of 1E6

[kurtzmarc]

You will experience integer overflow at those zoom levels. It will work okay in some locations, but eventually it will overflow and crash.

[kjeremy]

Hm. We haven't seen an issue with that but I believe you. Is there a
recommended route for adding this sort of capability?

On Tue, Jun 17, 2014 at 2:01 PM, kurtzmarc [email protected] wrote:

You will experience integer overflow at those zoom levels. It will work
okay in some locations, but eventually it will overflow and crash.

—
Reply to this email directly or view it on GitHub
#46 (comment).

[devemux86]

What was the reason for not using doubles from the beginning?

[kjeremy]

I think it was because they were slow on original Android devices. That's why google uses ints everywhere for the map api (at least V1, haven't checked out V2).

[devemux86]

Google seems to have moved to doubles at API v2.
https://developer.android.com/reference/com/google/android/gms/maps/model/LatLng.html

Also MapBox implementation (Osmdroid fork) has moved to doubles.
https://github.com/mapbox/mapbox-android-sdk/issues/61

[kurtzmarc]

I think the reason Google Maps used 1E6 is to have fixed precision when passing lat/longs around. They still (likely) have to convert to doubles to do Mercator calculations.

[kurtzmarc]

... and we probably have kept it around because we aim to mirror the Google Maps v1 API, even if it has been superseded by v2 that uses doubles. If we are going to break from that history, then I'd prefer doubles.

[devemux86]

If we are going to break from that history, then I'd prefer doubles.

👍

[kjeremy]

doubles 👍

[MKergall]

doubles 👍

[neilboyd]

I'd prefer to keep the consistency with v1. If we're going to go to v2 then do it completely.

[kurtzmarc]

I am going to close this question since it has been superseded by #48.