-
-
Notifications
You must be signed in to change notification settings - Fork 866
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
[BUG] Markers without symmetrical anchors disappear before they are out of bounds #918
Comments
@lpongetti sorry to bother you but do you think this might be a bug? Or am I doing something wrong? |
@aytunch can you provide a minimal code example? |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
This issue was closed because it has been stalled for 5 days with no activity. |
@JaffaKetchup @ibrierley Hi:) This calculation in
|
Out of interest, what are your marker and anchor details ? |
@ibrierley This is what I have. Nothing special. Just some arithmetic to calculate the |
@ibrierley You can see what double and triple icon markers look like and please see where the notch (anchor) is. It is unsymmetrical according to the width. I am positive that my markers fall in to this condition when they are half way off screen's left edge and they don't get displayed. The for loop continues from the next marker.
|
Hi there, This is quite interesting, as I've never come across this before - I've always had symmetrical markers. I would also agree that you are correct about the calculations wrongly assuming symmetry, although I'm struggling to understand the below code fully. bool _boundsContainsMarker(Marker marker) {
var pixelPoint = map.project(marker.point);
final width = marker.width - marker.anchor.left;
final height = marker.height - marker.anchor.top;
var sw = CustomPoint(pixelPoint.x + width, pixelPoint.y - height);
var ne = CustomPoint(pixelPoint.x - width, pixelPoint.y + height);
return map.pixelBounds.containsPartialBounds(Bounds(sw, ne));
} It seems like it places Happy to accept PRs on this, if you think you've found the answer! At the moment I've just come out of exams and my plugin needs some attention, so I'm relatively time limited for coding on this project. Once I'm done, I can take a deeper look if necessary. |
Could you create an anchor with fixed values as an example that exhibits the problem. I kinda get the problem, but a concrete example is always handy. |
@JaffaKetchup @ibrierley I did some debugging and printed some values to be sure. Here are the results for you to consider;
Whit these values what the current code does is, I think a solution along these lines can solve this problem plus it would help with performance. Because before we were giving twice the height for markers which had their anchor points on the bottom.
|
It's a funny bit of code the original, the labelling, the way round it is etc :D. I feel like I'm missing something with its intention, but it doesn't look right, so you may be correct (I haven't got time now to go through it properly). Am I being dumb, or are sw/ne the wrong way around as well (normally it doesn't really matter in bounds), sometimes my brain works in different coordinate systems. |
@ibrierley I thought the same way also. I think the coordinate space of a The (0, 0) is bottom right. I am amazed that not many people encountered this error. I guess everyone uses anchors in the middle bottom :) |
Ah yep doh, mixing coordinate systems, as if life isn't tricky enough already :D |
Actually now you made me question the proposed solution as well 😅. I am confused with sw and ne. |
If anyone is having this issue, you can temporarily use this dependency.
|
I believe the fix below handles the markers which have anchors in the center or edges.
#313
I have printed the marker width and height values and they are all as they are supposed to be.
If I increase the marker width artificially then the disappearing stops but the anchors are getting corrupted of course. So I think it might be a bug in the package. I might be wrong though.
RPReplay_Final1622477362.mov
The text was updated successfully, but these errors were encountered: