# Area Calculation incorrect

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
Commented Oct 28, 2015 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. Commented Oct 28, 2015 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. Commented Oct 28, 2015 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. Commented Oct 28, 2015 at 22:00
• You say the projections are the same. What projection are you using? Commented Oct 28, 2015 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
------------------------------------------------------------------------
1
npoints: 9
shape: Area shape (1 part, 9 vertices)
polyArea: 2828440.0000000
piRsquared: 3141592.6535898
pctOfIdeal: 90.0320414
2
npoints: 13
shape: Area shape (1 part, 13 vertices)
polyArea: 3000015.9218000
piRsquared: 3141592.6535898
pctOfIdeal: 95.4934727
3
npoints: 19
shape: Area shape (1 part, 19 vertices)
polyArea: 3078184.2050000
piRsquared: 3141592.6535898
pctOfIdeal: 97.9816464
4
npoints: 37
shape: Area shape (1 part, 37 vertices)
polyArea: 3125670.1582000
piRsquared: 3141592.6535898
pctOfIdeal: 99.4931712
5
npoints: 73
shape: Area shape (1 part, 73 vertices)
polyArea: 3137611.9584000
piRsquared: 3141592.6535898
pctOfIdeal: 99.8732905
6
npoints: 91
shape: Area shape (1 part, 91 vertices)
polyArea: 3139044.1576000
piRsquared: 3141592.6535898
pctOfIdeal: 99.9188789
7
npoints: 121
shape: Area shape (1 part, 121 vertices)
polyArea: 3140169.7504000
piRsquared: 3141592.6535898
pctOfIdeal: 99.9547076
8
npoints: 181
shape: Area shape (1 part, 181 vertices)
polyArea: 3140957.5440000
piRsquared: 3141592.6535898
pctOfIdeal: 99.9797838
9
npoints: 361
shape: Area shape (1 part, 361 vertices)
polyArea: 3141437.8776000
piRsquared: 3141592.6535898
pctOfIdeal: 99.9950733
10
npoints: 721
shape: Area shape (1 part, 721 vertices)
polyArea: 3141556.5788000
piRsquared: 3141592.6535898
pctOfIdeal: 99.9988517
11
npoints: 1081
shape: Area shape (1 part, 1081 vertices)
polyArea: 3141575.4056000
piRsquared: 3141592.6535898
pctOfIdeal: 99.9994510
12
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
------------------------------------------------------------------------
1
npoints: 101
shape: Area shape (1 part, 101 vertices)
polyArea: 3139533.0872000
piRsquared: 3141592.6535898
pctOfIdeal: 99.9344420
2
npoints: 101
shape: Area shape (1 part, 101 vertices)
polyArea: 12558089.9062000
piRsquared: 12566370.6143592
pctOfIdeal: 99.9341042
3
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
------------------------------------------------------------------------
1
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.

• 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. Commented Oct 30, 2015 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. Commented Oct 30, 2015 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.) Commented Oct 31, 2015 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. Commented Oct 31, 2015 at 15:12
• 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 Commented Nov 2, 2015 at 14:47