-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Offset map center #2600
Comments
+1 |
+1 Both Apple and Google uses this offset thing on their map apps. Would be very useful to have! |
/cc @1ec5 |
Just to clarify, this is in their own user-facing apps, not their developer-facing frameworks. But agree. |
This is in some ways blocked by #1041: currently “user tracking” consists of moving the user dot in response to user location changes, then synchronizing the map’s center point in response. A better approach would be to affix the user dot to a set location on-screen (usually the center point but in this case somewhere near the bottom) and pan the map directly in response to user location changes. The logic in |
Apple MapKit uses 2 APIs for this using insets:
and
|
We have One thing I’m stuck on is how best to present this option to developers: should it be a percentage or an absolute pixel? Should we measure from the view’s edge to the annotation view’s edge, or to its center? The thought crossed my mind of allowing the annotation view to be constrained using Auto Layout – the map view would effectively pin the map view to the annotation – but maybe that’d be too difficult to work with. |
Ok, it's something not available on Apple MapKit. We have this feature on our map at Mappy, we just expose a property to users in the framework: This inset is used when centering the map at coordinates or at the user position or when setting the region. |
So if you have course tracking on and want to push the puck down to the bottom, as depicted in #2600 (comment), you’d set a very large top inset, correct? That sounds reasonable. In fact, under the hood, we’ll want methods like |
Yes, it's working like that. |
Both the iOS and OS X versions of MGLMapView need this functionality regardless of the user tracking mode, because it’s common for there to be a translucent top bar overlay. On iOS, MGLMapView’s center should account for the top and bottom layout guides; on OS X, if the MGLMapView occupies the entire content view and the content view is full size, the center should account for the toolbar. |
Hi, I'm working at Mappy. |
From the Android side, this is something that should be tackled with #3276 |
To clarify above, I was looking at this from an Android View being overlaid on a Map, |
Moved EdgeInsets to geo.hpp so CameraOptions and Transform can refer to it. Added a padding option to CameraOptions that alters the frame of reference for the center option. Added optional padding parameters to LatLng getters and setters. Working towards #2600.
Moved EdgeInsets to geo.hpp so CameraOptions and Transform can refer to it. Added a padding option to CameraOptions that alters the frame of reference for the center option. Added optional padding parameters to LatLng getters and setters. Working towards #2600.
In user tracking mode, keep the user dot in a fixed location on screen, instead easing the map view so that the fixed location corresponds to the new user location. There is one exception: MGLMapView reacts to the first location update the same way as before, so that it appears to move to where the user dot has been all along. In course tracking mode, weight the user dot down towards the bottom of the view, since it’s more important to see the road ahead than the road behind. Fixes #2600, and #1041 to some extent.
#3583 adds content insets and shifts the map’s visual center point to account for any translucent top and bottom bars. #3589 pushes the visual center even further downward in course tracking mode. Note that in both Apple’s Maps application and Google Maps, the user puck is only offset in turn-by-turn mode, but not before you complete the first step (e.g., leaving the parking lot). So the puck’s position will be configurable. |
Moved EdgeInsets to geo.hpp so CameraOptions and Transform can refer to it. Added a padding option to CameraOptions that alters the frame of reference for the center option. Added optional padding parameters to LatLng getters and setters. Working towards #2600.
In user tracking mode, keep the user dot in a fixed location on screen, instead easing the map view so that the fixed location corresponds to the new user location. There is one exception: MGLMapView reacts to the first location update the same way as before, so that it appears to move to where the user dot has been all along. In course tracking mode, weight the user dot down towards the bottom of the view, since it’s more important to see the road ahead than the road behind. Fixes #2600, and #1041 to some extent.
In user tracking mode, keep the user dot in a fixed location on screen, instead easing the map view so that the fixed location corresponds to the new user location. There is one exception: MGLMapView reacts to the first location update the same way as before, so that it appears to move to where the user dot has been all along. In course tracking mode, weight the user dot down towards the bottom of the view, since it’s more important to see the road ahead than the road behind. Fixes #2600, and #1041 to some extent.
In user tracking mode, keep the user dot in a fixed location on screen, instead easing the map view so that the fixed location corresponds to the new user location. There is one exception: MGLMapView reacts to the first location update the same way as before, so that it appears to move to where the user dot has been all along. In course tracking mode, weight the user dot down towards the bottom of the view, since it’s more important to see the road ahead than the road behind. Fixes #2600, and #1041 to some extent.
In user tracking mode, keep the user dot in a fixed location on screen, instead easing the map view so that the fixed location corresponds to the new user location. There is one exception: MGLMapView reacts to the first location update the same way as before, so that it appears to move to where the user dot has been all along. In course tracking mode, weight the user dot down towards the bottom of the view, since it’s more important to see the road ahead than the road behind. Fixes #2600, and #1041 to some extent.
Implemented in #4790. |
where
|
@leonardodev, panning to fit a selected annotation is unrelated to this issue, but it would be great for the SDK to have that functionality built in: #3249. |
@leonardodev Great solution, but it doesn't take into account different zoom levels. If I'm on a different zoom level, the coordinate point messes up. Any suggestions to fix that? |
I'm confused about whether this was answered for Android. It seems that it was achieved as a feature for iOS. Any insights to Android, particularly Kotlin? Is this possible with Mapbox Maps SDK or is it necessary to switch to Navigation UI? |
Hi,
Is it possible to easily offset what the map treats as it centre? We want the map to follow the users position more like a navigation app where the "car" is much lower on the screen so that you can see further ahead.
I've looked for a value that defines the center but wasn't able to find anything. We have our own fork so it doesn't matter what the change is as long as it's possible.
Thanks
Maciej
The text was updated successfully, but these errors were encountered: