Determine "best candidate" by time to fetch, not distance

[marians]

Currently we select the nearest AED by direct distance. And probably that's okay if the user has one candidates in reach (meaning shortest and second shortest distance are quite different). But it might not be helpful in cases where the user would have to decide which candidate would be the fastest to fetch. The nearest AED might not always be the fastest to fetch, e.g. if the user has to surround a huge building or if the AED is in the 30th floor (unlikely in Cologne).

I open this issue to discuss better ways to approximate which AED would be the fastest to fetch.

[marians]

I have a GraphHopper instance set up for testing purposes. It allows to calculate the foot route between two points in cologne.

Example call:

http://graphhopper.sendung.de/api/route?point=50.937743,6.944025&point=50.938811,6.946256&type=jsonp&vehicle=foot&encodedPolyline=false&minPathPrecision=1&callback=c

[marians]

Created branch "routing" to check out what can be done. Currently, the routes to the closest 3 candidates (direct distance) are fetched from GraphHopper. Then, these 3 candidates are reordered based on route length instead of direct distance.

A screenshot shows how this results in skipping the two closest candidates:

[marians]

Routing has now been merged to master and can be tested at www.sendung.de/aedcgn . Feedback welcome!