Measuring distances and areas when your map uses the Mercator projection

Recently, ArcGIS Online services became available in the same “Web Mercator” projection used by Google Maps and Bing Maps. If you use the new ArcGIS Online services, avoid the temptation to perform measurements of polylines and polygons in Web Mercator. You should instead re-project user-submitted geometries into a more appropriate coordinate system before you perform a measurement.

Why is the Google/Bing/ArcGIS Online projection not acceptable for measurements?

Every map projection causes distortion of shapes, areas, directions, and/or distances. Some projections such as Robinson or Winkel Tripel attempt to minimize distortion across the world through some compromise of all those factors. Other projections (such as UTM and State Plane) are designed for focused areas of the globe in order to keep the distortion minimal.

The modified Mercator projection used by Google, Bing, and ArcGIS Online is not designed to minimize distortion at all. Instead, it was engineered for convenience in working with cached map tiles. This projection fit the entire globe (well, most of the latitudes anyway) into a square area that could be covered by 256 x 256 pixel tiles. The projection sacrifices some accuracy because it is based on a perfect sphere (the earth is better approximated by a spheroid), but the biggest problem is the heavy vertical and horizontal stretching at extreme latitudes. This is evident from the enormous dimensions of Greenland and Antarctica relative to land masses closer to the Equator:

Mercator-based ArcGIS Online map

If you perform measurements in the Mercator projection or the Google/Bing/ArcGIS Online variation thereof, your results will likely be much larger than you intended. In cylindrical projections like this, errors are minimized along the standard parallel(s), and in the case of the Mercator projection, this standard parallel is at the Equator. The farther away from the Equator you get, the more distorted your measurements will be.

So, how should you measure?

Fortunately, you don’t have to perform your measurements in the same coordinate system used by the map. When a user submits a geometry to your application for measurement, you can re-project that geometry into a more appropriate coordinate system for measurement. The re-projected geometry is used internally for measurement only; you don’t display it on the map. Once the measurement is complete, you return the correct result to the user.

This begs the question, which coordinate system should you use for the measurement? There is no answer that fits every application. You should make your decision based on the general area covered by your application. If your application covers a small area, such as a city, county, or perhaps even a state or province, you can use a local coordinate system such as State Plane or UTM. As mentioned before, these are designed to minimize distortion for just the regions or zones that they cover. For example, UTM Zone 1 minimizes distortion between -180 and -174 degrees longitude.

For a larger area, such as a country or continent, you can pick one of the coordinate systems that you would see in ArcMap’s Projected Coordinate Systems > Continental folder, such as North America Lambert Conformal Conic.

If users need to measure any place in the world using your application, consider using a compromise projection designed for displaying the entire world, such as Robinson. An alternative to using a compromise projection may be to write custom code that picks the most fitting coordinate system based on the bounds of the polygon to be measured. Finally, with areas this large, you may attempt to get the geodetic measurement, which takes into account the curvature of the earth. Geodetic polyline measurements are coming in version 2.0 of the ArcGIS APIs for JavaScript, Flex, and Silverlight, and in the SOAP API at ArcGIS 10.

Remember that each coordinate system has its own unit of measurement. The Web Mercator coordinate system used by Google/Bing/ArcGIS Online uses meters. If you project into State Plane to perform your measurements, your returned measurement could be in either meters or feet depending on the variation of the coordinate system you choose. Be careful not to report a mistaken unit in the labels or text in your application. You may need to add some basic conversion math to your code to get the unit you need.

Code example

Here’s a simplified example of how to take a user-submitted polygon, project it into a local coordinate system, and measure the resulting polygon. The code assumes the existence of a geometry service object and a graphic containing a single polygon. This example uses the ArcGIS API for JavaScript, but other ESRI Web mapping APIs allow similar use of the geometry service.

