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 almost 11 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 almost 11 years ago
- Status changed from Open to Feedback
- Category set to Vectors
#3
Updated by Paolo Cavallini almost 11 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 almost 11 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 almost 11 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 almost 11 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 almost 11 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 almost 11 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 almost 11 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 almost 11 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 almost 11 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 almost 11 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 almost 11 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.