When I use the field calculator it gives me a value above 100 % (Pic. 1, red mark).
As you see in the picture the result is at 100,05 %. At other calculations its even higher, sometimes up to 100,25 %. When I change the command from ($area / sum(area))*100 to (round("$area",5) / round("sum(area)",5))*100 it doesn't change anything.
QGIS – Solving Area Percentage Calculation Above 100% Issue
field-calculatorqgis
Related Solutions
Use the gdaldem tool http://www.gdal.org/gdaldem.html as
gdaldem slope input.dem output_in_percents.tif -p -of GTiff
From the manual page: "-p : if specified, the slope will be expressed as percent slope. Otherwise, it is expressed as degrees "
QGIS generates a similar gdaldem command and degrees/percents is selected here:
EDIT - Disclaimer: I would like to refer the readers to the discussion with ChrisW below. It might be that getting an area based upon an OTF CRS is not a bug after all; that is, at least, in arcgis it also being used to allow geoprocessing two layers from different CRS.
To elaborate on the issue above. As AndreJ as suggested and show - this is probably a bug in qgis's current version. Yet it should be noted that the problem isn't the wrong area, but that on-the-fly transformation affects in anyway on area calculations.
The purpose of on-the-fly transformation/projection is to align data from different sources and with different CRS. That is mainly for display purposes. E.G. arcmap automatically perform on-the-fly projection in any case a layer CRS does not match the data frame CRS.
Arcmap also provides a possibility to edit data while projected on-the-fly, but also notes that: (source)
However, it is important to note that certain editing operations may produce unexpected alignment or accuracy problems, depending on the coordinate systems being used.
Specific editing operations that may cause issues include changing the shapes of features, snapping to the edge or boundary of features, or extending and trimming features. These problems are more likely to occur when the features you are editing are close to the edge or beyond the area of use of the coordinate system
That is to say: on the fly transformation is less acurate than just project the data to a different CRS (which also introduces its own problems).
Having said that it is not surprising that based on a on-the-fly transformation a wrong area is being calculated, yet it is surprising that the fact that on-the-fly was enabled affects in any way the calculation of geometry, which should be based on the data. Thus, it doesn't matter if on-the-fly transformation is based upon the same or a different CRS, area calculation should be identical each time.
To be more practical, if your aim is to compute the area do not use on-the-fly. If you have the wrong CRS, project your data.
Best Answer
The issue you are encountering may be laying in the different calculation methods of
$areaandarea($geometry). We do not know how your field"area"was calculated, but to get your accurate percentage, I recommend to either recaluclate the fieldvalue of"area"by using$areaor use another method in your new calculation. (Like the one @Babel suggested:($area / sum($area))*100orarea($geometry) / sum(area($geometry)))*100)From the docs: