3 ms·
> Actual transit providers typically lack the technical knowledge This is actually getting better, as most of the transit providers already rely on software co
by lqet 7y ago
> Actual transit providers typically lack the technical knowledge
This is actually getting better, as most of the transit providers already rely on software companies that provide their own route planning software for passengers and/or administrative software like tools to create the actual schedule with. These companies are slowly getting better in providing standardized feeds.
I am skeptical that something like a feed-wiki would work, both because of vandalism, and because schedules are usually incredibly complex. You may have noticed that your bus starting at 14:30 from station X was scheduled incorrectly, but does this service has this mistake every day? What about the 3 days a year where this bus has a slightly different schedule? If the bus travels every 5 minutes, and each trip has this mistake, you have to manually check hundreds of trips per day if they contain this mistake. Automation is difficult here, because trips that occur frequently are very often not grouped by any mechanism (although for example GTFS provides such mechanisms).
I think the better way is a legislative change which requires all transit companies to submit their schedule data to a central authority, which then publishes the merged schedule.
There is now (since the beginning of 2020) a new EU regulation [0] which basically pushes for an EU-wide multimodal route planner and schedule dataset (published in a special format, NeTEx). This makes it now possible to rely on the data of existing national schedule aggregators, which have been checking and merging timetables of all national transit providers for decades. For example, in Switzerland, the national railway company SBB does this (GTFS feed published here [1]), in Austria its also the national railway company ÖBB, and in Germany, its Deutsche Bahn (GTFS feed published here [2]).
[0] https://eur-lex.europa.eu/eli/reg_del/2017/1926/oj https://eur-lex.europa.eu/eli/reg_del/2017/1926/oj
[1] https://gtfs.geops.ch/ https://gtfs.geops.ch/
[2] https://gtfs.de https://gtfs.de
- londons_explore 7y ago>most of the transit providers already rely on software companies that provide their own route planning software This doesn't seem to apply to mid size networks and smaller. For example, when tree falls and blocks a road, in a midsize network there'll probably be one admin-person in the office who decides what to do about it. Usually they'll just print off a paper sign saying "All services to X won't go past Y today", then ask a driver of another service to put that sign at each stop. They'll log into the website and put a banner at the top saying the same, and they'll ring the local radio station to announce it. At no point does that info ever go into a computer in a machine-parsable form. Even if it did, timetables are probably saved in a big MS Word document.
- lqet 7y agoIndeed, but you are already one step ahead with real-time updates. This is an entirely different beast than static schedule data. In my experience (I occasionally talk to people in the industry), even providers of public transportation in cities with over 500,000 inhabitants have trouble providing reliable and machine-readable real-time information (like: this trip is cancelled today, this trip is 5 minutes delayed at station X, there is an additional trip Y today, expect delays this afternoon because of Z, ...). At least where I come from, the solution was that the state government decided to build a centralized infrastructure for all providers to use. Real-time information is displayed there on a website which also provides a real-time route planning. The real-time data is also available in machine-readable form. It is a lot easier to convince a small bus operator in a rural area to just enter cancellations / delays into a website than it is to convince him to buy and administer servers and software to built its own real-time service.