#17591 closed defect (fixed)
Zoom to download doesn't work as expected
Reported by: | GerdP | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | 19.04 |
Component: | Core | Version: | |
Keywords: | regression | Cc: | Don-vip, wiktorn |
Description
From https://forum.openstreetmap.org/viewtopic.php?pid=745086#p745086:
Every time I download new data in JOSM, (File > Download data, or Ctrl+Shift+Down, and accepting the >default selecting which is the current viewport), then the maps zooms out, with the downloaded data only >covering the inner 50% of the new viewport. I have to zoom in once to go back to the previous view and >the actual extends of the downloaded data.
Also using 5 (Zoom to Download) zooms out too much making the actual download only cover 50%.>
Is this due to a combination of wrong settings?
I initially though this was some faulty HiDPI processing, but my screen is only 1920x1080 and set to 100% >scaling in Windows.
Using JOSM 14945, jPortable 1.8.0_201, Windows 10.
Attachments (2)
Change History (8)
by , 6 years ago
Attachment: | 17591.patch added |
---|
comment:1 by , 6 years ago
comment:4 by , 6 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
There is still an issue when a e.g. a Bing layer is already open and "Scale follows native resolution of this layer" is enabled in the layer list (which is it by default).
by , 6 years ago
Attachment: | 17591-scale-follow.patch added |
---|
comment:5 by , 6 years ago
Cc: | added |
---|
This 2nd patch implements a new preference zoom.scale-follow-native-resolution-at-load
. The default is true which is the current behaviour: A new layer that implements NativeScaleLayer gets the flag "scale follows native resolution of this layer".
If set to false this doesn't happen, the user can still enable one layer of his choice.
If I hear no complains I'll commit this patch next monday.
I think there are two problems:
1) The checkbox "Zoom to downloaded data" looks like "Zoom to download" but the current implementation doesn't try to do the same.
I don't know if this is intended, it is at least confusing.
2) The implementation for 5 (Zoom to download) calls
BoundingXYVisitor.enlargeBoundingBoxLogarithmically()
. I think this should not happen. The attached patch addresses this problem.