Bug report #8592

Field Calculator: Nonsense values for $area and $perimeter

Added by Bernd Vogelgesang over 10 years ago. Updated over 10 years ago.

Status:Closed
Priority:Severe/Regression
Assignee:-
Category:Vectors
Affected QGIS version:2.0.1 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:
Crashes QGIS or corrupts data:No Copied to github as #:17334

Description

Calculating an area field for a polygon layer in todays 2.1-dev from osegeo4w, the field is filled with strange 9-digit numbers, positive or negative ones, or zero.
Done this with a polygon layer in DHDN-Gauss-Grüger 4, 1.8 correctly calculates the value e.g 334325 while in 2.1, the preview of the calulator shows the same value, but fills in 0.
Other values:
187868 -> -139069743
92118 -> 109699764

Tried it both with integer and decimal fields.

Just tested also $peremiter: same strange numbers in comparison to 1.8

PolygonsAreaPeremiter.zip (10.8 KB) Bernd Vogelgesang, 2013-09-10 10:38 AM

fc_tests.tar.gz (10.9 KB) Giovanni Manghi, 2013-09-10 11:32 AM

Related issues

Related to QGIS Application - Bug report #8738: Field Calculator with problems Closed 2013-10-01

History

#1 Updated by Giovanni Manghi over 10 years ago

can you please attach sample data? This issue surfaced recently or it was already there in previous master/dev releases pre-2.0?

#2 Updated by Giovanni Manghi over 10 years ago

  • Status changed from Open to Feedback
  • Category set to Vectors

#3 Updated by Paolo Cavallini over 10 years ago

  • Subject changed from Field Calculator: Nonsense values for $area and $peremiter in 2.1-dev to Field Calculator: Nonsense values for $area and $perimeter in 2.1-dev

#4 Updated by Bernd Vogelgesang over 10 years ago

Here my simple layer:
2nd field is $area in 1.8
3rd field is $area in 2.1
4th field is $peremiter in 2.1
5th field is $peremiter in 1.8

Don't know which version i used last time to calcualte $area. Just realized then that it doesn't handle multi-part object correctly.

#5 Updated by Giovanni Manghi over 10 years ago

I tested your vector with qgis 1.9 on linux a few days old, and with qgis 2.1 on Windows: I cannot confirm this issue, in both cases the results are identical to the ones computed by qgis 1.8 by you. See attached file.

#6 Updated by Bernd Vogelgesang over 10 years ago

On my computer at home, this didn't happen as well. Today reinstalled QGIS from scratch, loaded the project and tried again. The same error occured.
When i open the file in a fresh project, it calculates correctly.
So i think there must have happend sth strange to the project file when getting converted from 1.9 to 2.1 ?
Anyway, have to redo the project then.

Update:
Now it didn't even work when loaded in a new project. Even deleted .prj and .qgj-files before loading and assigned GK4 for the file and the project. Still the same outcome.
Then deactivated on-the-fly transformation for the project: TADA! correct values.

So, it definately doesn't work with on-the-fly transformation for this shape!

#7 Updated by Giovanni Manghi over 10 years ago

So, it definately doesn't work with on-the-fly transformation for this shape!

ok confirmed.

So... in QGIS 1.8 works as expected even when reprojecting?

#8 Updated by Giovanni Manghi over 10 years ago

  • Priority changed from Normal to Severe/Regression
  • Target version set to Future Release - High Priority
  • Status changed from Feedback to Open

So... in QGIS 1.8 works as expected even when reprojecting?

oh yes... so this is a BAD BAD regression...

#9 Updated by Bernd Vogelgesang over 10 years ago

just to clarify: there was nothing to reproject. The layer and the project was in the same CRS. The difference was made activating or deactivating on-the-fly transformation for the project.
btw: same issue under Linux Mint with debian-nightly.

Update:
I just copied my features to a fresh shape file layer with EPSG 31468. Now the calculation go right, no matter if transformation was on or off!

I have no idea what can go wrong with a shape file. This one was created in an environment (presumingly under 1.8 or 1.9, I often switch) with layers in EPSG 4326, 31468 and 3857.

But sth must have changed in QGIS behavior as well: When i load the layer in 1.8 in a fresh project, the project crs switches to 31468, while in 2.1 it stays in 4326.

Hope s.o. will figure it out.

#10 Updated by Giovanni Manghi over 10 years ago

Bernd Vogelgesang wrote:

just to clarify: there was nothing to reproject. The layer and the project was in the same CRS. The difference was made activating or deactivating on-the-fly transformation for the project.
btw: same issue under Linux Mint with debian-nightly.

Update:
I just copied my features to a fresh shape file layer with EPSG 31468. Now the calculation go right, no matter if transformation was on or off!

I have no idea what can go wrong with a shape file. This one was created in an environment (presumingly under 1.8 or 1.9, I often switch) with layers in EPSG 4326, 31468 and 3857.

But sth must have changed in QGIS behavior as well: When i load the layer in 1.8 in a fresh project, the project crs switches to 31468, while in 2.1 it stays in 4326.

Hope s.o. will figure it out.

I confirm the issue also with other projections that I'm more familiar with, like 3763.

#11 Updated by Bernd Vogelgesang over 10 years ago

I have to report that this issue also occurs with 2.01 stable, so not only master is affected.
Today within a course, this happend on my Win7 machine with osgeo4w-setup and also on another Win7 with a standalone install, while the same fresh standalone install on a XP-Notebook didn't show this behaviour.
This time we processed OSM-Data, projected from WGS84 to DHDN Gauss-Krueger zone 4.

#12 Updated by Jürgen Fischer over 10 years ago

  • Subject changed from Field Calculator: Nonsense values for $area and $perimeter in 2.1-dev to Field Calculator: Nonsense values for $area and $perimeter
  • Affected QGIS version changed from master to 2.0.1

#13 Updated by Giovanni Manghi over 10 years ago

Bernd Vogelgesang wrote:

I have to report that this issue also occurs with 2.01 stable, so not only master is affected.
Today within a course, this happend on my Win7 machine with osgeo4w-setup and also on another Win7 with a standalone install, while the same fresh standalone install on a XP-Notebook didn't show this behaviour.
This time we processed OSM-Data, projected from WGS84 to DHDN Gauss-Krueger zone 4.

I confirm it seems fixed in qgis master. If no backports are expected then should not this be closed?

#14 Updated by Paolo Cavallini over 10 years ago

  • Status changed from Open to Closed

If this works in master, it can indeed be closed. Reopen if necessary.

#15 Updated by Giovanni Manghi over 10 years ago

Paolo Cavallini wrote:

If this works in master, it can indeed be closed. Reopen if necessary.

it is not fixed, but anyway there is another ticket about it.

Also available in: Atom PDF