var sr = new esri.SpatialReference({wkid:32610});
geometryService.project([graphic], sr, function(projectedGraphic){   
  geometryService.areasAndLengths(projectedGraphic, function(result){   
    var perimeter = result.lengths[0]; 
    var area = result.areas[0]; 

In the above code, the geometry service projects the graphic from its initial coordinate system to WGS_1984_UTM_Zone_10N (WKID 32610). The geometry service also has an areasAndLengths method that is able to get both the perimeter and the area of the graphic. If you’re just measuring a polyline, you can use the lengths method.

Is this really worth the effort?

To understand the discrepancies in measurements returned by the default ArcGIS Online Mercator and a more local coordinate system, take a look at this example application, which is zoomed into the town of McMinnville in northwestern Oregon. Draw a polygon somewhere within the initial map extent and notice the difference between the UTM, State Plane, and Mercator measurements.

Example measurement application

The UTM and State Plane measurements are both close to each other because these coordinate systems are designed for the same latitudes and longitudes that include northwestern Oregon. These results are closer to the true measurement.

The Mercator measurements are much larger because this area of Oregon is about 45 degrees latitude, halfway between the Equator and the North Pole. This is far enough away from the projection’s standard parallel (the Equator) to cause significant error in the measurement.

Contributed by Sterling Quinn of the ArcGIS Server development team. Example application by Kelly Hutchins.

This entry was posted in Services and tagged , , , . Bookmark the permalink.

Leave a Reply


  1. Sibbald says:

    Excellent article. Point to note in ArcGIS 10 that Web Mercator which was previously an ESRI WKID of 102100 (Google used a WKID of 900913 as it looked like “google”) will be an EPSG WKID of 3857 ( ). WKID of 102100 will still work if used in programming the dataframe but a WMS will report it correctly as EPSG:3857.

  2. sterlingdq says:

    @Ana – Hmm…that’s a challenging one unless you’re using a custom central meridian and standard parallels (support for this varies depending on the client). Have you tried the Asia South coordinate systems that are in the Continental folder? Maybe Asia South Equidistant Conic?

  3. digy79 says:

    Hi, How can I apply this method if I’m using the extension of ArcGIS Server API for Google Maps?

  4. sterlingdq says:

    @digy79 – You could use the esri.arcgis.gmaps.Geometry class which has methods for projecting and measuring. The code would be structured similar to the code in this post. See the API reference at

  5. digy79 says:

    Thank you a lot, this could be the right way to solve.
    It’s possible to have an example made with the Google Maps extensions API?
    I believe the solution to obtain correct distances and areas has to be included in the samples page of the api reference (measurement and buffers examples). Thx again!

  6. digy79 says:

    sorry for annoy you, but the esri user forum is closed at the moment and I need to solve this issue suddenly.
    I created this salmple [1]. It seems to “work”: it reprojects the input polyline before returning the measurement, but results are still wrong (and returns always 0 meters for small polylines…).
    3004 and 32633 are the best SRIDs I can use for my zone.
    Thx for your help


  7. digy79 says:

    var geometryService = new esri.arcgis.gmaps.Geometry(“”);
    function calculateLengths() {
    //Parametri per la riproiezione
    var params = new esri.arcgis.gmaps.ProjectParameters();
    params.geometries = [polyline];
    params.inSpatialReference = 4326;
    params.outSpatialReference = 3004; //Gauss-Boaga fuso Est
    //Riproiezione e funzione di callback
    geometryService.project(params, getLengths);
    function getLengths(projectResults){
    var url = “”;
    var parameters = {
    polylines: projectResults.geometries,
    sr: 3004
    esri.arcgis.gmaps.JSONRequest(url, test, parameters);
    function test(result) {
    alert(result.lengths[0]+” m”);

    Thanks to Domenico Ciavarella

  8. dmortenson says:

    Good article.

    However, I am still incredulous about using Web Mercator in the first place. In 30 years of creating maps and spatial analysis for a variety of agencies and projects, not once was this kind of projection ever considered. Why are we caving to whatever Microsoft decides? Shouldn’t it be a decision by the GISP’s?

  9. tystick says:

    I found this thread to be very helpfull when I was dealing with this same issue.

    It helped me fix this problem.
    I was using the following: (AGS 10.0 & JS API 3.4)

  10. hlzhang525 says:

    Nice review on Web Mercator projection and its problems. It will help clarify many confusions, in particular, among some GIS web developers and cartographers without solid geodesy and geomatics backgrounds.

    By the way, do you have any comments on the datum/projection transformation between WGS 84 Web Mercator / WGS84 Web Mercator (Auxiliary Sphere) and major local datum /projection like WKID 102204 (Ain_el_Abd_1970_Aramco_Lambert_2 in Saudi Arabia) ?

    With ArcGIS, the transformation between WGS 84 (saying, WKID: 32639) and Ain_el_Abd_1970_Aramco_Lambert_2 (WKID 102204) uses Ain_El_To_WGS_1984_2, which shows prefect conformal match…

    However, we couldn’t find any proper transformation between WKID: 3857 (Authority: EPSG WGS_1984_Web_Mercator_Auxiliary_Sphere) and Ain_el_Abd_1970_Aramco_Lambert_2 (WKID 102204) to help us perform data transformation.

    Any advice?