Bug report #8592
Field Calculator: Nonsense values for $area and $perimeter
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
Related issues
History
#1
Updated by Giovanni Manghi over 9 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 9 years ago
- Status changed from Open to Feedback
- Category set to Vectors
#3
Updated by Paolo Cavallini over 9 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 9 years ago
- File PolygonsAreaPeremiter.zip added
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 9 years ago
- File fc_tests.tar.gz added
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 9 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 9 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 9 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 9 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 9 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 9 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 9 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 9 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 about 9 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 about 9 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.