Add a global "padding" option

[lucaswoj]

We allow users to pass an around option to some camera methods.

This ticket proposes a around option be added to Map as a constructor option, getter, and setter.

This option would specify a default value for around on all camera mutations so that

• it becomes possible to specify around for implicit camera mutation, such as those triggered by use of the NavigationControl
• it becomes more ergonomic to use the same around value for all camera mutations

Open Questions

• Does around make sense semantically in this case? Many users will be using this feature because they have a translucent element over the map. In that use case, padding is a more intuitive option.
• Might users be confused about the difference between around and center? Can we find a naming convention that eliminates that confusion?
• Are there any other parameters that should have global defaults like this?

[1ec5]

A padding option would avoid the potential confusion between center and around. We do need to make sure padding accepts all four edges independently, both for consistency with related style specification properties and so that we address the use case that originally prompted this cluster of tickets.

Another important aspect is that it becomes all the more important to provide a method that returns the current CameraOptions, accepting a padding option. The developer should be able to call something like jumpTo(getCamera(padding), padding) and count on the viewport to stay constant.

[mourner]

I don't think it makes sense to have a global around option, because the value you need for it depends on context (e.g. the current map view). I have a hard imagining a use case where it would be static.

padding makes sense though because it's usually static. I would introduce independent padding for 4 sides because it's one of the most common use cases — e.g. having a semi-transparent sidebar on the map.

[musicformellons]

It's been a while since I brought up this issue referring then to it as 'shifted center'. I am now trying to establish what current status is. I note that in the meantime padding is added, but am I right that then you would have to set all flyTo etc kind of operation explicitly with offset to the 'shifted center', whereas this issue would have this setup instantly for all kinds of zoom operations? So maybe just wait a little till this is implemented?

[mourner]

@musicformellons yes, that's right. I still think a global map padding option makes more sense than individual offset options in various camera methods, but we don't have a timeline for implementing this at the moment.

[jaapster]

I would also prefer global map padding as this would also apply to box zooming.

[stevage]

Thanks @mourner for noticing this duplicate. Copying my text in from that issue since I think it covers another use case, with much the same proposed solution:

Currently a map's maxBounds specifies that the four corners of the map will never be outside the lat/long boundaries of the maxBounds. I am finding that sometimes this isn't ideal, when you have controls or overlays sitting inside the map area.

A concrete example:

• I have the western boundary of maxBounds set to 140, which is the western boundary of the state of Victoria. (This particular map is for a state-based agency). Minzoom is 6 (which shows the whole state).
• There is a legend sitting just inside the left margin of the map, 315px wide out of 890px. (It's not very tall, so doesn't obscure much space).
• Problem: when the user zooms out fully, part of the state is obscured by the legend.
• Solution 1: move the western boundary of maxBounds a lot further west, which isn't ideal, as it creates a huge amount of area where the user could get lost, at higher zooms.
• Solution 2: decrease minZoom, which creates more issues for data preparation and cartography, and also doesn't totally solve the problem of the user wanting to see lots of the state at a higher zoom level.

Proposed solution: allow some kind of maxBoundsBuffer setting which changes the definition of maxBounds. Instead of the four corners being constrained to the maxBounds, a rectangle inset by maxBoundsBuffer will be constrained. So in my case, the user could pan 315px further left than currently, so the legend doesn't obscure the map.

[59023g]

Hey, Updates on this?

[songololo]

Since you use the thumbs-up to track the priority of these items, and since the parent issue from which this item was split had 26 thumbs up plus the 9 above I hope that makes for a total of 35 thumbs-up! ;)