search

KoelnAPI / aedmap

Mobile web application for the display of automated external defibrillator (AED) locations
MIT License
4 stars 1 forks source link

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

Closed marians closed 10 years ago

marians commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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:

screenshot

marians commented 10 years ago

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