Reachability Analysis App

Get the points that are reachable from twp adresses within approx. 45minutes

Inspiration

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 this- whaaaat?!