Snap to Route Fails Silently about bingmapsresttoolkit HOT 3 CLOSED

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.

from bingmapsresttoolkit.

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.

from bingmapsresttoolkit.

Thanx!

from bingmapsresttoolkit.