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

Update v5 API #40

Merged
merged 4 commits into from
Apr 29, 2016
Merged

Update v5 API #40

merged 4 commits into from
Apr 29, 2016

Conversation

1ec5
Copy link
Contributor

@1ec5 1ec5 commented Apr 29, 2016

This PR reacts to various changes to the v5 API made over the past few weeks:

  • Updated ManeuverType values.
  • A request has only one transport type, corresponding to the profile, but for every request, each step may have a different, more granular transport type. So now an MBRouteStep’s transportType has a distinct datatype. The transportType property matters particularly when the maneuverType is HeedWarning.
  • Updated v5 URL parameters.
  • v5 route legs currently lack route summaries, so here I’m synthesizing them using logic similar to what would be done on the server side. This code can be very expensive, so I hope to remove it as soon as possible.

/cc @karenzshea @bsudekum @freenerd

A request has only one transport type, corresponding to the profile, but for every request, each step may have a different, more granular transport type.
Worked around mapbox/api-directions#567 by concatenating the two top way names by cumulative length along the route, but only if a route leg summary is absent.
Left in a PassWaypoint type for compatibility with v4.
@1ec5 1ec5 self-assigned this Apr 29, 2016
@1ec5 1ec5 added the bug label Apr 29, 2016
@1ec5 1ec5 merged commit 9daebc8 into master Apr 29, 2016
@1ec5 1ec5 deleted the 1ec5-v5-update branch April 29, 2016 01:35
1ec5 added a commit that referenced this pull request May 2, 2016
@1ec5
Copy link
Contributor Author

1ec5 commented May 2, 2016

97378ca follows up by inverting the logic for when to synthesize a route name.

@1ec5 1ec5 added the backwards incompatible changes that break backwards compatibility of public API label Dec 18, 2018
@1ec5 1ec5 added this to the v0.5.0 milestone Dec 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backwards incompatible changes that break backwards compatibility of public API bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant