<aside> 👋
This, and all of the desk research blogs, give an overview of the process and steps taken for each part. I’ve included images taken from the FigJam boards where the majority of the work lives to illustrate the process.
If you would still like to see further details on each part, please view the FigJam board in full.
It can be found at the end of this page, or on this master page.
</aside>
I now want to look at the back end side of things and start to consider that.
There’s two sides to this project; the user facing app, and the back end platform for networks. So far I’ve been mainly considering the user side of things, but I now want to take some time to consider the back end.
With one of my main aims being to provide users with first party data on a third party platform, I need to understand what data is used and how it used.
In this step, I want to understand how public transport data is created, published, and presented to the user.
I began by conducting some initial research and learnt that there are major distinction in data types and processes between types of public transport which are:
Due to the differences, I would need to tackle each individually. I wanted to map out the process for adding a line/route to a typical public transport app for each.
To delve deeper, I used ChatGPT to form an initial process for each.
I then broke each step up, and investigated into the specifics of each step.
<aside>
Something I learnt here which was really important was that most public transport data is already standardised into GTFS (General Transit Feed Specification), which allows for easier sharing and processing of both static and real-time public transport data.
Of course, naturally, the UK has it’s own proprietary data format (TransXChange) which is considered outdated, and is usually converted to GTFS when used by 3rd parties, which can cause data loss or inaccuracies.
This is really important to this project as it means: