Field Calculator: Nonsense values for $area and $perimeter

[qgib]

Author Name: Bernd Vogelgesang (Bernd Vogelgesang)
Original Redmine Issue: 8592
Affected QGIS version: 2.0.1
Redmine category:vectors

---

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 (Bernd Vogelgesang)
• fc_tests.tar.gz (Giovanni Manghi)

---

Related issue(s): #17453 (relates)
Redmine related issue(s): 8738

---

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• status_id was changed from Open to Feedback
• category_id was configured as Vectors

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

• subject was 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

[qgib]

Author Name: Bernd Vogelgesang (Bernd Vogelgesang)

---

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.

---

• 6215 was configured as PolygonsAreaPeremiter.zip

---

• PolygonsAreaPeremiter.zip (Bernd Vogelgesang)

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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.

---

• 6216 was configured as fc_tests.tar.gz

---

• fc_tests.tar.gz (Giovanni Manghi)

[qgib]

Author Name: Bernd Vogelgesang (Bernd Vogelgesang)

---

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!

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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?

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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

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

---

• priority_id was changed from Normal to Severe/Regression
• fixed_version_id was configured as Future Release - High Priority
• status_id was changed from Feedback to Open

[qgib]

Author Name: Bernd Vogelgesang (Bernd Vogelgesang)

---

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.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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.

[qgib]

Author Name: Bernd Vogelgesang (Bernd Vogelgesang)

---

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.

[qgib]

Author Name: Jürgen Fischer (@jef-n)

---

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

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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?

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

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

---

• status_id was changed from Open to Closed

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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.