13

Trying to get a handle on how length and area are calculated in different scenarios in ArcGIS. I don't know why I can't find a answer on the feature class fields, but I can't find a precise answer, unless I'm not understanding something and I know there is some history. Can you help me fill in the question marks? Or tell me why I'm going about this all wrong ; )

GCS = Geographic coordinate system PCS = Projected coordinate system
All links are to 10.1 help docs --

  1. Feature Class shape_length and shape_area fields
    a. GCS - ?
    b. PCS - Using simple planar
    c. Is it always auto-updated, except for shapefiles? yes

  2. ArcMap Measurment Tool
    a. GCS - default geodesic, alternatives are Loxodrome and Great Elliptic, but not planar. Area calculation not available!
    b. PCS - default planar, alternatives Geodesic, Loxodrome, and Great Elliptic
    http://resources.arcgis.com/en/help/main/10.1/index.html#//00s500000022000000

  3. Attribute Table Calculator
    a. GCS - not available
    b. PCS - planar
    http://resources.arcgis.com/en/help/main/10.1/index.html#//005s00000027000000

  4. Calculate Field Tool (Data Management toolbox)
    a. GCS - geodesic linear, area available but questionable
    b. PCS - planar
    http://resources.arcgis.com/en/help/main/10.1/index.html#//00170000004m000000

  5. Buffering Tool (and other tools coming)
    a. GCS - geodesic
    b. PCS - planar or specify GCS output http://resources.arcgis.com/en/help/main/10.1/index.html#//000800000019000000

  6. Javascript API Clientside
    a. GCS - geodesic area and length functions
    b. PCS - can convert from web mercator to geographic (or use geometry service) http://help.arcgis.com/en/webapi/javascript/arcgis/help/jsapi/namespace_geometry.htm

  7. Flex API Clientside
    a. GCS - geodesic area and length functions, "The length [or area] will be calculated using a custom cylindrical equal-area projection". This is not mentioned in the javascript api!!
    b. PCS - can convert from web mercator to geographic http://resources.arcgis.com/en/help/flex-api/apiref/com/esri/ags/utils/GeometryUtil.html

  8. ArcGIS Server REST API - Geometry Service
    a. GCS - geodesic
    b. PCS - planar
    http://help.arcgis.com/en/webapi/javascript/arcgis/help/jsapi/geometryservice.htm

Another question, what exactly is a geodesic measurement? I thought it meant a 3D trig formula on a spheroid (haversine?). And is it too slow to use in calculating an area and that is why equal area projections are used?

Another question, when determining length and area -- is an equal area projection more accurate than a geodesic calculation using the same datum, spheroid? And briefly why?

Improve this question
9
  • 2
    Concerning the last question, please see What is the most accurate coordinate system for calculating areas of polygons?. For the penultimate, because there exist equal area projections for ellipsoids, it is much easier to compute areas with such projections than to write ellipsoid-specific code. The situation is not as nice for computing distances, because no projection faithfully reproduces all distances: thus, direct spherical and ellipsoidal distance formulas are often implemented in good GISes.
    – whuber
    Nov 15, 2012 at 3:02
  • 1
    1.b, 3.b and 4.b use the projected coordinate system, so therefore planar. 1.c is always auto-updated when you use a geodatabase (personal/file/SDE).
    – Jens
    Nov 15, 2012 at 15:52
  • 2
    I think it might be best to split your questions. That way you will get the best answers for each one. It would be easier to vote on the answers that way, too.
    – R.K.
    Nov 30, 2012 at 12:36
  • 1
    I think there are around 10 questions here, each of which would most likely have been quickly answered if they had been presented one at a time (as separate Questions). Lumping lots of questions in one makes it hard for our Q&A style of responding.
    – PolyGeo ♦
    May 31, 2013 at 23:22
  • 2
    This is not a good candidate for CW. Moreover, it arguably is not too broad: it only seems so due to its careful enumeration of the many different ways ArcGIS offers to perform area and length calculations. It is still one single question that has been very clearly focused.
    – whuber
    Jul 5, 2013 at 13:12

2 Answers 2

Reset to default
5

