Bug report #1993
North arrow changes direction (with OTFR disabled and projected CRS) at very high/low zoom levels
|Affected QGIS version:||master||Regression?:||No|
|Operating System:||All||Easy fix?:||No|
|Pull Request or Patch supplied:||Yes||Resolution:|
|Crashes QGIS or corrupts data:||No||Copied to github as #:||12053|
Depending on the zoom level, the north arrow points sometimes north, sometimes south...
[spatialite] Fix pk-less queries cannot be retrieved by id
Fixes #1993 - Zoom to feature" does not work
This actually fixes many more bugs related with the
QGIS generated feature id (incremental) when using
queries that was not consistent when using
QgsFeature request with ids or bbox.
This is not a regression: the same error is in 2.18
#3 Updated by Giovanni Manghi almost 12 years ago
I'm not really very deep into projections matters, so I may not be able to explain this correctly, and if I'm saying something wrong please correct me.
Try add a layer defined in wgs84, for example a shape of the world borders: to let your France shape overlap the world borders you will need to enable OTFR. If you define wgs84 as project CRS, then you'll see obviously all aligned and the north points upwards, regardless the zoom level.
Now change the project CRS to a projected system and zoom to your France layer, you'll obviously still see the north upwards, but then when you zoom out the north arrow will start change the direction because the world border layer "wraps". It seems to me that the direction changes depending on what you have in the centre of the canvas. ***
I'm not sure why this also happens when you zoom in a lot, but I see that it happens when the scale reads "4 cm", so I guess that is not really important.
I'm also not really sure why this happens with OTFR not enabled and the project defined with a projected CRS. Interestingly it seems to happen always when zooming in (a lot) regardless the projected crs, but I found that when zooming out with certain projected crs, the north arrow does not change direction. As I said I'm very scarce about this matters, so maybe there is a reason that makes perfect sense for this behaviour.
Doing such test I found a bug that crashes qgis under ubuntu, but I will open a separate ticket.
#5 Updated by Giovanni Manghi almost 12 years ago
Replying to [comment:5 vince]:
To me, it is wrong at large and small scales. Look at the screenshots I made, always in Lambert 93 system.
yes (if you are using otfr disabled), it is what I wrote in my last sentence. But again, it doesn't happens with all the projected crs, so maybe there is an explanation, maybe is a just a bug.
#9 Updated by Magnus Homann about 9 years ago
- Pull Request or Patch supplied set to No
There were two things
1) Zoomed in: A tolerance for very small delta-x and delta-y prevented proper calculation of rotation.
2) Zoomed out: The center of the canvas was used for grabbing delta-x and delta-y. When zoomed out, the center of the camvas could possibly be "on the other side of the globe" compared to the layers in question.
A fix is in https://github.com/qgis/Quantum-GIS/pull/205