Snap to Route Fails Silently
markolbert opened this issue · comments
I'm running into an odd problem using the snap to route feature of the Bing Maps REST API. It works great for most of the GPS coordinates I send it -- they were recorded by me on a recent motorcycle trip, so they're "contiguous" -- but fails silently for others.
As in, the returned status code is 200...but rather than returning SnapToRoadReponse objects it returns Route objects. Which lack any of the snapped-to coordinates I need.
What's particularly interesting is the problem occurs in the middle of processing the entire route. In other words, it works fine for 6 or so invocations (each with around 100 points), fails for a number of invocations, and then works fine for the remaining invocations.
Maybe Bing Maps just doesn't like the hills east of Santa Rosa and the 101 corridor south from there over the Golden Gate Bridge... :)
Turns out the problem was sending too many points through the request pipeline. The Bing Maps REST API requires/strongly advises not to use GET requests involving more than 100 geographic points. I assumed the Bing Maps REST Toolkit took care of ensuring larger requests were done as POSTS. It does not, however, appear to do that.
Reducing the number of geographic points to no more than 100 per request solved the problem.
The portion of my route which was causing problems involved high speed freeway travel, which caused my code to interpolate additional points for each set of observed data points so as to ensure no two points were more than 2.5 kilometers apart (that's a Bing Maps hard limit). That drove the total number of points for each request along that stretch of the route to over 100 points, causing the problem I encountered.
It sounds like there's a bug in the code which doesn't properly switch from GET to POST requests when the number of points exceeds 100.
Looking into this I found the error. Looks like someone changed the class that the response was being serialized to. Instead of being a "SnapToRouteResponse" it was being serialized as a "Route" which was causing the issue. Synchronous response are deserialized as "Response" objects then casted. Strangely, this is the only async service in Bing Maps that returns a full resource set response object rather than just the result object in the async response. So this was also causing an issue and wasn't the case when this library was created, so something changed.
In any case, I've fixed this bug in version 1.1.5 of this library and tested with a few hundred points. Note that version 1.1.5 currently is only available when loading the library locally, not sure who updates the NuGet package these days.
Thanx!