The Microsoft Live Maps and Google Maps projection

I have lately seen several blogposts confused about which datum and projection Microsoft’s Live Maps (Virtual Earth) and Google Maps use. As most people already know by now, they render the round earth onto a flat screen using a Mercator projection.

I think the confusion comes from that they actually use two spatial reference systems at the same time:

  1. Geographic  Longitude/Latitude coordinatesystem based on the standard WGS84 datum.
  2. Mercator projection using a datum based on WGS84, BUT modified to be spheric.

So when is what used?

The Javascript API’s use (1) as input when you want to add points, lines and polygons. That is, they expect you to input any geometry in geographical coordinates, and click events etc. will also return geometry in this spatial reference. This is the coordinate system most javascript developers will use. The API will automatically project it to the spheric mercator projection.

If you want to create image overlays, or roll your own tile server on top of the map, you will need to project your images into a spheric mercator projection. The JavaScript APIs are not able to do this for you.

Here’s a bit of facts about the two projections:

The valid range of (1) is: [-180,-85.05112877980659] to [180, 85.05112877980659].

The valid range of (2) is: [-20037508.3427892, -20037508.3427892] to [20037508.3427892, 20037508.3427892]

Well-known Text for (1):

Well-known Text for (2):
PROJCS["Mercator Spheric", GEOGCS["WGS84basedSpheric_GCS", DATUM["WGS84basedSpheric_Datum", SPHEROID["WGS84based_Sphere", 6378137, 0], TOWGS84[0, 0, 0, 0, 0, 0, 0]], PRIMEM["Greenwich", 0, AUTHORITY["EPSG", "8901"]], UNIT["degree", 0.0174532925199433, AUTHORITY["EPSG", "9102"]], AXIS["E", EAST], AXIS["N", NORTH]], PROJECTION["Mercator"], PARAMETER["False_Easting", 0], PARAMETER["False_Northing", 0], PARAMETER["Central_Meridian", 0], PARAMETER["Latitude_of_origin", 0], UNIT["metre", 1, AUTHORITY["EPSG", "9001"]], AXIS["East", EAST], AXIS["North", NORTH]]

Proj.4 definition for (1):
+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs

Proj.4 definition for (2) (see here for an explanation of the weird ’nadgrids’ parameter):
+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs

So why this weird extent for the latitude? First of all, the poles in the Mercator projection extends towards infinity, so at some point they have to cut them off (and who cares about ice anyway - apart from that its melting). If you look at (2) these latitude/longitude values projected into the spheric mercator results in a perfect square, fitting perfectly with squared image tiles, that are simple to sub-divide over and over again, as you zoom in. I expect the reason for the spheric datum is for simplicity and perfomance when reprojecting points from longitude/latitude to screen coordinates. Charlie Savage also has a more mathematical approach to deriving these values.

For a quick introduction to projections, coordinate systems and datums see here.

If you want to know more about how these mapping api's work, keep an eye on Jayant's blog.

Update: We now have an offical EPSG code for the projection. See details here.

Profanity usage

Inspired by xkcd, here's my take on it as a javascript developer:

My Profanity Usage by Browser

To be fair to the numbers above, I first of all base my JavaScript on the Microsoft AJAX client library, so usually this works pretty well with IE7. I start out with making stuff work in IE7 and then adjust it to work in FireFox, IE6, Safari etc. This is probably why I spend more time fixing quirks in FireFox than in IE7. I'm currently doing some testing against Safari 3.0beta, and some of the issues I'm having were often resolved by making some subtle (but illogical) changes in the JavaScript, but these changes were often something I've stumbled upon by sheer luck (hence the profanities). It might just as well be because this is a beta browser. Surprisingly I do find myself spending more time working around issues and bugs in FireFox than in IE, but in the end I'm usually able to come up with a script that works in all major browsers and only have very few tweaks that tests against which browser I'm using (thank God for JS base API's that does most of that work).

IE6 wins as the browser that required the most extra code needed, just because of one thing: PNG Transparency. I need objects that need to know whether its using images that are PNG or not, so I can apply the transparency workaround (but at least this is a well-known workaround). It just complicates the JS API, requiring developers to deal with more properties to ensure it works in IE6. I can't wait till the day where we can sign of that browser version.

So why do I primarily develop in IE7, and not FireFox which seems to be the case for a lot of developers? Many reasons:

  • The debug integration with Visual Studio.NET is lightyears ahead of FireBug and all the other JS debug tools in FireFox (and is the JS console really all I get in Safari 3.0 on Windows?).
  • There are some great tools to browse and modify the DOM, see requests etc. My favorites are "Web Development Helper" which even have JSON and Microsoft AJAX Partial Postback deserializers to help you easier analyze the server responses, and IE Developer Toolbar for viewing the DOM and modifying it on the fly (priceless when you are tweaking your CSS styles).
  • It's the most used browser out there, so this is in my mind also the most important one. I'm not saying the others aren't important, but this should ensure that the most used browser also gets the most preliminary testing.
  • I know all the non-ECMA-Script properties and methods that IE adds to the DOM, so I also know which properties and methods to avoid. I'm not that familiar with Mozilla's extensions and don't want to risk using methods that doesn't exist in other browsers (that just adds to the number of profanities :-).
  • This one is probably going to give me some flaming, but I do think IE7 is the best overall browser.