Leaflet: Different maxBoundsViscosity for x and y axes

[buschtoens]

Would a PR for two additional map options maxBoundsViscosityX and maxBoundsViscosityY that both default to maxBoundsViscosity, if not explicitly set, be accepted?

If x and y are frowned upon, we could also go with maxBoundsViscosityLng and maxBoundsViscosityLat.

In our case, we want to restrict panning to one axis only, but keep the bounciness when reaching the end. Currently this is not possible without also allowing a bit of viscous panning on the other axis.

[IvanSanchez]

I'm not convinced. If you need to restrict panning in one axis only, then set maxBounds to [[a, -Infinity], [b, Infinity]].

Is there a use case I'm missing?

[buschtoens]

I think I wasn't making myself clear enough. Sorry.
I'll try to explain it with this graphic.

The map element / viewport has the size of the fully opaque area. The map itself (or to be more precise, the maxBounds) has the size of the translucent area.

Assuming that the map has the minimal zoom and zooming is disabled, the user can pan on the green axis, but not on the red axis.

If we set maxBoundsViscosity to 1, the panning will abruptly stop, when the end of the map on the left or right side is reached. Panning along the red axis is impossible.

If we set it to 0.5 for instance, we would get that nice viscous bounds effect that we want. However, that would also mean that the user can pan the map on the red axis as well, at least a bit.

By allowing separate maxBoundsViscosity values for either axis, we could enable the viscous bounds for one axis, but completely restrict panning on the other axis.

[IvanSanchez]

Hhhhhhmmmmm. 🤔

In your use case, what would happen when the map is zoomed, and then the user pans to a corner? Solid bounds on top/bottom, but viscous on left/right?

[buschtoens]

That's a good question. I would expect the panning on the red axis to stop immediately, but the movement on the green axis to continue for a bit. As if the map was hitting a solid brick wall on the red axis, but was suspended on rubber bands on the green axis

At least that would be the desired behavior. Without digging into the code, I don't know if that's easily achievable. But I'd guess yes.

[perliedman]

As with most of these special cases, I'd say a plugin would be the preferred way to cater for special use cases like this. Having said that, I'm not familiar with the code in question, so I don't know if that's feasible.

If not possible to write as a plugin, perhaps we should look into if it would be possible to make the bounds bounce-code more extensible?

[buschtoens]

• https://github.com/Leaflet/Leaflet/blob/d3c7ed13ad7272f41ab1170501357a329a8d2bc9/src/map/handler/Map.Drag.js#L109
• https://github.com/Leaflet/Leaflet/blob/d3c7ed13ad7272f41ab1170501357a329a8d2bc9/src/map/handler/Map.Drag.js#L151-L153
• https://github.com/Leaflet/Leaflet/blob/d3c7ed13ad7272f41ab1170501357a329a8d2bc9/src/map/handler/Map.Drag.js#L161-L164

Should be quite easy to adapt. I'd be okay with using a plugin for this. But I'm not sure how I would specify a custom DragHandler. :thinking:

[buschtoens]

The default Map.Drag handler registers itself here:

• https://github.com/Leaflet/Leaflet/blob/d3c7ed13ad7272f41ab1170501357a329a8d2bc9/src/map/handler/Map.Drag.js#L231
• https://github.com/Leaflet/Leaflet/blob/c18ac11efb968613b11136a8c0fe4a0b9fb09233/src/core/Class.js#L102-L112
• https://github.com/Leaflet/Leaflet/blob/b997839fe73397330c292dcac1e5a65cb3ea8fdb/src/map/Map.js#L669-L681

I don't see a way to unregister and replace it.

[IvanSanchez]

Don't unregister it. Replace the behaviour of L.Map.Drag with L.Map.Drag.include({...});.

[buschtoens]

Ah I see, so Class.include can overwrite / monkey-patch the class? That's neat. Thanks. :smile:

[IvanSanchez]

Yeah, that's buried somewhere in the "extending Leaflet" tutorials 😄

I'll wait for your plugin then 😉