Is your feature request related to a problem? Please describe.
Tab Radius is documented as the distance within which nearby markers combine into one tabbed popup, with a default of 0.0003. That value is in degrees, and the code compares raw latitude and longitude deltas against it:
var shift = this.t_error + .0002,
n_coord = mapMarker.getPosition().lat() + this.t_error,
e_coord = mapMarker.getPosition().lng() + this.t_error,A degree of longitude is about 111 km at the equator and roughly 55 km at 60 degrees north. So the same setting combines markers across twice the ground distance in Singapore as it does in Oslo, and an operator who tunes it at one latitude and deploys at another gets different behaviour with no indication why.
Latitude is unaffected; longitude is where the error lives, and it grows with the cosine of the latitude.
Describe the solution you'd like
Express the setting in metres and convert through the map projection, so the same number means the same ground distance everywhere. Both Google and Leaflet expose the helpers for this.
The existing value would need migrating, or the setting renaming, so an upgrade does not silently change every install's marker grouping.
Describe alternatives you've considered
Scaling the longitude comparison by cos(latitude) in place. Cheaper, and it fixes the asymmetry without touching the settings UI, but it leaves the unit as degrees, which stays hard to reason about.
Additional context
Related to the marker overlap geometry, which has the same class of problem: pixel-space maths expressed in lat/long.
Is your feature request related to a problem? Please describe.
Tab Radius is documented as the distance within which nearby markers combine into one tabbed popup, with a default of
0.0003. That value is in degrees, and the code compares raw latitude and longitude deltas against it:A degree of longitude is about 111 km at the equator and roughly 55 km at 60 degrees north. So the same setting combines markers across twice the ground distance in Singapore as it does in Oslo, and an operator who tunes it at one latitude and deploys at another gets different behaviour with no indication why.
Latitude is unaffected; longitude is where the error lives, and it grows with the cosine of the latitude.
Describe the solution you'd like
Express the setting in metres and convert through the map projection, so the same number means the same ground distance everywhere. Both Google and Leaflet expose the helpers for this.
The existing value would need migrating, or the setting renaming, so an upgrade does not silently change every install's marker grouping.
Describe alternatives you've considered
Scaling the longitude comparison by
cos(latitude)in place. Cheaper, and it fixes the asymmetry without touching the settings UI, but it leaves the unit as degrees, which stays hard to reason about.Additional context
Related to the marker overlap geometry, which has the same class of problem: pixel-space maths expressed in lat/long.