Common/suggested camera calculations (meta-issue)

[ianthetechie]

Every frontend will be in charge of camera handling, and in many cases, the user may be allowed to temporarily take over. However, for the case of the "default" camera following the user around during navigation, we want to outsource this logic in a fairly generic manner to the core, which returns the key bits to be translated into camera control of the renderer by the frontend.

This issue will track individual cases until we finish the next milestone.

• 39

• 40

[Archdoog]

Yep, this is a solid idea. A couple of notes either new or from previous discussions:

• [ ] I know we discussed adding the ability to pass a configuration into/or post processing this state generator (e.g. multipliers, centering). Beyond the basics like speed or speed limit based zoom/pitch, I can see needing different versions of the camera parameters for a mobile UI versus CarPlay/AndroidAuto within the same app.
• [ ] Considerations to enable future configurations (e.g. bbox for next maneuver). Lots of stuff that could enhance the camera feature here that we don't really need in the short term.

[ianthetechie]

Beyond the basics like speed or speed limit based zoom/pitch, I can see needing different versions of the camera parameters for a mobile UI versus CarPlay/AndroidAuto within the same app.

Yes, good call-out! I think there are a few things packed into this so let me try to get it all out in the open.

1. With no other configuration, we will compute other parameters like zoom and pitch assuming something sane like phone + automotive navigation.
2. We should probably also add profiles for in-dash use (or large screen? help welcome on deciding what kind of thing this is) with sensible defaults.
3. We should also allow the developer end-users of the framework to provide their own implementations. Of course users wanting to throw out the "batteries included" UI can always write their own logic, but we want to provide a way that plugs into the provided UI components as a matter of principle. Since we are trying to make the UI as composable as possible, most people should be able to override the logic for, say, zoom level and then not have to reimplement their own UI.

Anything I'm missing?

Considerations to enable future configurations (e.g. bbox for next maneuver)

Yeah, that's actually a really good call-out too. Many navigation experiences will want this to be able to quickly show a maneuver and highlight it in a route detail. I think this should actually be a property on RouteStep. Let me know if you agree and I'll capture that in an issue.

It should be extremely easy to extend either by adding either fields to the data structures (for stuff that is useful for a wide range of applications) or extension methods and the like (for those which are not used as often / make sense to compute lazily).

[ianthetechie]

@Archdoog to do a SwiftUI first pass at what the core state value looks like.

[ianthetechie]

Ok, so first thoughts on this now that I'm getting into it...

Desirable properties

• User "puck" is at the bottom center of the viewport
• Map view is at some angle (pitch), which may change based on various factors (ex: pedestrian apps tend to use top down; vehicle navigation tends to have a steeper angle)
• Camera tracks the user's course (not heading; the puck may track a smoothed heading though)
• Camera animates smoothly between location updates

Points of observation

• It looks like MapLibre/Mapbox Navigation achieve the intended effects using a camera constructed with cameraLookingAtCenterCoordinate:acrossDistance:pitch:heading: .
• Thus, the primary variables are
  • Pitch: seems to be 45 by default and 60 for CarPlay.
  • Distance or Altitude: MapLibre Navigation determines which altitude to use based primarily on three factors.
  • First, there is of course a default altitude. This appears to be 1000 by default, and 500 for CarPlay.
  • Second, there is a "zoomed out" level, which is used whenever the user is far enough from the next maneuver. This is only used on motorways.
  • If you're thinking "how are distance and altitude related," you're not wrong :P I'm not sure which they meant, but it's actually distance even though the code is wrong as far as I can tell...
    • Confusion arises from badly named variables and use of method in CarPlay that is CLEARLY wrong/confusing
    • It appears to get factored in here, but only when you pass an instruction point. It boils down to "if our current route step is on a motorway AND the next step is a motorway AND it's a 'long' maneuver (per the threshold), zoom out. Otherwise, use the default altitude."
  • Whether we should use the "zoomed in" or "zoomed out" camera "height".

Where we go from here

• For #39, we can get by with hard-coded values for the default profile and add more configurability later.
• It sounds like MapLibre actually does help us out quite a bit here (though the method names have me very, very confused given that I know the effect but it doesn't seem to match anything going on). To take advantage of this, we'll need to extend the MapLibe SwiftUI wrapper a bit with a new camera mode.
• I think that exposing pitch and "distance" (I still want to determine the best name for this parameter) are sufficient as far as the core is concerned if I've understood the above correctly.

[ianthetechie]

Some salient points from the discussion with @Archdoog today:

• Looks like the code I was linking was not very informative 😂 They actually did end up rolling with the user location tracking built into the (mobile guts of the) renderer. This now lives on as MLNLocationManager on iOS LocationEngine on Android.
• We can provide adapters bridging our LocationProvider interfaces into MapLibre so that we'll get things like simulation for free
• In addition to setting mode to .followWithCourse, you can push the user's position down to the bottom of the screen using contentInset