Walking parameters #370
Walking parameters #370
Conversation
| /** | ||
| A bias which determines whether the route should prefer or avoid the use of alleys. The | ||
| allowed range of values is from -1.0 to 1.0, where -1 indicates preference to avoid | ||
| alleys, 1 indicates preference to favor alleys, and 0 indicates no preference. |
There was a problem hiding this comment.
🙏 thank you for grabbing the correct docs!
|
Initially in 68dfa3f, I started with a clear separation between route options and walking options by subclassing directions options because walking parameters and driving parameters are mutually exclusive but not yet enforced on the server-side. However, currently, as this PR stands, the walking parameters are folded into RouteOptions but the relevant query items are parsed for the corresponding profile identifier. |
| case .cycling: | ||
| break | ||
| default: | ||
| break | ||
| } | ||
|
|
||
| if !roadClassesToAvoid.isEmpty { |
There was a problem hiding this comment.
"exclude" (roadClassesToAvoid) should only be appended if profile identifier is any of [.automobile, .automobileAvoidingTraffic, .cycling] for now.
There was a problem hiding this comment.
We’re putting these properties in RouteOptions for now because they aren’t supported in the Map Matching API yet, but we’ll need to move them from RouteOptions to DirectionsOptions as soon as the Map Matching API adds support for them.
Remember to add a blurb to the changelog about the new options.
| queryItems.append(URLQueryItem(name: "roundabout_exits", value: String(includesExitRoundaboutManeuver))) | ||
|
|
||
| switch profileIdentifier { | ||
| case .automobile, .automobileAvoidingTraffic: |
There was a problem hiding this comment.
These switch statements might become more invasive over time. Maybe we can extend the MBDirectionsProfileIdentifier enumeration so that a given profile knows which parameters it supports?
| Defaults to 1.42 | ||
| This property has no effect unless profile identifier is set to `MBDirectionsProfileIdentifier.walking`. | ||
| */ | ||
| @objc open var walkingSpeed: CLLocationSpeed = 1.42 |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
| @objc open var walkwayBias: Double = 0 | ||
|
|
||
| /** | ||
| Walking speed in meters per second. Must be between 0.14 and 6.94 meters per second. |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
| switch profileIdentifier { | ||
| case .automobile, .automobileAvoidingTraffic: | ||
| if includesExitRoundaboutManeuver { | ||
| queryItems.append(URLQueryItem(name: "roundabout_exits", value: String(includesExitRoundaboutManeuver))) |
There was a problem hiding this comment.
All profiles support this parameter, and roundabouts do occasionally occur along bike/hike trails. Better that this library pass through the parameter so that the navigation SDK can assume its presence.
A more generic property name for speed allows the same property to be reused for cycling options in the future. “Priority” sounds more positive than “bias” and aligns with UILayoutPriority and similar types. An extensible enumeration gives us a way to symbolically refer to meaningful priorities.
|
d57c1e0 renamed |
This PR adds walking parameters (
alleyPriority,walkwayPriority, andspeed) toRouteOptions.Fixes #371.
cc @1ec5 @kevinkreiser 👀