wrap the dateline

[jrf]

Make all longitudes into "positive and negative clock numbers modulo Pi" using  modular arithmetic, so that everything wraps around the dateline correctly. This will mean special changes for most layers, because different layers handle the dateline differently. Most will need to need a hard stop that gets only visually matched with the other side.

This may mean special stuff in the vector branch, e.g. what happens when some draws a line across the dateline? or drags a polygon across the dateline? or clicks in a feature that is on both sides of the dateline?

While it would be nice to also work out the code for pole crossing, it is more complex than just making latitudes into positive and negative clock numbers modulo Pi/2, because the singularity at the pole creates an orientation ambiguity that can only be remedied in one of two ways:

• choosing a special angle or set of angles for approaching the pole, and forcing users approaching the pole to follow one of these lines. Something like this is happening in  Map Point's South Pole.
• rotating the entire map image as the user pans the map anywhere on the globe. To see this, try  dragging the arrow in many little circles on this globe.

I think this means that pole crossing should wait for later.

[crschmidt]

Thought from tschaub: Move to OL 3.0. Make everything use XY instead of LonLat, and LonLat is special because it wraps.

[tschaub]

A fun exercise while considering dateline wrapping is to draw lines with Google's "My Maps". If you zoom way out, things start out well as you are given 360 degrees to play with. When you stray beyond the initial 360, your point wraps to the other side of the map though your cursor stays fixed. As you add points and pan, it looks like this 360 degree window shifts, always giving you a good bit of room to add points. Things quickly fall apart however if you start adding points at zoom 0 or so, then zoom to 2 or 3 and keep adding points. Points are orphaned, lines fall apart, and things get crazy. Similar craziness ensues when modifying polygons that wrap.

[crschmidt]

What it does:

• New option 'wrapDateLine' on the base layer
• Wraps zoomToExtent
• Wraps getLonLatFromPixel
• Function 'adjustBounds' on layer does wrapping
• Moved adjustBoundsForGutter inside adjustBounds
• added calls to adjustBounds in all the getURL functions which can support it. (Grid layers, mostly.)

Limitations/expectations of this patch:

• It is expected behavior that the layer's getPixelFromLonLat will not wrap. This means that if you are looking at Australia and Hawai'i, and you place a marker at 175, it will end up visible or not visible depending on which side of the date line you're on.
• Vector drawing across the date line is not supported. (Your mouse will 'snap' to the other part of the world.)
• Requests which cross the date line are *not* wrapped, so they will request content outside the world if it does not divide evenly.

[sderle]

crschmidt's patch with a typo corrected (r3277)

[crschmidt]

There's a newer version in SVN. We should make a new patch before committing.

[euzuro]

i'm currently reviewing this ticket from cr5's sandbox making a few small changes.

[euzuro]

this is my reworked patch for the dateline wrapping. it is taken pretty much directly from crschmidt's "wraptheworld" sandbox. All tests pass in ff & ie6.

[euzuro]

i just new patch. please RUN TESTS (just in case) and review.

[crschmidt]

Tests pass. Code works. And the sunshine smiled upon you, and it was said 'let it be done'.

[euzuro]

fixed with r3323