Bug report #9951

Perimeter is completely wrong when OTFR is on

Added by Giovanni Manghi over 10 years ago. Updated over 10 years ago.

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.

grid.zip (2.78 KB) Giovanni Manghi, 2014-06-09 04:44 AM

Associated revisions

Revision a19886d2
Added by Martin Dobias over 10 years ago

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

#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)

Also available in: Atom PDF