TfL Digital Blog – Digital news from Transport for London
TfL is the local government organisation responsible for most aspects of London's transport system. Our role is to implement the Mayor's Transport Strategy. TfL share the latest news about all things digital. We post regular updates about new releases to our Unified API, hack days, events and partnerships.
This week we have a guest post from Rikesh Shah and Daniel Gosselin from our Commercial Innovation team.
We recently launched London RoadLab, a new way of working with innovators.
London’s transport network has been consistently delivering new technology and innovations. We are home to the very first underground railway and, in 1868, the first traffic light was introduced in London. We couldn’t imagine London without traffic lights now, but 150 years ago our roads were revolutionised by taking something used for the railway and applying it to motor traffic.
More recently, we have developed a world-leading contactless payment system, and launched our open data products. Our open data now powers nearly 700 apps, used by 42% of Londoners and has not only allowed us to work more closely with app developers, but has generated new jobs and enabled Londoners to plan their journeys through their channel of choice.
Technology continues to develop at a faster rate than ever before and it’s important that we continue to embrace the latest innovations to help us deliver better services for our customers. Following the success of open data, we wanted to explore how to work more closely with innovators to develop new products that solve our problems.
We have also been exploring what else we can do better and what problems we can solve. One of these is roadworks. Roadworks on our strategic roads have an estimated £2 billion cost to London’s economy every year, and, whilst we appreciate their importance in keeping London moving, we also know we must continue to find new and innovative ways to reduce the impact they have on the city. We knew we needed to find new ways to work with innovators to create useful and tangible solutions to solve this problem. We also knew it was important to offer unique access to our assets and expertise, and to be able to take the products forward at the end of the programme.
Sign up for RoadLab
It’s true to say that this area of innovation is new for corporates and the public sector. The value to innovators of getting to work with companies like TfL to develop something that solves citywide problems is significant, and we need to offer opportunities like innovation partnerships to enable us to deliver this.
Building on our research over the past few months, we have created a new process for bringing innovation into public sector organisations and working with innovators beyond a set programme. We are offering unique insight into TfL, providing expertise, data, and pilot sites alongside a programme of mentoring and business support from our partners at Plexal.
If you think you can make roadworks in London safer, smarter, or more inclusive please sign up today.
Later this week we’re planning to add some fares information to the “Journey” endpoint of the TfL Unified API. This will be shown on TfL’s online Journey Planner, and developers using the Unified API will be able to show the same fares information.
We will provide and display the adult pay as you go fare for any journey which is fully pay as you go, made up of only Buses, Underground, DLR, TfL Rail, Overground, Trams, Thames Clipper, Emirates Air Line and some National Rail. The peak or off-peak fare will be given based on the time of the journey.
How the change will appear
The “Fare” property in the Unified API response is currently null, we’ll be populating it with a “Fare” object.
In addition to the fare itself, the “Fare” object also contains a breakdown of the cost, and more information about how to pay the fare, what time to travel, etc. This information should be made available on any platform using the fares information, to ensure users know how to pay the expected fare.
Join us on 12-13 June for the Transport for London (TfL), Met Office, and Amazon Web Services (AWS) London Hackathon at Amazon’s office in London. You will have the opportunity to compete against other teams of developers to create an innovative application that improves street environments and makes it easier for everyone to get around on foot or by bike. Help us to make London a city where people choose to walk and cycle more often by taking part in this hackathon. Register here now: https://travelhackathon2018.splashthat.com/
Join us for the Transport for London (TfL), Met Office, and Amazon Web Services (AWS) London Hackathon at Amazon’s office in London.
This is a two-day event sponsored by Cloudreach, where you will have the opportunity to compete against other teams of developers to create the most innovative application running on AWS.
Learn from subject-matter experts from TfL, Met Office, and Cloudreach to help address some of London’s key challenges.
The recently published Mayor’s Transport Strategy sets out a vision “to make London a city where people choose to walk and cycle more often by improving street environments, making it easier for everyone to get around on foot and by bike, and promoting the benefits of active travel.”
This vision aims to reduce traffic, pollution, and noise; and to create more attractive, accessible, and pedestrian-friendly streets for citizens. A more engaged, physically active society leads to a healthier people.
The plan includes a target that 80 percent of all Londoners’ trips will be made by foot, bike, or public transport by 2041. Achieving this goal will require a considerable shift in behaviour citywide.
This is where you come in! We want to open this challenge to the wider developer community to find innovative solutions to this key challenge. Through teamwork, TfL believes we can provide our audience with the best information, tools, and encouragement it needs, to help influence behavior toward more sustainable and active travel.
Ahead of the event, we encourage you to think about the challenges below and will provide you with the data concerning cycling, walking, air quality, weather, and roads.
Encourage a mindset shift:
Encourage active travel for the first and last miles. Drive good behaviour through social influence by making it easier to share travel plans and through wearables. Inspire the development of new travel planning technology and features. Encourage combining TfL and Met Office data to develop air quality/active travel products.
Enable and support more active travel:
Improve the functionality and personalisation of existing active travel journey-planning and navigational tools (e.g. routing features enhanced by new cycling and walking data), and build new resources and technology.
Empower users to share feedback:
Develop new tools and enhancements to allow crowd-sourcing of customer feedback and reporting of data errors (to support management and maintenance of cycling and walking datasets). Provision new mechanisms for communicating expectations for healthy streets and the barriers / improvements that can inform future policy development.
So whether you’re a start-up or a developer, if you are in a position to develop a product that addresses the challenges outlined below, you should join us at the launch event on 10 April.
Where and When
Venue: Amazon’s offices – 60 Holborn Viaduct, EC1A 2FD, London
When: April 10 – April 11, 2018
Free drinks and nibbles will be provided at event.
Through this transport-focused Hack event, TfL, AWS and Met Office are keen to work with the start-up community, app developers, UX and design specialists, and anyone with a passion for data in order to build new applications and unlock new insights from the data.
We’ll ‘hack’ on 10 April from 10:00 to 18:00, and resume on 11 April from 10:00 to 16:00.
You will receive AWS Promotional Credits, which will help you take your project from idea to implementation. Subject-matter experts from TfL, AWS solutions architects, and developers from Cloudreach and Met Office will be onsite to provide support and mentorship. At the end of the two-day hackathon, a panel of experts will choose the most innovative application, and prizes will be awarded.
What you’ll need
You will need to bring a laptop and you will need an AWS account. AWS credits and an API will be provided to access the data.
Rapid charge points can charge an electric vehicle battery in 20-30 minutes. This is quicker than regular charge points that can take 7-8 hours for a full charge.
The majority of these charge points allow for pay as you go payment using a credit or debit card – you don’t need to be a member.
They allow high mileage users, such as electric taxi and private hire drivers and freight and fleet operators, to quickly charge their vehicle. We have committed to install 150 rapid charging points by the end of 2018 and have at least 300 by 2020.
Electric Vehicle Rapid Charge Point (ECP) data is supplied to us from a number of concessionaires who install and manage charge stations across the UK and Europe. These concessionaires include British Gas, Charge Master, FastNed, Bluepoint and ESB, although at present not all of them have facilities in the Greater London area.
We consolidate the data, which is provided in a client-specific format, into a common structure available through the TfL Unified API that third-party users can consume in a simple, generic way. We have worked closely with Zap-Map, the leading source of information on EV charging points for the UK, to fine tune our API data for third party users. You can view the TfL points on their map and filter on taxi only rapid charge points.
Although the physical ECPs can differ considerably between concessionaires and even a single concessionaire can have different models of charge stations, we transform the data associated with them into a consistent, dynamic parent-child structure of ChargeStation with one or more ChargeConnectors.
As part of our import process of this data, we exclude ChargeStations (and therefore related ChargeConnectors) that are considered outside of the Greater London area.
Charge Stations and Connectors
A ChargeStation is the physical appliance, that may be one of several in a specific location. It has a unique identifier and name, as well as being designated to a latitude-longitude position.
It is also possible that a single ChargeStation can support multiple parking spaces.
A ChargeStation can have one or more ChargeConnectors. The connectors represent the physical connecting alternatives that can be accessed at a time, and each one has a unique identifier and name, as well as an occupancy status associated with this element, along with the other properties, detailing the type of connection, power, etc.
From the TfL Unified API, both the ChargeStation and ChargeConnector core data is available via the existing Place endpoint(s) and the current availability of a ChargeConnector is through the Occupancy endpoint(s).
The core data is the key information that describes the Station and Connector, and the information that comes from the concessionaires is accessible via the additionalProperties field collection. The most relevant attributes of each additionalProperty are the category, key, and value. Common keys for all ChargeStations are “ConnectorCount”, “Location”, “Name”, “Reference”, “PricingUrl” and “Restrictions”. Common keys for all ChargeConnectors are “ConnectorDescription”, “ConnectorType”, “ParentStation”, “Power”, “Status”.
Special Note: The “Restrictions” field will identify if the charge station is for Taxi Use only.
The core data is updated daily from the independent concessionaires and we recommend this data is downloaded and stored on local servers for reference and performance.
You can specifically request the different Place Types, but in doing so you will not get the parent-child mapping between the two. The recommended request is as follows, which will return all Greater London ECPs.
The response to this request would include a collection of all ChargeStations with child ChargeConnectors, as well as ChargeConnectors as top-level objects. A request can be made using the Place endpoint and the unique id to return just a single Place.