-
Notifications
You must be signed in to change notification settings - Fork 90
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
Navigation on mapmatched routes #526
Comments
Thank you, @csongorkeller, for the report. @ShanMa1991 or @jill-cardamon could you run with the initial investigation? /cc: @andrewbrownnz |
I’d check first if the code they provided results in a NavigationMatchOptions and NavigationRouteOptions that has |
Hi @zugaldia, @1ec5, @jill-cardamon, @ShanMa1991 is there an update on this issue? We're keen to get Mapmatched routes into the SDK so if you could let us know how to proceed. Thanks. |
Hi @jackgregory , after looking into this case, we could reproduce this issue. The problem should be related with the response of the
|
thanks @ShanMa1991 I've tried your workaround but as I thought It's not working, since it has the 25 limit. Is it possible to use mapmatching somehow without the 25 limit? So like plotting the route directly on the map after mapmatching? |
@ShanMa1991 thought it would be useful to give you some context to our issue and use case. We currently have a custom server and API which plots a route on a map based on user preferences (elevation, time, distance etc.), coordinates returned for each route are between 500-1000. These coordinates are then passed to the Map-matching API so we can format data for the Navigation SDK. We need the turn-by-by directions and route in the Nav to be the same if not as close as possible to the original route, so don't want any new routes calculated on top of the supplied route. We can not use waypoints as there is a limit of 25, we have had our limit of coordinates raised to 1000 for the Map-matching API. So ideally we need to use the Map-matching API and have the directions passed to the Nav SDK and navigate through that route. If theres another method were unaware of please let us know. |
Going back to the original post, I don’t think it should be necessary to create or modify a NavigationRouteOptions within the completion handler of |
Thanks for the response @1ec5 but this doesn't work either. Also I haven't found much documentation on how mapmatching should be used with custom coordinates. Do you have anything that might be missed? |
ResponseOptions is an enumeration: if it happens to be a guard case let .match(matchOptions) = response.options else { return }
let routeOptions = RouteOptions(matchOptions: matchOptions)
If you haven’t seen it already, this example demonstrates using |
Great @1ec5, many thanks for this. Although when starting the navigation at the end, I haven't found a workaround for how to assign a Hereby the method for starting the navigation:
|
By the time you’re in the completion handler of As far as the navigation SDK is concerned, it’ll have been a normal Directions API response all along. Depending on your application’s intended rerouting behavior, this may be problematic, because you might want the user to stay on the map-matched route instead of a more optimal route returned by the Directions API. In that case, you could implement |
Thanks @1ec5 this did the trick, Although now I'm facing another small problem. Well, actually 2 of them.
And As you see, I got back a lot of fake points:
Many thanks for your help |
@1ec5 Do you have any idea why the above-mentioned behavior appears? I haven't found anything mentioning this problem... Thanks in advance |
These results look like they could be submatches, but it’s hard to know without the specific request that you sent. Could you contact Mapbox Support or your Mapbox account representative so we can rule out a server-side or one-off problem? Please include the specific tracepoints/waypoints you used and any configuration options, or better yet, the full URL and request body returned by
Common reasons for returning no match include requesting tracepoints that go against the flow of traffic or pass a road closure (which may be time-dependent). If your input data comes from one mode of transportation but you’re requesting a match against a different profile (for example, matching your morning jog through a park to the road network), that can easily lead to missing or circuitous matches. It looks like the original issue reported above has been addressed, so please open a new issue if you run into any other roadblocks that are specific to the MapboxDirections library as opposed to the Map Matching API, and definitely write into Mapbox Support if you encounter anything that may be API-related. Thanks for taking the time to report and write up these issues! |
@1ec5 I think the above mentioned issues are still related to mapmatching and navigation. And hereby the response body:
|
And here is a case when there are valid coordinates but receive NoMatching back for some reason.
Here is the request URL in this case, interesting but doesn't generate the points for some reason into the URL, nor the settings. Why could that happen?
And then this is the error coming back:
Now it's unknown, but sometimes I receive back NoMatching |
Reopening per @csongorkeller's request via email. |
The Map Matching API uses POST requests, not GET requests, so the coordinates and every parameter except |
@1ec5 We are using POST requests and the |
Look at the raw JSON-formatted response from that URL – not processed by the MapboxDirections library in Swift. If submatches is the issue, you’d see multiple items in the |
Hi there,
I have an issue with using the mapbox iOS navigation SDK along with mapmatching API. Basically, the problem is after receiving the mapmatched response the navigation SDK doesn't draw all the points on the map. It only picks a few points from the list and therefore the navigation also doesn't contain the whole mapmatched route.
Also noticed that both of the methods: Directions.shared.calculate() and Directions.shared.calculateRoutes() do calculate a brand new route even though the points already matched with the route.
Here is the method which accepts 2D coordinates and matches them with mapbox, then calls the navigation SDK for navigation:
Also saw in some documentation that maybe waypoints would do it better, but there is a 25 limit, and in my approach we'd have 400-1000 points to show on the map and navigate through them. Do you have any help how this could be working?
Thanks in advance
The text was updated successfully, but these errors were encountered: