Is your feature request related to a problem? Please describe.
setOuterBounds() reimplements pixel geometry in latitude and longitude:
n_outer = marker.startcoord.lat() + .5 * ((marker.n_outer - marker.s_outer + .00075)
/ Math.pow(2, -(17 - this.map.getZoom()))),Three problems in one expression. The constants .00075 and .00025 are unexplained. 17 is a zoom baseline with no stated origin. And the whole calculation belongs in pixel space, where the map library already provides the conversion.
resize() has the same character, with a hardcoded - 105 that should be CSS.
Describe the solution you'd like
Do the maths where it belongs. Both providers expose projection helpers (fromLatLngToPoint in Google, latLngToLayerPoint in Leaflet) that convert correctly at any zoom and latitude. Overlap and shifting should be computed in pixels and converted back once.
Describe alternatives you've considered
Leaving it and documenting the constants. Tempting, because it works today, but it makes the same mistake as Tab Radius: a ground-distance behaviour that changes with latitude and zoom for reasons nothing in the code explains.
Additional context
This has no test coverage at all, and it cannot get any without a browser harness, since it depends on a live map instance and its zoom. Of all the JavaScript, this is the piece I would least want to change without one.
Best done as part of the provider work in #8: a provider abstraction has to define marker positioning anyway, and doing this twice would be waste.
Is your feature request related to a problem? Please describe.
setOuterBounds()reimplements pixel geometry in latitude and longitude:Three problems in one expression. The constants
.00075and.00025are unexplained.17is a zoom baseline with no stated origin. And the whole calculation belongs in pixel space, where the map library already provides the conversion.resize()has the same character, with a hardcoded- 105that should be CSS.Describe the solution you'd like
Do the maths where it belongs. Both providers expose projection helpers (
fromLatLngToPointin Google,latLngToLayerPointin Leaflet) that convert correctly at any zoom and latitude. Overlap and shifting should be computed in pixels and converted back once.Describe alternatives you've considered
Leaving it and documenting the constants. Tempting, because it works today, but it makes the same mistake as Tab Radius: a ground-distance behaviour that changes with latitude and zoom for reasons nothing in the code explains.
Additional context
This has no test coverage at all, and it cannot get any without a browser harness, since it depends on a live map instance and its zoom. Of all the JavaScript, this is the piece I would least want to change without one.
Best done as part of the provider work in #8: a provider abstraction has to define marker positioning anyway, and doing this twice would be waste.