There is a similar question posted, but the solution to it seems to be that polygons were multipart: Wrong $area from field calculator (QGIS)

In my case, all polygons are singlepart. I have several polygons and want to calculate area in acres. I tried doing so using the field calculator [ $area / 4046.9548 ]. However, the calculation resulted in most polygons being extremely high (for some reason, there was 1 polygon that was right - id 2; 19.8 acres). The proportion of error seems to be inconsistent as well (i.e., area is being overestimated by as much as 7000x and as little as 19x, and there is no clear relationship with polygon size and the amount area is being overestimated).

area in QGIS

I have tried 2 different projections: WGS 84 / UTM zone 15N (EPSG: 32615); NAD83 / UTM zone 15N (EPSG: 26915). Both are giving me similar area results. I have changed the project CRS as well as the layer CRS, and I am always getting the same result.

I was able to bring the .shp into ArcGIS, and the area calculated correctly there (column 3 of the table shown). However, I do not have direct access to ArcGIS and would like to use QGIS for this project anyways.

Why is the area calculating wrong and what should I do to fix it? It seems to me this is a bug of QGIS 2.8.1 - any thoughts?

wkt_geom    id  Acres   Acres2
POLYGON((413021.65088476904202253 4902835.35903273895382881,413019.9315825883531943 4902864.74276821129024029,413020.16550777421798557 4902882.35620316863059998,413026.60994472057791427 4902891.07888804655522108,413040.35845059278653935 4902893.83241057209670544,413058.28628579177893698 4902893.59438843559473753,413083.63513001694809645 4902896.19401332177221775,413127.90793888038024306 4902894.13855400308966637,413181.71088945050723851 4902894.89314012043178082,413252.46482790348818526 4902901.2957936767488718,413293.72935398085974157 4902911.02565119322389364,413327.6311613493016921 4902922.32124511897563934,413362.68450617993948981 4902940.94199378602206707,413407.36460598744452 4902969.71193141676485538,413417.01093905157176778 4902981.32873533200472593,413434.17498251388315111 4903003.12247731350362301,413450.43954338179901242 4903036.67249271180480719,413468.71606994007015601 4903062.85574622172862291,413483.6930770076578483 4903078.80633773282170296,413507.02882917522219941 4903088.77438649814575911,413550.26521912473253906 4903088.20347991678863764,413602.97315922257257625 4903086.03985215444117785,413697.92101420927792788 4903087.72398152016103268,413754.90515020152088255 4903089.90934882126748562,413797.08696452697040513 4903089.35396001953631639,413809.74150878586806357 4903089.18739637453109026,413814.95628477755235508 4903084.71464222017675638,413817.04606045957189053 4903083.21909907832741737,413819.97791090072132647 4903065.56402648147195578,413818.76103240338852629 4902973.09347910806536674,413815.55090785957872868 4902889.45741724409162998,413816.36595994769595563 4902791.08799542300403118,413815.12982126727001742 4902697.14970104768872261,413816.04157619818579406 4902606.11923649720847607,413814.94069934217259288 4902522.45546605158597231,413813.55013947084080428 4902416.77492918446660042,413812.31410632590996101 4902322.83668850176036358,413812.06303940195357427 4902303.75548500940203667,413810.96974148997105658 4902300.83379253000020981,413748.80205652303993702 4902306.05620487872511148,413420.72158131503965706 4902304.5122439693659544,413392.2648284116294235 4902306.35647539328783751,413377.46059512521605939 4902303.61614877637475729,413336.32835487823467702 4902304.16021616943180561,413239.29845405393280089 4902305.44468074943870306,413143.30376236519077793 4902305.24881310202181339,413067.32834032038226724 4902303.32059202902019024,413017.77817315247375518 4902305.4464269345626235,413013.57897152286022902 4902306.97023348603397608,413012.62175831967033446 4902314.32316423580050468,413011.87896264484152198 4902337.82173055876046419,413013.4404260833398439 4902375.97013689763844013,413011.91588399559259415 4902420.03170452453196049,413013.37988375558052212 4902450.84118893276900053,413013.82821619434980676 4902484.60025170724838972,413014.99981597042642534 4902493.3929580096155405,413018.4652555855573155 4902515.67651823163032532,413020.69696994166588411 4902522.31802542041987181,413028.88479899178491905 4902525.8483043760061264,413040.53031151450704783 4902526.42682134918868542,413068.13132632256019861 4902522.78247515670955181,413087.34590595948975533 4902523.98119094967842102,413111.37147112272214144 4902522.20874827541410923,413127.8231866043061018 4902522.23303250782191753,413175.10716451448388398 4902522.36775166448205709,413226.98541615298017859 4902524.4464023457840085,413231.27382519887760282 4902543.97303796652704477,413234.09454947075573727 4902566.9557322058826685,413237.21136964973993599 4902585.86850575264543295,413230.90055104432394728 4902615.69136238191276789,413229.5281678574392572 4902658.53254770860075951,413229.30461286893114448 4902681.82638497371226549,413223.41665920958621427 4902699.09058632329106331,413223.41665920859668404 4902699.09058632235974073,413207.57806618750328198 4902697.83241203054785728,413195.97735917463432997 4902697.98615144472569227,413162.26876944815739989 4902701.36908191628754139,413120.06492864451138303 4902700.46073917020112276,413087.37203403416788206 4902700.89449449349194765,413055.71426410338608548 4902699.84662727545946836,413036.7117997023742646 4902698.63086597807705402,413031.43874977907398716 4902698.70088256429880857,413025.16956455889157951 4902703.18826565146446228,413021.04859009064966813 4902710.58321542106568813,413019.09531814896035939 4902722.35351380426436663,413020.0309898930718191 4902792.80724116694182158,413020.0309898930718191 4902792.80724116694182158,413021.65088476904202253 4902835.35903273895382881))   8   21607.59    126.72
  • Considering you're trying multiple projections--indicating uncertainty toward the data's coordinate system--I'm going to have to step out on a limb and reject the bug-in-QGIS hypothesis. :)
    – elrobis
    May 13, 2015 at 17:34
  • Here's a more constructive suggestion.. try selecting one of your features using the Select Single Features tool in the QGIS interface, then with any feature selected, hit CTRL+C on the keyboard. This will copy the entire feature record to your clipboard, which includes the feature's geometry as a Well Known Text (WKT) expression. Since this captures the geometry in its native coordinate system, it could be helpful if you paste the WKT geometry into your post as an edit so we can see what the actual coordinates look like.
    – elrobis
    May 13, 2015 at 17:42
  • Also, while this is potentially a different issue, are you intending to convert square meters to acres? Should that not be $area / 4046.86?
    – elrobis
    May 13, 2015 at 17:50
  • 1
    To be clear, I digitized the polygons of this layer while the project CRS was in WGS 84 / UTM zone 15N (EPSG: 32615). I reprojected the layer to see if that may have given a different result. I will add the WKT data as an edit. Also, the square meter to acres is a rounding error. I derived that number from sq. ft. to acres. Thanks for the suggestions.
    – Tyler N
    May 13, 2015 at 19:25

