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:

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.

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.*