Introduction

The steps followed in order to create a weather and travel app that would be useful for the end user were:

1. Define what information would be most useful to the user.
2. Identify from searching the available API data, which parts of that data most closely matched the requirements from 1.
3. Work out how to retrieve the information required from the relevant APIs.
4. Design a ploty Dash dashboard to display the information retrieved in a clear/ appealing way.
5. Deploy the app using Heroku.

User requirements for the data

Identifying and Extracting relevant information from the APIs

Weather Information

json_normalize(json_data['SiteRep']['DV']['Location']['Period'][0]['Rep'])

This yielded the weather forcast for the first period in the data retrieved, the appearance of which is shown in Figure 1.

The columns show the forcast data in terms of different variables with the rows representing different times in the current three hour period. In order to decode the column variables used, the contents of

json_normalize(json_data['SiteRep']['Wx']['Param'])

was used which is shown in Figure 2.

The units were added to the variable description and then the column names from the dataframe shown previously renamed accordingly with

.rename(columns=weatherheader.set_index('name')['$'], inplace=True)

Weather codes stored as a dict allowed codes in the 'Weather Type' variable in the dataframe to be translated to meaningful string representations.

Transport Information

Transport for London's Unified API [2] was used to retrieve transport data. From the list of available requests on their website, the 'Gets the list of arrival predictions for the given stop point id' query seemed the most useful for the end user. However, this required the 'naptan ID' codes for each stop point of interest as input. These were found using the following steps:

1. Googling the bus stop to find the 5 digit bus stop id.
2. Using the query 'Search StopPoints by their common name, or their 5-digit Countdown Bus Stop Code' to get the stopping ID.
3. Using the query 'Gets a list of StopPoints corresponding to the given list of stop ids' to get stop point naptan IDs.

which allow data in the json format to be accessed. A similar procedure was followed to retrieve the relevant tube data.
The data from these requests was investigated in more detail to find out its structure and identify how to extract the elements of interest. The json output was decoded into a dictionary and then turned into a dataframe with json_normalise. The result was a dataframe with variables listed in columns and rows representing the different bus numbers and their relative direction (inbound or outbound with respect to central london). In order to identify the buses and directions of travel of interest, the dataframe was filtered based on lineID (bus number) and destination (indicating direction of travel). A loop through the remaining data points allowed each of the subsequent arrival times to be found. For the tube data, a general status of the line of interest was identified using

json_result[0]['lineStatuses'][0]['statusSeverityDescription'] # status as string description
json_result[0]['lineStatuses'][0]['reason'] #reason

Presenting the information in a Dashboard with Plotly Dash

Plotly Dash [3] seemed an attractive proposition to use to create the dashboard for this project. It's key advantage is that all the dashboard can be written in Python. Having retrieved the data and extracted the relevant information, the main task was to define the layout in app.layout. Much of the data is currently presented in text form as this seemed most sensible in order to get things up and running and considering for the end user interactivity is unlikely to be important. However, some of Dash's interactive capabilities were investigated by presenting the numeric weather information in a line graph with the variable of interest selectable from a drop down menu and shown on the y axis with time/ subsequent forcast periods on the x axis. A slider was added to enable the user to move through subsequent three hour forcast windows. The current format of the dashboard is shown in Figure 3. The dashboard was set up to refresh the information displayed on page reload.

Deploying with Heroku

Heroku [4] was used deploy the app on the web. This required a free Heroku account and Python 3.6, pipenv and Postgres be installed locally. The Heroku command line interface was installed on linux using

sudo snap install heroku --classic

Then using

heroku login

requests the login details. The app was deployed to Heroku using

heroku create
git push heroku master

Different numbers of instances of the app can then be run using

heroku ps:scale web=number_of_instances

Heroku recognises it is dealing with a Python app by the existence of a requirements.txt file. Requirements for the app are dealt with using pipenv. For debugging and development a local version of the app can be run using

heroku local web

which uses the local Procfile to find what to run. The app is available at http://localhost:5000. To push changes to Heroku the following is used

git add .
git commit -m "Demo"
git push heroku master

Bibliography

1. M. Office. MET Office Datapoint (Contains public sector information licensed under the Open Government Licence), MET Office, 2018.
2. TfL. Transport for London Unified API Powered by TfL Open Data (Contains OS data © Crown copyright and database rights 2016), Tfl, 2018.
3. P. Technologies. Collaborative data science, Plotly Technologies Inc., 2015.
4. Heroku. Cloud Application Platform, Heroku Inc., 2007.