brouter-web
brouter-web copied to clipboard
Feature-Request: magnifying by "holding zoom"
Frequent issue when working with maps: labels too small to read. So you zoom in, and if you are lucky, you can read the label before the tiles are replaced by the higher zoom level and labels get small again.
For a mobile app that I developed I addressed that problem with a simple hack: while multi-touch-zooming, the target-tile-zoom-level is not changed until you release the multi-touch. Very simple, feels very natural and you have the magnifier-feature almost for free. And it saves tile-requests.
Could BRouter-Web (or Leaflet?) implement the same behaviuor for mobile/multi-touch-zoom?
And something similar for desktop/mousewheel-zoom: mybe holding zoom while holding "shift". Or something based on the mouse-wheel button? Or just some fixed seconds wait-time after the last mouse-wheel event before changing the target-tile-zoom-level. Would be great.
regards, Arndt
Frequent issue labels too small to read
IMO it should not be the user's job to constantly work around deficiencies in the app by zooming in and out. Labels should be readable by default, i.e. their size should observe any DPI scaling settings (assuming default label sizes are already correctly chosen wrt. a standard font size, talk to your map vendor otherwise).
As far as I can tell, at least scaling the map according to DPI settings is already support. So instead of increasing the font size in every app's settings (which only scales fonts, but not UI elements), you might try resetting font size to defaults and changing DPI settings instead (see "Screen zoom" in Android settings; desktop browsers sometimes need to be configured separately). I just tested this:
- Android: Very large difference in label sizes between smallest and largest "screen zoom" setting in Android settings.
- Chromium: Map does not react to DPR settings in dev tools (is this equivalent to setting
Window.devicePixelRatio?), butchromium --force-device-scale-factor=2.5works. - Firefox:
layout.css.devPixelsPerPx = 2.5inabout:configworks.
What might be worth looking into though is checking, supporting and/or enabling @2x tiles served by some providers, since simply scaling up low-res images does not always increase readability. (Vector tiles would enable more fine-grained tuning, of course, but we are not there yet.)
target-tile-zoom-level is not changed until you release the multi-touch fixed seconds wait-time after the last mouse-wheel event before changing the target-tile-zoom-level
I would not welcome any change adding latency for regular zoom usage. Loading tiles while zooming is a feature, not a bug, it will present the correct tile faster and enhance image quality and detail during the zoom operation already, not only after it is done.
for desktop/mousewheel-zoom: mybe holding zoom while holding "shift"
When zooming any UI part (e.g. Ctrl+Scroll over navbar, status bar, sidebar), the map is scaled up already, along with fonts. Would that be enough?
I fear that adding another dynamic (i.e. not statically set in settings) zoom mode only for labels on top of the regular map zoom (which should normally be used when you want to see geographic features "bigger" / with more detail) might make the UX too complex and confusing. In particular with Shift-Click for beelines and Shift-Drag for box-zoom it might get triggered by accident, and users will wonder why their map suddenly looks fuzzy due to non-integer scaling.
Is there any other map which provides such a behavior? If not, chances are their UX teams decided not to implement it for good reasons.
TL;DR: Label size should be okay with correct DPI settings already, in the future vector tiles should provide more opportunities with less disadvantages.
When zooming any UI part (e.g. Ctrl+Scroll over navbar, status bar, sidebar), the map is scaled up already, along with fonts. Would that be enough?
hey, really, that is a possibility for reading small text on the map (other then using a physical magnifier) - thank you.
But no, not enough, that's zooming the map with map center as center point, it interferes with the responsive design, and it changes a persistant setting.
Is there any other map which provides such a behavior? If not, chances are their UX teams decided not to implement it for good reasons.
openstreetmap.de/karte.html comes close
For mobile/multi-touch, it's exactly what I propose.
For desktop/mousewheel it's close to BRouter-Web, but does the UI-zoom+mapscaling for any pointer-position, and uses the pointer-position as the center-point for the zoom. Better, but not good as well.
So if ctrl+mousewheel is semi-established, I refine my desktop proposal:
While holding "ctrl", behave exactly like openstreetmap.de/karte.html while holding the muti-touch (for mousewheel- and buttom-zoom)
For desktop/mousewheel it's close to BRouter-Web, but does the UI-zoom+mapscaling for any pointer-position, and uses the pointer-position as the center-point for the zoom. Better, but not good as well.
I don't think that's an explicit feature of https://openstreetmap.de/karte.html. It's just the scrollwheel zooming the map, and the browser doing text zoom in parallel since it is not inhibited. Thus I would not classify it as "semi-established". That map still has pan buttons even, as if it was stuck in the last decade. Good for them, but not something I would look at as a innovative example to get inspired by.
For mobile/multi-touch, it's exactly what I propose.
This too seems more like loading tiles while zooming simply has not been implemented. Such behavior was common in old maps designed for low-bandwidth connections. Modern maps add continuous loading of tiles while zooming, along with intelligent cross fading (the linked map just fades to a white background every time, leading to flashes of brightness and a subpar overall experience). Panning while pinch-zooming is also not supported. It just introduces too much UI latency for me, sorry.
While holding "ctrl", behave exactly like openstreetmap.de/karte.html
It's seems unlikely Leaflet is going to accept an extra option to disable their intentional modifier inhibition. We would have to either fork Leaflet, or try to circumvent it client-side. Again, I don't think this is something we should be doing, because pretty much everyone is in fact inhibiting this behavior in order to not break browsers everywhere when Ctrl-zooming by accident.
Besides, since it is the browser doing the zoom at this point, the rest of the UI would get zoomed too, which is a no-go for me as well.
If your really must have this feature, I would propose something like this:
- Ctrl+Shift+Scroll and Ctrl+Shift+Plus/Minus to override the map's automatically applied devicePixelRatio. (Note: I did not verify if this is actually possible for individual DOM elements.)
- It would be more of a setting (like adapting a zoom factor of a text-heavy website with Ctrl+Scroll and Ctrl+Plus/Minus) rather than a navigational feature (like zooming/panning a map or scrolling through text on a website).
- If the implementation happens to also keep the map location under the mouse pointer invariant when changing DPR, this would be pretty much what you want.
- This probably needs attaching a handler to intercept keyboard modifiers and mouse wheel events, and pass those to something hooked to the map's DPR config (and forward the remaining events).
- On mobile, this could be activated by holding down two extra fingers (one extra finger alone would likely trigger too often accidentally) to mean "Ctrl+Shift" while pinch-zooming.
Still, this will only look good (i.e. non-blurry) on low-resolution desktop monitors once we get vector maps, on mobile @2x tiles could be an interim solution.
One more thing: Adapting the size of labels on the map is also important for accessibility. As in that case everything should be bigger and not only maps, this is typically done at the OS and/or browser level. See above for how to change DPI globally.
What is requested here however is increasing the size of labels independently, while keeping everything else small, i.e. by not changing global DPI settings. This goes more into hyper-configurability rather than accessibility.
Regarding implementation of the DPR idea, maybe it could be done as a Leaflet plugin similar to https://github.com/elmarquis/Leaflet.GestureHandling or https://github.com/CliffCloud/Leaflet.Sleep.
Loading tiles while zooming is a feature, not a bug,
I agree, seamless transitioning of tiles with zoom animation in Leaflet is a nice feature that we wouldn't want to disable in general.
Some further rough ideas to explore (no specific order):
- turn off fadeAnimation/zoomAnimation dynamically
- set maxNativeZoom to current zoom dynamically, overzooms by scaling tiles
- increase tileSize
- increase
scaleCSS (and adapt translate3d) ofleaflet-tile-containerdirectly<div class="leaflet-tile-container leaflet-zoom-animated" style="z-index: 19;transform: translate3d(0px, 0px, 0px) scale(1);"></div> - Leaflet.MagnifyingGlass plugin
- does not enlarge tiles (?), just displays another zoom level
- OpenLayers Magnify example
- would do what we want, but not applicable to Leaflet as tiles are not displayed with canvas like in OL