SharpGIS

#GIS from a .NET developer's perspective

Spherical/Web Mercator: EPSG code 3785

I just received an update from the EPSG mailing list:

New to Version 6.15 are (among other things): Added spherical Mercator coordinate operation method and associated CRS as seen in popular web mapping and visualisation applications.

It looks like they FINALLY added the spherical Mercator / Web Mercator projection used in Virtual Earth and Google Maps.

This is a big surprise. EPSG’s earlier statement whether to include it was this:

"We have reviewed the coordinate reference system used by Microsoft, Google, etc. and believe that it is technically flawed. We will not devalue the EPSG dataset by including such inappropriate geodesy and cartography.

Guess they changed their mind, or did they just devalue their dataset? Then again, judging from the remarks EPSG put in there, their arrogance still shines through. There´s absolute nothing wrong with using a sphere instead of a flattened sphere. Sure it's not as accurate as for instance WGS84, but then again WGS84 is not accurate either - no ellipsoid is. But we know the exact differences between the two, and as always you will need to take these things into account so I don´t see the real issue. Viisually the distortion is far less than what you would notice, and when doing area, distance and bearing calculations you would first of all never use the mercator units without taking the projection distortion into account, and if you do your calculationg in long/lat it's more or less just as easy to use WGS84 as a base for your calculations (since no datum transform is really needed).

Anyway, finally we get an official code for "Web Mercator": EPSG:3785 

Here are the details of the entry:

Full WKT with authorities (untested!):
PROJCS["Popular Visualisation CRS / Mercator", GEOGCS["Popular Visualisation CRS", DATUM["Popular Visualisation Datum", SPHEROID["Popular Visualisation Sphere", 6378137, 0, AUTHORITY["EPSG",7059]], TOWGS84[0, 0, 0, 0, 0, 0, 0], AUTHORITY["EPSG",6055]], PRIMEM["Greenwich", 0, AUTHORITY["EPSG", "8901"]], UNIT["degree", 0.0174532925199433, AUTHORITY["EPSG", "9102"]], AXIS["E", EAST], AXIS["N", NORTH], AUTHORITY["EPSG",4055]], 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], AUTHORITY["EPSG",3785]]
  

Projected CRS
COORD_REF_SYS_CODE: 3785
COORD_REF_SYS_NAME: Popular Visualisation CRS / Mercator   
AREA_OF_USE_CODE: 3544   
COORD_REF_SYS_KIND: projected   
COORD_SYS_CODE: 4499       
DATUM_CODE:
SOURCE_GEOGCRS_CODE: 4055 (see below)
PROJECTION_CONV_CODE: 19847   
CMPD_HORIZCRS_CODE:
CMPD_VERTCRS_CODE:
CRS_SCOPE: Certain Web mapping and visualisation applications.   
REMARKS: Uses spherical development. Relative to an ellipsoidal development errors of up to 800 metres in position and 0.7% in scale may arise. Some applications call this WGS 84. It is not a recognised geodetic system: see WGS 84 / World Mercator (CRS code 3395)   
INFORMATION_SOURCE: Microsoft.
DATA_SOURCE: OGP
REVISION_DATE: 3/14/2008
CHANGE_ID:
SHOW_CRS: TRUE
DEPRECATED: FALSE

Geographic CRS:
COORD_REF_SYS_CODE: 4055
COORD_REF_SYS_NAME: Popular Visualisation CRS
AREA_OF_USE_CODE: 31262
COORD_REF_SYS_KIND: geographic 2D
COORD_SYS_CODE: 6422
DATUM_CODE: 6055 (see below)
SOURCE_GEOGCRS_CODE:
PROJECTION_CONV_CODE:
CMPD_HORIZCRS_CODE:
CMPD_VERTCRS_CODE:
CRS_SCOPE: Certain Web mapping and visualisation applications.
REMARKS: Some applications erroneously call this WGS 84. It uses a sphere with a radius having the same value as the semi-major axis of the WGS 84 ellipsoid. There is no geodetic recognition of this system.
INFORMATION_SOURCE: Microsoft.
DATA_SOURCE: OGP
REVISION_DATE: 3/13/2008
CHANGE_ID:
SHOW_CRS: TRUE
DATUM_CODE: FALSE


Datum:
Code: 6055       
Datum Name: Popular Visualisation
Datum Type: geodetic
Origin Description: Not specified in the classical sense of defining a geodetic datum.
Datum Epoch:
Ellipsoid Code: 7059 (see below)
Prime Meridian Code: 8901
Area Code: 1262
Datum Scope    : Used by certain popular Web mapping and visualisation applications.
Remarks: Not recognised by geodetic authorities.
Information Source: Microsoft.
Data Source: OGP   
Revision Date: 13-Mar-08
Change ID:
Deprecated: No


Ellipsoid:
Code: 7059
Ellipsoid Name: Popular Visualisation Sphere   
Semi-major axis (a): 6378137   
Axes units code: 9001       
Inverse flattening (1/f):
Semi-minor axis (b): 6378137   
Ellipsoid?: No   
Remarks: Sphere with radius equal to the semi-major axis of the GRS80 and WGS 84 ellipsoids. Used only for Web approximate mapping and visualisation. Not recognised by geodetic authorities.   
Information Source: Microsoft.
Data Source: OGP
Revision Date: 14-Mar-08
Change ID:   
Deprecated?: No

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):
GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.0174532925199433]]

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.