3 things you should not forget in your next digital mobility policy

As cities around the world continue to grow and urban populations increase, the need for efficient and sustainable transportation solutions becomes increasingly important. Digital mobility policies (like Germany’s ‘Mobilitätsdatenverordnung’) are an essential tool for transit planners and policymakers to address new challenges. The following three critical aspects should not be forgotten when creating a digital mobility policy.

Agencies must provide GTFS feeds and register with MobilityData

GTFS (General Transit Feed Specification) is a standard format used to describe public transportation schedules and related geographic information. GTFS feeds enable software applications to provide passengers with accurate and up-to-date transit information, including real-time arrival and departure times, trip planning, and other useful data.

While NeTEx (Network Timetable Exchange) is another standard commonly used for public transportation schedules in the European Union, it has limitations that make it less suitable than GTFS feeds for digital mobility policies. NeTEx does not offer the same level of standardization and compatibility with third-party applications, and the standard is too complex to adopt for pure navigation use cases. GTFS is has a high world-wide adoption rate and is supported by many software applications, making it the preferred format for developers.

So in my opinion, transit companies must provide GTFS feeds to ensure their data is easily accessible to the public. It is essential to register these datasets on the MobilityData GTFS Feed Registry – a centralized platform that aggregates GTFS feeds from all over the world. Registering datasets ensures their validity and enhances their discoverability, providing valuable information to passengers who use different transportation modes. Additionally, the policy should describe all aggregation platforms on all administrative levels (e.g. municipality, county, country) where the feed URLs must be registered.

Ensure data freshness, validity, and accessibility information

I think that GTFS feeds must contain all possible accessibility information, including the type of vehicle, wheelchair accessibility, level boarding, and real-time information. These details help individuals with mobility challenges and those who rely on transit to travel comfortably.

A policy should also contain quality requirements and explicitly regulate what happens if these requirements are not met. It is important to ensure that the feeds are valid, meaning they adhere to the GTFS specification. Transit companies must update feeds regularly to reflect any changes in their routes, schedules, or service disruptions, and ensure that data is correct, consistent, and easily accessible. Real-time data should also be provided where possible, as it enables passengers to make informed travel decisions.

A transit policy that does not enforce GTFS data validity as a law will lead to feeds being provided, but at varying quality – and in the worst case unusable for app developers.

Include pathways and level data at stop level to enable precise indoor navigation

There is still a missing key part of accessible transit navigation: How do I change vehicles on a transit route? Beyond merele a name of the next bus line, a blind person needs a precise location of the bus stop and precise infos about the way there. With a wheelchair or stroller, broken elevators and escalators can mean long journey delays – and unfortunately, these facilities are broken very often. So information about the routing graph, including elevators and escalators, must be included in the GTFS datasets, too. The GTFS RT standard will adopt realtime escalator/elevator status in the future, and data providers can already prepare by gathering and providing accurate wayfinding information as soon as possible. Transit companies who want to publish GTFS RT feeds with their elevator outages can contact me to get help.

Soon, mobility app users that use a wheelchair or stroller might not end up in front of a broken elevator anymore, but see a notification like this:

This feature is possible with pathways.txt/levels.txt – essential components of GTFS feeds that provide a routing graph including the accessibility of stations, platforms, and stops. pathways.txt data describes the pathways inside and between stations, platforms, and stops (including stairs, escalators, and elevators), while levels.txt data describes the reached floor levels.

It is crucial to provide this information at the stop level, not only at the station level. This data ensures that passengers can plan their trips and navigate transit systems more effectively. It also helps individuals with mobility challenges to identify the most accessible routes and stops.

In conclusion, digital mobility policies are essential tools for transit and city planners, and policymakers to create efficient and sustainable transportation solutions. When creating such policies, it is crucial not to forget to include GTFS feeds that are registered with MobilityData's GTFS Feed Platform, valid and accessible information, and pathways.txt and levels.txt data at the stop level. By following these guidelines, we can ensure that public transportation systems are more accessible, reliable, and efficient, ultimately improving the quality of life for urban populations.

If you operate a transit agency, feel free to contact Sozialhelden e.V. for help with accessible navigation.