oisinq / dbikes-planner

dBikes Planner: A predictive journey planner Android app and Python back-end API for Dublin Bikes

dBikes Planner

dBikes Planner is an Android journey planning app for cyclists using the Dublinbikes bike-sharing scheme. It allows users to generate cycling routes from their location to a destination, taking into account the availability of bikes at each station.

The back-end for this project is a Flask web server in Python. It uses a microservices approach, building a HTTP API. scikitlearn is used for generating predictions. The app is currently designed to run on Google AppEngine, incorporating many Google Cloud features. CycleStreets and OpenStreetMap are used for generating routes.

The front-end is an Android application. It displays the location and status of each station in Dublin, as well as historical data for a station. Users can input a destination, and will receive a cycling route to reach this destination, incorporating bike-sharing stations. Basic directions are also provided.

This app is currently designed for use in Dublin. It could easily be extended for other international bike-sharing schemes.

Installation

The back-end is designed to run on a Google Cloud AppEngine instance. It can be deployed using:

gcloud app deploy

To function correctly, you will need to set up a bucket to store historical bike data. The data in this repo's /data folder can be used for this purpose.

The Android app also requires a Google Maps API key. Change the value in the two google_maps_api.xml files to your Google Maps API key.

If you want to download the latest .apk without compiling from source, the /releases tab is the place to go.

Have fun!

dbikes-planner's Issues

Tweaks to station selection

Would like to fix this up so that it will select a moderate station if it thinks the bikes will be there when the user arrives eg if the rate of usage at that time is generally low, still select it

Use walking distance when finding nearest stations

Currently it uses Euclidean distance, which is generally good but leads to issues like this:

Walking API is sometimes not good

Like in this screenshot...

It like goes back on itself sometimes and just doesn't plan the best route often

A favourites tab would be cool

Migrate files to Google Cloud again

I tried this before, but it didn't work. Would be nice to try again: would make deploying easier and might be able to switch to a Standard instance of AppEngine.

Colour-code text when a station is selected

Need to add VGI component

This could be a notification after a journey asking "were you waiting long" or something along those lines.

Migrate from AppEngine Flex to Standard

Kinda badly needed tbh, Flex will be very expensive when my free credits run out

Station icon doesn't rvert from spaces -> bikes after a journey is completed

(The starting station doesn't change either)

Notification if your journey time is over the Dublinbikes free time

Prediction for the ending station isn't correct

Needs to take into account the length of the cycling portion of the route when making a prediction

Doesn't really take waiting into account

Would be nice if the predictor could figure out if you'd be better off waiting until bikes arrive. Kinda hard to do because we only have data from every 10 minutes and we only see the current availability, not exact numbers for how many bikes came in and out.

Time selector for future journeys

Expanding on #7

Black bar when there's hardware buttons

This issue is based on a mix of street views and bottom sheets. Potential fixes I can think of are:

1. Moving from bottom sheet to a different kind of interface when a station is clicked
2. Maybe replacing the StreetView with an image or a custom 360 image that we can use there

Or just some better way of indicating that the bottom sheet can be dragged up

What if a location isn't permitted and you plan a journey?

Sometimes walking is better?

Like say if you're in Charlemont and wanna go to Ranelagh. Could be cool to show the walking route instead.

Refactor code

The code (especially the Android code) is not in good shape. It needs a full refactoring to get up to standard.

Need to distiguish between bikes and bikestands in map view

Station graphs need to be real-time

Probably easiest to store this locally, but get some real-time info from the station for today's usage? Idk

Go into more detail on Co2 craic

Could be nice to have a breakdown on Co2 usage, compare it to public transport

Collapse bottom sheet when title is clicked on exapnded state

Show graphs for bikestands instead of bikes

Just add the endpoint, Android app logic should be easy

Better graphs

Via feedback:

my only complaint was the I wish you could make the graph full screen when you tapped or swiped up on it- be cool to see it more clearly. I felt like I could keep swiping up when the graph showed up and it felt weird when I couldn't.

Journey info doesn't take into account the walking segments

Shouldn't be a difficult fix. Just add walking stats to each RouteType object.

*urgent* unix_timestamp column is a mess

Need to get this normalisation working throughout. Not a tough fix but important

Doesn't let you plan future journeys currently

Could just be a pop-up after you select a place

Normalise data

Support for council bikeracks would be very cool

This is more of a long-term issue. It would be really cool if it also took into account where bike racks are, and uses that info.

Add "ultra high" availability?

I'm not sure why I want this, but I think I do?