Bug report #9951
Perimeter is completely wrong when OTFR is on
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: | |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 18452 |
Description
When OTFR is ON, both in the field calculator and in the identify->derived dialog, the perimeter of polygons gives completely bogus values.
Tested on master.
Associated revisions
Fix #9951 (perimeter completely wrong with OTF on)
With OTF on and computation on an ellipsoid, the coordinates
were transformed twice(!) when measuring perimeter.
History
#1 Updated by Martin Dobias over 10 years ago
- Status changed from Open to Feedback
I cannot replicate - perimeter seems to return reasonable values for me. Please add more details
#2 Updated by Giovanni Manghi over 10 years ago
Martin Dobias wrote:
I cannot replicate - perimeter seems to return reasonable values for me. Please add more details
take the attached grid (epsg 3763, projected), each side is 1km.
1) with OTFR OFF the field calculator result is OK, the identify (in "derived") returns 4000KM
2) with OTFR ON, project in EPSG 3763, the ellipsoid changes to GRS80 (right), now the identify returns 4147CM as perimeter and the field calculator returns 0.0414716552751224
3) with OTFR ON, project in EPSG 3763 and the ellipsoid manually changed to "planimetric/none" the identify returns 4000KM and the field calculator returns right values
*) similar (wrong) results as 2) if you reproject in UTM (ex: 29n) and leave QGIS choose the proper ellipsoid (WGS84). Right values seems to be computed only if the ellispoid is "planimetric/none" and the identify returns always the wrong unit.
#3 Updated by Giovanni Manghi over 10 years ago
- Status changed from Feedback to Open
- File grid.zip added
#4 Updated by Giovanni Manghi over 10 years ago
same data/cases as above, but with the area:
1) identify returns 100ha, fc returns 1000000, so is ok
2) identify returns 1.002km2, it is not clear if in identify the "." is used as decimal separator, if yes the result make sense. If it is used to separate the thousands then is not ok. The field calculator returns values between 1002211.86361505 and 1002255.37670402 that make sense.
3) identify returns 1.000km2, see 2) for considerations about the interpretation. Field calculator returns 1000000 so is ok.
#5 Updated by Martin Dobias over 10 years ago
- Status changed from Open to Closed
Fixed in changeset a19886d2f5d8b4acc3c4aac3cd887619cd81bf9f.
#6 Updated by Martin Dobias over 10 years ago
The separator is indeed decimal separator. We should try to find out how to display the values so that they are not so confusing. The problems I see:
- it uses 3 decimal digits, making it look like the value is in thousands
- it uses locale-aware decimal separator, making it look different than other values (for me, the area and perimeter use comma as a decimal separator, the rest of values use dot)