Bug report #8592

Field Calculator: Nonsense values for $area and $perimeter

Added by Bernd Vogelgesang about 6 years ago. Updated almost 6 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 about 6 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 about 6 years ago

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

#3 Updated by Paolo Cavallini about 6 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 about 6 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 about 6 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 about 6 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 about 6 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 about 6 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 about 6 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 about 6 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 about 6 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 about 6 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 about 6 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 almost 6 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 almost 6 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