Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Markers Disappear #512

Closed
avipersin opened this issue Jun 15, 2015 · 3 comments
Closed

Markers Disappear #512

avipersin opened this issue Jun 15, 2015 · 3 comments

Comments

@avipersin
Copy link

Using Chrome and Windows 7.

Seems to be an issue with cluster groups at the south pole that are close to the prime meridian. I can place single markers at [-89.00, 0], [-89.00, 1] but if I place other markers in that area and they cluster it messes up.

For example it will show a group of 3, but when you click the group nothing is there-- the markers disappear. If I move the markers to [-81.00, 0] then they display properly. Clustering shouldn't add a limitation that isn't there when placing single markers. Clearly those coordinates are in scope, as you can place single markers there AND even marker cluster acknowledges they are there. It's just when you click the cluster everything disappears.

@ghybs
Copy link
Contributor

ghybs commented Oct 9, 2015

Hi,

Well, it turns out that if you keep the default CRS (Web/Spherical Mercator), there is a maximum latitude: MAX_LATITUDE: 85.0511287798 (also used for South limit of course)

What happens is that all markers beyond this limit are ceiled/floored to the limit when projected onto the map.
Demo: http://jsfiddle.net/zn7q7or6/1/

By the way, this behaviour happens at all longitudes, not only at the prime meridian.
It is also symmetrical: same problem at Northern limit (as shown in the demo).

MCG hides markers which it thinks are outside the visible bounds (plus an extra margin).
So when you are looking at the map lower limit, you are actually looking at the ~ -85° latitude, which is far away from the marker's latitude (-89° in your case), so MCG does not show it.
We are misled by the fact that other markers (not within a MCG) are displayed at this limit, even though their latitude was specified farther!

But if you go far away from the map limit, the view bounds eventually reach the marker actual position. Then MCG adds it to the map, which shows it only at its border, and not on the edge of the view…
Demo: http://jsfiddle.net/zn7q7or6/2/ (Try panning up a little bit to reveal the hidden markers)

Obviously this use case is quite limited: the majority of applications would be placed at lower latitudes, where the Web/Spherical Mercator error (as compared to Elliptical Mercator for example) is negligible.

Still, is this fixable?
Well, we could force the markers latitude to the limit if markers original position are outside, but then it interferes with their data, which the application may not expect.
We could also fiddle with the _getExpandedVisibleBounds() method, that could be easier: http://jsfiddle.net/zn7q7or6/4/ (there is still a bug at map init, move or zoom to make all markers appear)

But this issue seems to highlight a more fundamental issue in Leaflet itself: bounds padding can give latitude outside [-90; +90]°. Worse, the padded latitude decreases when we go further up from the North limit, maybe because we are on the other side of the arctan function. But I have not seen where the unproject is called when padding bounds, or just modifying them manually as is done in MCG?

ghybs added a commit to ghybs/Leaflet.markercluster that referenced this issue Oct 14, 2015
Following issue Leaflet#512, if CRS Projection defines a `MAX_LATITUDE`,
expand the bounds to Infinity if the padded visible bounds exceeds
that limit.
@ghybs
Copy link
Contributor

ghybs commented Oct 24, 2015

Regarding my last comment, it is actually very simply explained, but very counter-intuitive: at very high latitudes (North or South), the view spans across less degrees. The view upper and lower edges represent closer latitudes, so the difference is less, and the expanding (bounds padding) hence results in a shorter range.

@danzel
Copy link
Member

danzel commented Dec 21, 2015

Should be fixed by #587

@danzel danzel closed this as completed Dec 21, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants