In ArcGIS 10.2 I created two buffers using the default settings one with a distance of 1 kilometer. When I calculated the area it has a square kilometer area of 3.14. All seems fine there to me. However, when I run the calculate area for the buffer that is 2 kilometers the area is 1.25581. Interestingly, as you go up in size to 3 kilometers, etc. the area calculations continue to be one decimal off, that is the area of a circle with a radius that is 2km should be 12.5581, 3km should be 28.27 rather than 1.256 and 2.287 respectively. The projections are the same-albers equal area. Any ideas what is happening??

  • What GIS software are you using? – PolyGeo Oct 28 '15 at 21:25
  • And how many digits in the display? And how many vertices are in the "circle"? Area closely approaches *pi*(r ^^2) as vertex count approaches 361. – Vince Oct 28 '15 at 21:34
  • GIS 10.2 The field is double with a precision and scale of 6. I'm not sure about how many vertices I have. I just used the default settings in the Buffer tool. – Kerry Oct 28 '15 at 21:36
  • Please edit your question in response to requests for clarification (If the product is ArcGIS 10.2.x, please specify the exact release -- "ArcGIS 10.2.whatever"). Take the Tour for a better idea of how things work here. – Vince Oct 28 '15 at 22:00
  • 2
    You say the projections are the same. What projection are you using? – Fezter Oct 28 '15 at 22:55

There may be many issues at play here, but one of them is the fact that a buffer around a point isn't a circle -- it's a circle-like polygon. The area of that polygon is calculated using Simpson's Rule (aka trapezoid rule), and will therefore under-approximate the curve between points -- As the number of vertices is increased (making the those points closer together), the area of the resultant polygon approaches ideal.

The following is a formatting hack of output calculated from the area of one kilometer radius circles in a projected coordinate system (with 1mm coordinate reference resolution), as the number of vertices increases from nine (an octagon) to 1441 (four vertices every degree)

ArcSDE 9.3 Dynamic ASCII Table Utility   Wed Oct 28 21:10:05 2015
             npoints: 9
               shape: Area shape (1 part, 9 vertices)
            polyArea: 2828440.0000000
          piRsquared: 3141592.6535898
          pctOfIdeal: 90.0320414
             npoints: 13
               shape: Area shape (1 part, 13 vertices)
            polyArea: 3000015.9218000
          piRsquared: 3141592.6535898
          pctOfIdeal: 95.4934727
             npoints: 19
               shape: Area shape (1 part, 19 vertices)
            polyArea: 3078184.2050000
          piRsquared: 3141592.6535898
          pctOfIdeal: 97.9816464
             npoints: 37
               shape: Area shape (1 part, 37 vertices)
            polyArea: 3125670.1582000
          piRsquared: 3141592.6535898
          pctOfIdeal: 99.4931712
             npoints: 73
               shape: Area shape (1 part, 73 vertices)
            polyArea: 3137611.9584000
          piRsquared: 3141592.6535898
          pctOfIdeal: 99.8732905
             npoints: 91
               shape: Area shape (1 part, 91 vertices)
            polyArea: 3139044.1576000
          piRsquared: 3141592.6535898
          pctOfIdeal: 99.9188789
             npoints: 121
               shape: Area shape (1 part, 121 vertices)
            polyArea: 3140169.7504000
          piRsquared: 3141592.6535898
          pctOfIdeal: 99.9547076
             npoints: 181
               shape: Area shape (1 part, 181 vertices)
            polyArea: 3140957.5440000
          piRsquared: 3141592.6535898
          pctOfIdeal: 99.9797838
             npoints: 361
               shape: Area shape (1 part, 361 vertices)
            polyArea: 3141437.8776000
          piRsquared: 3141592.6535898
          pctOfIdeal: 99.9950733
             npoints: 721
               shape: Area shape (1 part, 721 vertices)
            polyArea: 3141556.5788000
          piRsquared: 3141592.6535898
          pctOfIdeal: 99.9988517
             npoints: 1081
               shape: Area shape (1 part, 1081 vertices)
            polyArea: 3141575.4056000
          piRsquared: 3141592.6535898
          pctOfIdeal: 99.9994510
             npoints: 1441
               shape: Area shape (1 part, 1441 vertices)
            polyArea: 3141584.7376000
          piRsquared: 3141592.6535898
          pctOfIdeal: 99.9997480

