The Layer object can understand what projection you’re working in, if you happen to give it one. If the displayed map area happens to wrap around the IDL (and your layers are set up correctly), the Layer object gracefully acknowledges the IDL and produces correct coordinates.

In contrast, the Bounds object is pure math. It’s meant to be as projection-agnostic as possible without actually messing up coordinates in objects that do know about projections and their quirks. This can be a very good thing, since doing math without worrying about projections is a lot faster and works just fine in most cases.

The problem I ran into comes from one little Layer object configuration option that is uncharacteristically poorly documented: wrapDateLine. The issue it tells you to reference (#487) talks about using modular arithmatic to fix how layers handle the IDL… I’m not a math person, but handling the IDL is exactly what I want it to do! Too bad they couldn’t have mentioned this in the documentation.    What the Map winds up doing if you don’t have this config option set is using the Bounds object’s straight-up math to get the center of the extent. Unfortunately, using straight math when the IDL is in play puts the center of the map at the longitude exactly opposite of where logic dictates it should go. If the wrapDateLine configuration item is set, then the Layer tells the Map “Whoa, there! The Bounds object doesn’t know about the IDL, but I do. Use my math first.” So the Map uses the Layer’s math to turn the extent into coordinates that the Bounds object’s math will work correctly on. Viola! The North Pacific!

So the simple fix is to have wrapDateLine: true in your layer configuration object.

To see this bit of oddness ‘in action’, go to the OpenLayers Google Map example and pan the map so that the IDL is in view. Using FireBug, enter the commands map.getCenter() and map.getExtent().getCenterLonLat(). The resulting coordinate longitudes will be on opposite sides of the planet.

For Sourcemap, we started visualizing larger and larger networks, and began noticing that nothing from China was ever connected to anything in North America vai the Pacific Ocean. When you want to visualize a globally connected network, it helps if the network knows that the map is a globe, and creates connections in the direction that minimizes the distance between points.  Using the built in cartography of OpenLayers, we get the following map:

Where the network is always constrained within the rectangle of -180, -90, 180, 90 (x_min, y_min, x_max, y_max).  I approached this a couple of ways, and the one that turned out to be the easiest exploits a lesser-known ‘feature’ of OpenLayers, whereby a Longitude that exceeds the coordinate system (e.g. -200) is indeed rendered on the opposite side of the IDL (e.g. +160).

This is excellent! Now I know that OpenLayers can render multiple instances of a feature in a single map.  Instead of adding single vector features, I added multipart features{multipoint and multiline), with each individual feature in that multipart offset by 360 degrees from the next.

Interestingly enough, OpenLayers also does some flipping of your features when you cross the IDL.  When you grab the map and pan across the IDL, your features will flip into the coordinate system that contains the center point of the map.  For this reason, I created 3 versions of everything, and placed them at (x – 360), (x), and (x + 360).  This allows for continuous coverage on the map, even when the features are flipped over the IDL.

The result:

Now the maps reflect more accurately the trip of objects around the world! Each line is the shortest path between points, and are allowed to cross the IDL if necessary.  For the purposes of Sourcemap, it was important to be able to show these trips, since we are discussing ways of modeling the transportation networks of goods around the world.

In the midst of implementing Google Maps in our up-coming Sajara sample application, I realized that the International Date Line was causing problems. Large problems. Whenever the IDL was in play, I never retrieved the correct results from our database. One large problem was how we defined our bounding box inside Sajara itself. Once that was fixed, however, I realized that something was still wrong. The Nearest-to-Farthest sort was not behaving quite right: it was really doing a Nearest-on-this-side-of-the-IDL-first sort! The IDL was acting like a wall for our distance sort.

Example of linear distance with IDL in play. X = center of map

Here’s what we used before (in sql-speak):

RETURN sqrt(power(@FromX - @ToX,2) + power(@FromY - @ToY,2))

Your standard square-root of difference-squared plus difference-squared. This formula is fast and worked perfectly well so long as I operated under these two criteria:

1. a FLAT projection
2. POSITIVE numbers only

Once either of those things aren’t true anymore, I can’t use the basic distance formula. In my case, both things stopped being true at the same time! The solution? Something fairly math-magical to my mind, but accepted as THE formula to get at the distance between any two global coordinates: the Haversine Formula. Delving into descriptions of the formula brings up concepts such as spherical triangles, the planet’s elipticity, great circles and other things very important to navigation. It’s accurate down to about a meter, which is plenty for anything I’ll be doing with it.

Haversine Formula in Javascript:

var R = 6371; // radius of the earth
var dLat = (lat2-lat1).toRad();
var dLon = (lon2-lon1).toRad();
var a = Math.sin(dLat/2) * Math.sin(dLat/2) +
        Math.cos(lat1.toRad()) * Math.cos(lat2.toRad()) *
        Math.sin(dLon/2) * Math.sin(dLon/2);
var c = 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1-a));
var distance = R * c;

So here is the resulting SQL function that gives me the right distance between any two global coordinates.. basically a direct translation of the above javascript into T-SQL:

CREATE FUNCTION [dbo].[distance] (@FromX float, @FromY float, @ToX float, @ToY float)
RETURNS float AS BEGIN
DECLARE @R AS FLOAT;
SET @R = 6371;
DECLARE @DLAT AS FLOAT;
DECLARE @DLON AS FLOAT;
DECLARE @A AS FLOAT;
DECLARE @C AS FLOAT;
DECLARE @D AS FLOAT;
SET @DLAT = RADIANS(@ToY - @FromY);
SET @DLON = RADIANS(@ToX - @FromX);
SET @A =
SIN(@DLAT/2) * SIN(@DLAT/2) +
COS(RADIANS(@FromY)) * COS(RADIANS(@ToY)) * SIN(@DLON/2) * SIN(@DLON/2);
SET @C = 2 * ATN2(SQRT(@A), SQRT(1-@A));
SET @D = @R * @C;
RETURN @D
END