11

When I open QGIS, add the layer, and calculate the areas of the shapefile via field calculator I get a different area than when I open QGIS and check "Enable on the fly CRS transformation" and calculate the area. This is despite making sure that the project and the layer have the same Coordinate system (same EPSG number). What am I doing wrong?

I have a shapefile with area calculations made with ArcGIS (not be me, the data was handed to me and I have no clue for which CRS the area was calculated with ArcGIS). The shapefile layer CRS is EPSG: 21781 (Switzerland). In QGIS, if I do not change the OTF settings and leave the project CRS as EPSG:4326 (WGS84) I get the same value as the ArcGIS area value. However, if I change the OTF before adding the layer to EPSG: 21781 I get different area values. As I understand this suggests that ArcGIS Area was calculated with the CRS EPSG: 4326.

First workflow:

  1. open QGIS
  2. project CRS: EPSG 4326
  3. add layer
  4. project CRS adapts automatically and is EPSG 21781 now
  5. calculate $area with field calculator

Second workflow:

  1. open QGIS
  2. project CRS: EPSG 4326
  3. Turn on OTF, set project CRS to EPSG 21781
  4. add layer
  5. calculate $area with field calculator

Step 5 of the first and second workflow DO NOT produce the same area.

Improve this question
8
  • can you give an example of the workflow and tools you used; I've tried it with on-the-fly enabled and disabled in the WGS84 and it gave the same area. That is using $area in the filed calculator. In short, on-the-fly affects how geometry is being displayed without altering the data de-facto. Thus it ismore likely that the error is due to the workflow.
    – dof1985
    Commented Apr 18, 2015 at 11:14
  • does $area calculate the area based on the layers or the projects coordinate system?
    – kalakaru
    Commented Apr 18, 2015 at 11:24
  • I've checked and it seems to give the area in the OTF units; yet I am quite sure it uses the geometry of the layer itself
    – dof1985
    Commented Apr 18, 2015 at 11:29
  • That might be the root of my problem. I have a shapefile with Area Calculations made with ArcGis (not be me, the data was handed to me and I have no clue for which CRS the area was calculated with ArcGIS). The shapefiley layer CRS is EPSG: 21781 (Switzerland). If I do not change the on the OTF settings and leave the project CRS as EPSG:4326 (WGS84) I get the same value as the ArcGis Area value. However, if I change the OTF before adding the layer to EPSG: 21781 I get different area values. As I understand this suggests that ArcGIS Area was calculated with the CRS EPSG: 4326.
    – kalakaru
    Commented Apr 18, 2015 at 11:43
  • as far as I'm aware Arcgis can calculate geometry in many ways. Using field calculator's python expression !shape.area! should give the area according to the layer crs; than calculate geometry might work different. So it is hard to tell, exactly what was been done in arcgis, yet if you get the same result, e.g. degrees and not meters, it meens that the area calculation was indeed based upon the ESPG: 4326.
    – dof1985
    Commented Apr 18, 2015 at 11:47

2 Answers 2

Reset to default
7

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.

Improve this answer
4
  • I'm not sure about QGIS, but in some contrast to what you mention here ArcGIS can actually do its Calculate Geometry using OTF projection or a completely different projection altogether depending on method (ie right-click attribute column and choose Calculate Geometry vs an in-code/field calculator call of shape.area). There are sometimes choices given to use the CRS of 1) data/layer, 2) current dataframe, 3) a specified CRS unrelated to 1 or 2. Typically (again, ArcGIS) if the choice isn't presented it will be done in the current dataframe's CRS, regardless of what the data's is (hence OTF).
    – Chris W
    Commented Apr 21, 2015 at 21:32
  • I should also mention OTF isn't just for display purposes - one doesn't have to reproject a dataset to run a geoprocessing tool that also uses a dataset with a different CRS; OTF handles that. There are some exceptions to this, when both datasets do have to be in the same CRS.
    – Chris W
    Commented Apr 21, 2015 at 21:36
  • @ChrisW, if I understand correctly; some geoprocessing tools accept OTF CRS as it was the layer's CRS. Thus getting area based upon OTF CRS is not necessarily a bug. Is that correct? Regarding Arcgis, let us assume WGS84 as OTF; what about a call like: !shape.area@meters!
    – dof1985
    Commented Apr 22, 2015 at 6:44
  • That's correct. Your dataframe and first layer could be WGS84, and you could add a second layer that is NAD83. The second layer is OTF projected, and you can run any normal tool like Intersect or Union on it and the operation takes place in WGS84. Getting area definitely is not a bug. I have a client that wants data in NAD83, but the info requires units in acres and that I work in a projected CRS to enter info. I usually just change the dataframe projection, calc area, and then switch it back. Not sure how that call would be handled since I think unit conversion is separate from calculation.
    – Chris W
    Commented Apr 22, 2015 at 18:32
6

I can confirm that it seems to be a bug.

Create a csv file with the following content:

E N
600000 200000
700000 200000
700000 300000
600000 300000

Import it as delimited text with EPSG:21781, enable snapping and draw a polygon shapefile on the four points.

Without OTF, the result of $area/1000000.0 is 10000 m² (which is obviously correct).

Turning OTF on, and selecting the same EPSG:21781, you get 9988.2338 m².

Choosing a different CRS, like EPSG:4326, delivers 9990.5339 m², because the calculation is done on a different ellipsoid (WGS84 instead of bessel).

Vector --> Geometry Tools --> Export/Add Geometry Columns seems to deliver correct values.

The bug already has some tickets: https://issues.qgis.org/issues/10966 and https://issues.qgis.org/issues/12473

Improve this answer
0

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.