5 Answers 5


Use area($geometry) instead of $area

According to the QGIS documentation, area($geometry) returns the area of a geometry polygon object. Calculations are always planimetric in the Spatial Reference System (SRS) of this geometry, and the units of the returned area will match the units for the SRS. This differs from the calculations performed by the $area function, which will perform ellipsoidal calculations based on the project's ellipsoid and area unit settings.

  • There is something confusing. We can expect some differences in the use of the $area and the are functions since the former uses ellipsoidal calculations while the last uses planimetric cartesian maths. Aug 4, 2021 at 19:05
  • This helped me as the computed area using $area in Field Calculator was overestimated by about seven hectares compared to GroupStats result. Jun 20, 2023 at 10:12

Without precisely knowing the projection of your data, it's difficult to be sure what went wrong with your calculation. That said, it's always risky methodology to allow any kind of reprojection on the fly in your GIS when you're additionally performing geometry calculations. The same is true if you have several layers in a mixture of projections, in which case you're almost guaranteed to be reprojecting on the fly..

If I were you, I would start a fresh map in QGIS, load the layer you want to perform calculations on, then process your Field Calculator expressions while both the layer and the map are in the same projection--that of your native data.

It would be wise to double check that the QGIS map takes the projection of your data before you run the numbers. At least this way, you know QGIS's layer calculator is respecting the intended projection.

If you still get an unexpected result, my guess is your data may not be in the datum/coordinate system you actually think it's in.

  • 2
    It's confusing, because I checked to be sure the project and layer CRS were the same before I digitized the polygons. Then I reprojectod the layer only when I saw that the areas weren't calculating correctly. The problem for me was that I had "Render" checked on and was reprojecting on the fly. Thanks for your help!
    – Tyler N
    May 13, 2015 at 19:46
  • @TylerN No problem--your observation about having "Render" checked may prove useful for someone else. I'm glad you resolved the matter.
    – elrobis
    May 13, 2015 at 19:58
  • An added complexity can be the Project's Properties. See this for a problem which I faced: gis.stackexchange.com/questions/236217/… Apr 9, 2017 at 4:59

Something is confusing. We can expect some differences in the use of the $area and the area functions since the former uses ellipsoidal calculations while the last use planimetric cartesian maths.

However, these differences will be large only if the polygons are large, like a county or one state. But, for parcels, like shown in the figure, I would not expect differences like 700x, this does not make sense. Doesn't matter if the parcels are in a little landscape or around the country, for small parcels, differences among planimetric and ellipsoidal approach will be small.

So, to my best knowledge, differences in the kind of calculations can not explain not only the overestimations of the area of small polygons like shown in the figure, nor that the overestimation varies without a regular pattern.


I had a similar problem. This post solved it for me. You can define your calculation parameters in the Project Properties/General



$area returns to ellipsoidal area whereas area($geometry) gives planar area (Cartesian area)

  • 1
    Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    Nov 10, 2023 at 10:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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