Feature request #3296

Areas and length from field calculator are different to derived or measured results, when on the fly projection is on

Added by Gerhard Spieles almost 14 years ago. Updated over 9 years ago.

Status:Closed
Priority:High
Assignee:Magnus Homann
Category:Vectors
Pull Request or Patch supplied:No Resolution:fixed/implemented
Easy fix?:No Copied to github as #:13356

Description

Hi,

in a project with EPSG 31466 (Gauss Krüger Zone 2), i get different results of area and length from fieldcalculator and derived (or measured).
Project EPSG and shapefile EPSG are set to 31466.

When on the fly is off, the results are indentic.

A screenshot is attached

Do I soething wrong?

Gerhard

different-aerea-between-fieldcalulator-and-derived-when-on-the-fly-is-on.jpg (138 KB) Gerhard Spieles, 2010-12-06 02:12 PM

Latvia.7z - Shape file (compresed with 7z) (917 Bytes) zirneklitis -, 2012-02-06 11:56 PM

Related issues

Related to QGIS Application - Bug report #12057: Computed area is wrong when reprojection is active Closed 2015-01-26

History

#1 Updated by zicke - almost 14 years ago

This is also a bit a mystery to me but I guess with OTF enabled it regards the ellipsoid.

Stefan

#2 Updated by Marco Hugentobler almost 14 years ago

Hi all

The reason is that the field calculator does not take the target projection for measurement (and uses the default WGS84 ellipsoid), see qgssearchstring.cpp:145. It should probably read the ellipsoid from the options and set the target projection for measuring.

#3 Updated by zicke - almost 14 years ago

I still think it's a bit confusing that you get different results when OTF enabled or not. I have two coordinates: 600000/200000 and 600100/200000. When OTF is disabled I measure 100 meters, when OTF is enabled I get 100.1565 meters. I definitely prefer 100 meters :-) Is the OTF-enabled distance the distance on the ellipsoid?

At least you should have the possibility to choose what kind of result you want (even when OTF is enabled).

Stefan

#4 Updated by Marco Hugentobler almost 14 years ago

Hm, the field calculator distance measurement sets oft always to off for the calculations. Therefore, it should always return 100.

I tried it with your coordinates, and the field calculator always returned 100 for me, no matter if oft-projection is on or off. So I think your preferred behaviour is already there.

I agree that it would be good to have an option if otf and Ellipsoid should be considered or not.

#5 Updated by Giovanni Manghi almost 13 years ago

  • Target version changed from Version 1.7.0 to Version 1.7.4

#6 Updated by zirneklitis - almost 13 years ago

The difference between results is even more confusing when the same projection is used both for project as well as attached layer. (No actual reprojections should be done?) In the attahed example LKS92 / Latvia TM (EPSG:3059) is used. The calculated are ($area) gives the same result whether the 'on the fly' CRS transformation is enabled or not. Not the case with derived value inside 'Identify results' tool. The correct value is calculate when the 'on the fly' CRS transformation is disabled.

#7 Updated by Giovanni Manghi almost 13 years ago

  • Status info deleted (0)
  • Pull Request or Patch supplied set to No
  • OS version deleted (XP sp3)
  • Operating System deleted (Windows)
  • Assignee deleted (Jürgen Fischer)

I see this difference also with data in other projected CRSs.

#8 Updated by Giovanni Manghi over 12 years ago

  • Target version changed from Version 1.7.4 to Version 2.0.0

#9 Updated by Magnus Homann over 12 years ago

  • Assignee set to Magnus Homann

#10 Updated by Magnus Homann about 12 years ago

zicke - wrote:

I still think it's a bit confusing that you get different results when OTF enabled or not. I have two coordinates: 600000/200000 and 600100/200000. When OTF is disabled I measure 100 meters, when OTF is enabled I get 100.1565 meters. I definitely prefer 100 meters :-) Is the OTF-enabled distance the distance on the ellipsoid?

When OTF is enabled, the distance is probably on an ellipsoid, yes. I'm fixing this so that there will be a global selection off using ellipsoid or planimetric calculations, and this should then go into field calculation (and derived result). Stay tuned.

#11 Updated by Pirmin Kalberer about 12 years ago

  • Target version changed from Version 2.0.0 to Future Release - Nice to have

#12 Updated by Antonio Locandro over 10 years ago

This is still a problem and I disagree this should be tagged as Nice to have, there are lots of issues related to this behavior

#13 Updated by Giovanni Manghi over 10 years ago

  • Priority changed from Low to High
  • Target version changed from Future Release - Nice to have to Future Release - High Priority

#14 Updated by Giovanni Manghi over 9 years ago

  • Status changed from Open to Closed
  • Resolution set to fixed/implemented

this should be fixed in master, please reopen if necessary.

Also available in: Atom PDF