Consider changing geodetic algorithms

[GoogleCodeExporter]

We've had a few reports of poor results in our projection class. Can someone 
provide some history on the algorithms chosen for osmdroid? The comments 
discuss a margin of error at some zoom levels, so was there a trade off between 
computation and accuracy?

I've had excellent results using the sample code provided by microsoft at:

http://msdn.microsoft.com/en-us/library/bb259689.aspx

I'd suggest we at least run some tests to see if they provide different results.

See Issue 157
See Issue 175

Original issue reported on code.google.com by kurtzm...@gmail.com on 2 Mar 2011 at 4:22

[GoogleCodeExporter]

Maybe this is the source:

http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames

Original comment by kurtzm...@gmail.com on 2 Mar 2011 at 4:34

[GoogleCodeExporter]

The sample code appears to be covered under the Microsoft Limited Public 
License (http://msdn.microsoft.com/en-us/cc300389.aspx#P). This sounds like all 
we have to do is include the license in the source code and we can use it 
freely.

Original comment by kurtzm...@gmail.com on 2 Mar 2011 at 4:40

[GoogleCodeExporter]

That sample looks extremely useful. I suggest we just copy it as-is to our 
project, with a fairly trivial conversion to java of course, and then change 
all the other code that does similar things to use this instead. We're long 
overdue for some tidying up in this area.

I think it would be a VERY good idea to do lots of unit tests for this.  There 
are already a few, but we should add some more BEFORE changing anything.  TDD.

Original comment by neilboyd on 2 Mar 2011 at 11:10

[GoogleCodeExporter]

This issue was updated by revision r847.

Adds better Mercator projection code (not used yet)

Original comment by kurtzm...@gmail.com on 3 Mar 2011 at 2:46

[GoogleCodeExporter]

Any suggestions on how to approach the unit tests? I tried to do some searching 
around and haven't come up with a good reference point with known correct 
values. I tried to find a Google web service that would do Mercator projection 
mathematics but couldn't find anything.

Original comment by kurtzm...@gmail.com on 3 Mar 2011 at 3:10

[GoogleCodeExporter]

It's lame but in the past, I've backed all of the math out to proj4 and used 
that to generate baseline tests.  You'd think even some of that core math 
should be easy, but I've found an endless array of ways to screw it up.

See: https://github.com/stellaeof/nanomaps

Specifically projtest, client/test for tests.  See the Projections object and 
MapTransform class in client/lib/nanomaps.core.js and the 
TileSelector.selectTiles method in client/lib/nanomaps.tiles.js.

This was inspired by several sources including the Microsoft article and some 
experience doing this a few times and getting it wrong or not abstracted to a 
useful level.

Let me know if I can help in any way.  Feel free to cut the calculations out of 
nanomaps, load 'em up an Rhino and use them as a basline if you want to.  I of 
course can't vouch that they are 100% bug free but its at least an accessible 
baseline.

Original comment by ste...@laurenzo.org on 6 Mar 2011 at 6:35

[GoogleCodeExporter]

Well proj4 is highly regarded and used everywhere, so results from that are a 
pretty solid reference. Thanks for providing a link to your tests - we might 
just use your test values and build off of that.

Original comment by kurtzm...@gmail.com on 7 Mar 2011 at 5:26

[GoogleCodeExporter]

I added some simple tests that exercise the TileSystem class and compare it to 
the Mercator class. The comments contain notes on how to go from WGS84 to 
EPSG:900913 to TMS to Google Maps and back using PROJ4.

The algorithms produce equal results when going from pixel to lat/long, but 
when going from lat/long to pixel there needs to be a delta of at least 2 to 
pass. I have to do some more digging when I have time to find which algorithm 
is off. Not sure how good the tests are, but they are a start.

Original comment by kurtzm...@gmail.com on 9 Mar 2011 at 3:34

[GoogleCodeExporter]

What does everybody think about switching to using longs instead of ints for 
all pixel calculations? As-is we have a max zoom level of 22 (23 overflows at 
the max edge) which covers most tile sources, but we have a good opportunity to 
future-proof here and support higher zoom levels.

Original comment by kurtzm...@gmail.com on 11 Mar 2011 at 1:17

[GoogleCodeExporter]

Regarding using longs: I wouldn't bother - YAGNI ;-)

Original comment by neilboyd on 11 Mar 2011 at 7:54

[GoogleCodeExporter]

The attached patch replaces the Mercator class with the TileSystem class. I 
would however like to maybe make some more changes - specifically with making 
nomenclature consistent, maybe consolidate a few functions.

Original comment by kurtzm...@gmail.com on 12 Mar 2011 at 6:18

Attachments:

• TileSystemPatch.patch

[GoogleCodeExporter]

Final patch attached.

Additional changes include moving tile size tracking to TileSystem class, 
removal of dead code, explicit definitions of different nomenclature used for 
different tile systems.

Original comment by kurtzm...@gmail.com on 13 Mar 2011 at 6:53

Attachments:

• TileSystemPatch.patch

[GoogleCodeExporter]

I've been using this patch for a few days now and I have had good results, so I 
am going to check in the changes.

Original comment by kurtzm...@gmail.com on 16 Mar 2011 at 2:59

Attachments:

• TileSystemPatch.patch

[GoogleCodeExporter]

Updated in r877.

Original comment by kurtzm...@gmail.com on 16 Mar 2011 at 3:07

[GoogleCodeExporter]

This issue was updated by revision r881.

Fix for scroll adjustments in zooms where the world size is smaller than the 
screen size and also fixes things like the ScaleBarOverlay getting the proper 
latitude in the center of the screen.

Original comment by kurtzm...@gmail.com on 16 Mar 2011 at 3:58

[GoogleCodeExporter]

This has been working swimmingly. I am going to close the ticket.

Original comment by kurtzm...@gmail.com on 1 Apr 2011 at 1:40

• Changed state: Fixed