Transport / transit network integration

[overflorian]

Hi, following a discussion with @biodranik, let's explore ways to integrate transit networks in the app.

Goals

We should aim to produce a better transport map render and routing experience than proprietary software, using crowdsourcing and open data as leverage.

To achieve that, we need to:

1. use external data from the transit authorities and companies, known as GTFS files, to provide static geographic and schedule information
2. use and improve OSM data in order to generate a better geographical data quality than the one existing in each GTFS
3. use external APIs from transit authorities and companies to provide real-time data
4. improve the map render to display transit data and improve the routing engine

# Steps
I suggest progressive goals to achieve this long-term vision:
1. use existing OSM data

• clicking on a bus stop should display the number, name of the line, and the direction (destination)
  Example: clicking on this bus stop https://www.openstreetmap.org/node/6263448326 should display (line number 513, line name "La Traverse Bièvre Montsouris" and destination "Alésia - Général Leclerc" that is displayed in the relation https://www.openstreetmap.org/relation/1086658
• activating a new "bus layer" should display the shape and color of each bus route and stops
  Later in the process, add other transports than a bus, including but not limited to train, tram, subway...
  This is approximately how it's done in OSMand, and it should be replicated but with a simpler UX in Organic Maps.

2. use external GTFS files
These "officially produced" files apply to a specific city / region and should be specifically handled.
This implies a massive amount of sub-constraints, such as and not limited to

• being able to link the GTFS data to OSM data with a perenne and unique ID
  For example this bus stop https://www.openstreetmap.org/node/6263448326 has a unique ID ref:FR:STIF=28223 that allows to link it in a unique way to the local authority referential (here)
• quality validation
• prioritization of the data used between OSM and GTFS, according to specific rules
• ...

3. improve GTFS quality in OSM
This would allow any user to improve OSM data on the top of the GTFS file, in order for OSM to always be a better data source.

4. use real-time data
The last step would be to use real-time data from external APIs, with the need for an internet connection for the user.

---

My company Jungle Bus contributed to produce a lot of open-source software to solve these issues and we are happy to help.
Please see https://wiki.openstreetmap.org/wiki/Public_transport/Tools for more information. There is a page dedicated to quality control: https://wiki.openstreetmap.org/wiki/Public_transport/Quality_Assurance

PS: in order to achieve the vision of OSM being inevitable for bus transport over the large-Paris-area, we

1. mapped every single bus stop in OSM, including a unique ID (it took more than 4 years to achieve this first step)
2. contacted the local authority, which was happy to request a detailed audit to compare OSM VS GTFS data (here, only in French), that took one more step
3. chose the "OSM first" approach for our future projects (see the full infographic here) to make sure OSM would remain ahead of other data sources.
4. work with the local authority to improve the GTFS quality using OSM (see open data comparing the distance of the bus stops here)

We would be happy to be an experimental territory to test any step for Organic Maps to move forward.

[patepelo]

I'm happy to read this. Public transport is something very important that need improvement on apps based on OSM.

This project is worth mentioning: https://github.com/grote/Transportr

I believe they are newly active on development again.

[biodranik]

See related issues: https://github.com/organicmaps/organicmaps/issues?q=is%3Aissue+is%3Aopen+gtfs+label%3A%22Public+Transport%22

A preliminary vision for the OM's PT implementation:

1. Validate and generate bus, tram, rail, and ferry lines information from OSM, in a similar way as it is done now for subways (@alexey-zakharenkov may help with his validator) or using some other approach that allows to display and build simple routes in OM without schedule/real-time information. It should cover many cities and motivate the OSM community to update the transport network.
2. Collect real-time GTFS feeds on a server, map them to OSM data (the most complex task btw), and efficiently distribute them to clients (likely in a simple custom format suitable for the routing algorithm) so they can cache this data and use it even in offline when building routes.

Any volunteers to help/lead the implementation are welcome. The goal is to build a public transport service that is better than existing ones.

[jumelles]

GTFS definitely seems like the way to go. The GTFS site explains how it covers more than just timetables:

GTFS is most widely known for trip planning information, particularly in metro areas with fixed-route service. However, there are a variety of optional features above and beyond the basic GTFS Schedule specification that make GTFS more widely applicable, including Fares for showing fare costs and structures, Flex (in development) for demand-responsive transit options, such as dial-a-ride and paratransit services, and Pathways for displaying accessibility information that’s vital to riders using mobility devices or needing additional accommodations. GTFS Realtime builds upon GTFS Schedule and on-vehicle GPS systems to provide real-time updates on vehicle locations.

If I'm understanding correctly, it would make sense to pre-download the GTFS Schedule, and then use GTFS Realtime when Organic Maps has an internet connection.

[overflorian]

Hi, I agree with step 1. suggested by @biodranik.

Step 2. is more complicated... and should be discussed.

2 scenarios:

1. mine: use GTFS as they are, as you suggest @jumelles
2. yours @biodranik: Transform GTFS data to OSM format

Each option has its benefits and drawbacks:

1. GTFS: by-default management of timetables and more (mobile booking and payment...), need a proper server-side repository with OpenTripPlanner or Valhalla
2. OSM format: already supported in OM, less short-term development but need specific software to be supported such as GTFS2OSM. Also it might be limiting in the future.

[biodranik]

That is an easier step, yes. Adding and displaying these fields and route numbers is a good basic step. Any volunteers?

[biodranik]

Let's create a separate issue for stop position, with the best examples form other apps.

[PinguDEV-original]

@biodranik where can I find the issue?

[biodranik]

Is this one related? #2175

Displaying existing OSM metadata for existing OSM stops would already be very helpful.

[amirshahab89]

Hi! This is an awesome idea & I hope to see it come to fruition soon in the near future.

Here in Sweden, there is "Trafiklab". It seems that they have the full coverage of all public transport in the nation with relevant companies. See here; https://www.trafiklab.se/

They mention these GTFS Files can be used here; https://www.trafiklab.se/docs/using-trafiklab-data/using-gtfs-files/

The "GTFS Regional" API is live, as they mention here; https://www.trafiklab.se/api/

Hope someone here in the community knows how to use/ implement these into OM the best suitable way possible.

[patepelo]

Just adding some references that might help in the future:

https://overpass-api.de/ --> https://overpass-api.de/public_transport.html

Example: --> https://overpass-api.de/api/sketch-line?network=VRR&ref=625&operator=

And also consider the efforts of the Trufi Assosiacation, also on GitHub

[horvbalint]

I am not sure, but wouldn't this new project (started few weeks ago at fossdem) when ready, help organic maps to integrate public transport?
Maybe some collaboration would be beneficial :)
https://github.com/public-transport/transitous

[Machion]

I would be very happy, if at least line numbers soon find it's way into OM. It would be very helpful

[eagle-programming]

Directions for the Underground and other new public transport should be displayed. Otherwise you won't know which line to take. Data should be available from OSM.

I only know to take the U2 and U3, but not the direction.