Imagine you want to meet a couple of your friends at some restaurant. Unfortunately all live in different directions all accross Munich. So you´re looking for a place, which all of you can easily reach within 30min. using public transport. However most routing-services just give you the fastest route from one point to another one - but not from a number of source-points to a number of destination-points. This is what m:n-routing is about. The app that was created for this hackathon aims at finding all the locations within the dataset of places within Munich, that can be reached within a given amount of time by all of the source-points.
What it does
RAPP is a web-app that comes with a map and some textboxes where you can type a list of adresses as well as the amount of time you want to travel at max. After submitting your data you see some markers on the map - green for those location that can be reached by all source-points, red for the non-reachable points.
How I built it
I started by trying out the HERE routing-API - in particular the calculateMatrix-endpoint that enables an m:n-routing. Afterwards I added the geocoding-API so users can more easily type any abitrary adress instead of a geo-coordinate, as well as the xyz-service to get all locations within out data-hub. Finally all those locations from the hub are fetched into the matrix-calulation so we get all those locations that are reachable from all of our source-points.
Challenges I ran into
getting a POST-request for HERE data-layers for the spatial endpoint was impossible. I always ran into a GET which that endpoint could not handle. That drove me nuts, so I searched all features on my own and did the filtering on client-side. This of course is veeeery slow, but it gets its job done. Doing that I realised the lack of spatial functions such as intersect or contains within the API, so I had to use turf for it. Would be cool if true geospatial analysis would come in the future.
Furthermore the algorithm for m:n-routing differs from the calculation performed for the isolines. Therefor points that are located within the intersection-area of the polygons returned from calculateIsoline are marked red, because the routing-API identifies them as not-reachable.
JS-Arrow-functions don´t provide their own binding for
Accomplishments that I'm proud of
got a hobby-project ready
What I learned
callbacks on JS are so ugly, asnyc/await much neater.
What's next for Reachability Analysis App
perform spatial intersection of reachability polygons and query those POIs within that inersection-area by using the spatial-endpoint of data-hub.
use multiple travel-types such as public transport or bike.
use auto-suggest endpoint of Geocoding-API to enhance user-experience when typing in adresses.