Your question is essentially one on the accurate (and efficient) calculation of length and area over a large region. The practical details (in this case, concerning ArcGIS) are already being filled in by you and others. They also seem to point to these general conclusions:

  • length is best calculated via geodetic (geographic) coordinates
  • area is best calculated via equal-area-projection planar coordinates [Edit: But the complexity of the boundary, or the number of vertices needed to describe it, is a factor too -- see @cffk's answer]

Here is some explanation:

A geodesic is

the shortest line between two points on a mathematically defined surface (as a straight line on a plane or an arc of a great circle on a sphere)

http://wordnetweb.princeton.edu/perl/webwn?s=geodesic%20line (FYI, on an ellipsoid, a geodesic is generally slightly S-shaped.)

While calculations of geodesics (lengths on an ellipsoid) are relatively difficult, as compared to using the well-known Pythagoras equation, they are possible and accurate. They are relatively easy, however, compared to calculations of areas on an ellipsoid.

Map projections don't generally preserve linear scales, so projection coordinates aren't generally good for length calculations. (There are exceptions but those depend on where you are on the projection or in what direction you are going.) As for area, there is a class of projections which does preserve areal scale exactly: equal-area projections. Calculating areas on a plane is fairly simple to do, and, if an equal-area projection is used, it is accurate.

There are many good sources on geodesy or map projections that may help. For example, Geometrical Geodesy: Using Information and Computer Technology by Maarten Hooijberg.

Improve this answer
2
  • Characterizing a geodesic as being S-shaped is probably misleading because it implies that it isn't a shortest path. I'm aware of various figures that depict the geodesic as an S-shaped curve sandwiched between two normal sections. But I suspect that these are not accurate.
    – cffk
    Oct 24, 2013 at 23:42
  • If neither of the two normal sections is the geodesic, shouldn't the geodesic be sandwiched between the them and coincide appropriately with each at the ends?
    – Martin F
    Nov 3, 2014 at 7:51
4

To answer the question about measuring areas. If you want to measure the area of a polygon whose edges are geodesics you have two choices:

  1. project the polygon to an equal area projection, inserting sufficient additional vertices on each edge to ensure that the projected edges faithfully follow the geodesic, and measure the area in the projected space;
  2. use the formulas for the area of a geodesic polygon.

The second method is generally faster and more accurate unless the polygon edges are very short. Unfortunately arcgis doesn't implement this method (but it should!). However GeographicLib and proj (version 4.9.0 and later) do. See the Wikipedia article on the area of a geodesic polygon for more information.

Improve this answer
6
  • +1 I worry, however, about the accuracy in the geodesic calculations when applied to small polygons (such as areas of residential parcels): because it is adding and subtracting huge areas to arrive at the final area, there is tremendous cancellation and loss of precision. When coordinates were truly double precision this probably wasn't an issue, but with GISes that discretize their coordinates to an integral grid for their calculations (which includes ArcGIS), this would plausibly wipe out almost all the inherent precision and produce garbage results.
    – whuber
    Oct 22, 2013 at 14:18
  • There's nothing much that can be done if the starting coordinates have errors. However the overall accuracy of the geodesic area formulas using double precision is at worst 0.1 m^2 per vertex. Typical errors are much less. I did a careful check for the boundaries of various provinces in Poland. E.g., the polygon for Krakow has 8416 vertices (longest edge = 405 m, shortest edge = 0.02 m). True area (WGS84) = 326798565.428446 m^2, computed area (GeographicLib's Planimeter utility) = 326798565.4285 m^2.
    – cffk
    Oct 22, 2013 at 17:43
  • Right: double precision is fine, because it has about 52 bits of precision and you lose no more than 20 with the Gauss-Bonnet (angular excess) calculations. But signed integers have at most 32 bits of precision (and often quite a bit less, depending on how the analysis area is initialized), so losing 20 of them might become noticeable. I'm talking about loss of precision in the calculations, not the effects of errors in the coordinates themselves.
    – whuber
    Oct 22, 2013 at 18:40
  • I'm not sure why I would want to represent any real quantities as signed integers in the middle of a calculation like this. (Also where does your estimate of 20 digits for the loss of precision come from?) I do agree that estimating the error for realistic polygons is difficult. So in the case of Krakow quoted above, I computed the true area by brute force (evaluating the area formulas retaining 20 terms in the series and using 75-digit arithmetic). I also have similar data for other provinces of Poland and for the whole country (68000 vertices), area = 312e9 m^2, error = 0.001 m^2.
    – cffk
    Oct 22, 2013 at 21:03
  • 1
    OK. However, I still don't see why representing coordinates on an integer grid necessitates doing computations on those coordinates using integers instead of double precision. So it seems to me that you take a hit on accuracy up front quantizing the coordinates to a grid. However the additional error due to series truncation and round off during the area calculation can be made quite small (see the examples above).
    – cffk
    Oct 23, 2013 at 12:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.