In the demonstration, I illustrate how to use the Anatella box named "restCall" to access 2 different API's offered by BING (the geocode API and the route API). we used BING because it's much cheaper than Google but with only a few small modifications, you can get exactly the same demonstration to work with the Google API.
The demonstration also uses the k-NN Anatella-action to compute the K-closest agency to each client. By default, in the demonstration, I used k=2, but you can easily change that if you want. This "k-NN" box takes into account the curvature of the earth to compute the 2 closest agencies but it does NOT take into account the road network. This is why we used (at the end of the demonstration) the "route" API from BING to, finally, compute exactly the closest agencies in terms of travel distance and/or travel time using the road network.
At the end of the demo graph, you get for each customer the closest agency (in terms of distance and/or time), taking into account the road network.
The next steps are:
* inside the Anatella demonstration graph in attachment, if you intend to use the BING API (for the geocoding and/or for the routing), please create and use your own "Bing Maps Key" . The documentation on how to create a "Bing Maps Key" is here.
* improve the error-handling: I expect that, from time to time, the API calls is failing (i.e. the BING server does not repond). This didn't happen to me but I am pretty sure that it will happen at one point.
* maybe test for different values of the parameter "K" (k=5)
* maybe test with another API than the BING API? Maybe test the Google API or the Mapquest API.
* improve the speed when computing the "routing" (only do that if you see that it's too slow): Currently, each "API call" computes the routes for 1 customer. With a little bit of work, it's possible to only call one time the API to computes all the routes for several customers. This should reduce slightly the computation time.
* the BING routing API offers many options: in particular, you can choose the hour-of-the-day during wich you compute the "travel time". This might totally change the results. Currently, we didn't define any specific hour-of-the-day but it might be interesting to get the routing results at a specific hour (e.g. 16:40).