Bug report #10966
with OTFR on $area is always computed in square meters even if the CRS is in feet (and QGIS project/general configs too)
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Severe/Regression | ||
| Assignee: | - | ||
| Category: | Vectors | ||
| Affected QGIS version: | master | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | duplicate |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 19314 |
Description
This is the only way I know how to explain it. If you have a shapefile/Spatialite layer and you turn on "enable on the fly CRS transformation" you do not get a correct area calculation. Typically it is off by a factor of 10 but in this example it's off a bit more. Example: I have a spatialite layer of polygons. If I calculate acreage of a polygon in it's native CRS I get an acreage calculation of 208.72. If I turn on "Project on the fly" the acreage calculation is then 19.47. It's still wrong if I make sure the Map Canvas is in the native projection of the data layer and Project on the fly is enabled. It's wrong if I move the CRS to match a different data layer (CRS of the imagery). It's right if I turn off Project on the fly and change my map canvas to match the CRS of the data layer.
I am calculating acres by opening the field calculator and executing $area / 43560 (area in is square feet)
All the vector layers are in EPSG:2274
The image layer is in EPSG:26916
I had set in this project the Map Canvas to be EPSG:2274 and Turned on Project on the fly to bring my image layer under my data layers.
I've loaded the files in Google Drive: https://drive.google.com/file/d/0B8WLtz606XDdU1FwOTR1eENKQjA/edit?usp=sharing
Related issues
History
#1
Updated by Giovanni Manghi over 10 years ago
- Subject changed from Area Calculations in QGIS with Project on the fly enabled. to with OTFR on $area is always computed in square meters even if the CRS is in feet (and QGIS project/general configs too)
- Category changed from Attribute table to Vectors
- Status changed from Open to Feedback
- Operating System deleted (
Ubuntu 14.04 UbuntuGIS repo) - OS version deleted (
2.4)
The edited title says it all. Computations with OTFR on are right... but in meters when feet would be expected (even when the proper configurations are in feet in general options/project properties). I have no idea if this is a regression since a previous QGIS version. If yes this should be tagged as blocker.
It should be checked also if the same happens for lengths, perimeters and x/y values.
#2
Updated by Antonio Locandro over 10 years ago
This is a very good example for a test case for future versions, if test fails needs to be dealt before release
#3
Updated by Giovanni Manghi almost 10 years ago
- Priority changed from Normal to Severe/Regression
- Affected QGIS version changed from 2.4.0 to master
- Status changed from Feedback to Open
it turns to be a regression as it worked as expected at least until 2.0.1
#4
Updated by Randal Hale over 9 years ago
Checked in 2.8.1 and it's still providing incorrect area back when OTF Projecting
#5
Updated by Andre Joost over 9 years ago
Just another test case:
It looks to me that OTF produces wrong results (even with the same CRS).
#6
Updated by Giovanni Manghi over 9 years ago
Andre Joost wrote:
Just another test case:
It looks to me that OTF produces wrong results (even with the same CRS).
see #12057
#7
Updated by Randal Hale over 9 years ago
I worked with a client the other day and we were calculating area in EPSG:26916 and it produced the correct area with OTF enabled. I haven't had a chance to go back and check against another dataset. Of course if it is defaulting to square meters that makes since since 26916 is UTM Zone 16.
#8
Updated by Giovanni Manghi over 9 years ago
- Resolution set to duplicate
- Status changed from Open to Closed
merged with #12057