From this we see that as few as 37 vertices (one every ten degrees) can approximate a true circle to 99.5% of area, and 361 vertices (one per degree of arc) achieves "four nines" (within 0.01% of true circle area).

You've also got an issue with the buffer distance increasing, since a fixed number of vertices would increase the gap between vertices (albeit in larger polygons):

ArcSDE 9.3 Dynamic ASCII Table Utility   Wed Oct 28 22:04:51 2015
             npoints: 101
               shape: Area shape (1 part, 101 vertices)
            polyArea: 3139533.0872000
          piRsquared: 3141592.6535898
          pctOfIdeal: 99.9344420
             npoints: 101
               shape: Area shape (1 part, 101 vertices)
            polyArea: 12558089.9062000
          piRsquared: 12566370.6143592
          pctOfIdeal: 99.9341042
             npoints: 101
               shape: Area shape (1 part, 101 vertices)
            polyArea: 28255721.3978000
          piRsquared: 28274333.8823081
          pctOfIdeal: 99.9341718

In addition to the raw number of points, the coordinate system in which the calculation is performed could also play a role -- If the data is in a geographic coordinate system, either the values will be completely wrong (not even a circle), or the geodetic area would need to be calculated on the fly, which could introduce a number of additional complications (spherical vs spheroidal calculation, or even whether the spheroid used was the same used to generate the polygon).

It doesn't impact your use case, but the coordinate reference XY resolution could impact very small (sub-meter) circles if the vertices shift location significantly due to the integer coordinate grid conversion (e.g. 361 vertices of a 1-meter circle with centimeter resolution):

ArcSDE 9.3 Dynamic ASCII Table Utility   Wed Oct 28 21:50:28 2015
             npoints: 361
               shape: Area shape (1 part, 361 vertices)
            polyArea: 3.1424000
          piRsquared: 3.1415927
          pctOfIdeal: 100.0256986  

In conclusion, it is unlikely that the calculated area is "incorrect" -- it's merely imprecise.

| improve this answer | |
  • Thank you for this thoughtful response. However, I am not sure it explains how the average area of the 5 kilometer buffers around my ~4,000 sites is smaller than the average area around these same sites with a buffer of 1 kilometer. – Kerry Oct 30 '15 at 2:42
  • Heh. If you have an order of magnitude issue, it helps to use "order of magnitude" in the problem description. Are the polygons smaller? If so, then how are they generated? If not, what exact procedure was used to calculate area in units different than the map units? This also makes the exact software release more significant. – Vince Oct 30 '15 at 11:36
  • The polygons are the buffers I create in ArcMap. I created several buffers of different sizes 1km,2km,3km,4km,5km the following size buffers around ~4,000 sites nation-wide. To check I am doing area calculations correctly for a later step I added a field in the attribute table (double 6 precision and 6 scale) and then calculated the area with field calculator. I have tested various sizes, only looked at one state, with a state system projection, tried various area calculations (e.g. square miles, meters, feet, kilometers, etc.) – Kerry Oct 31 '15 at 15:07
  • I have also done this in python and I still get weird area measurements-areas should increase incrementally as the buffer size increases and this is never the case. The area sizes go up and down. I'm so frustrated. Thanks for your help. – Kerry Oct 31 '15 at 15:12
  • 1
    Yet you're reporting in units of square kilometers which appear to have an order of magnitude issue. Please edit the question to document your exact procedure, and include the exact coordinate system – Vince Nov 2 '15 at 14:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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