Bug report #9951
Perimeter is completely wrong when OTFR is on
|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|
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.
#2 Updated by Giovanni Manghi about 7 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.
#4 Updated by Giovanni Manghi about 7 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.
#6 Updated by Martin Dobias about 7 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)