In April of 2019 I became the transit planner for Sangamon Mass Transit District in Springfield, Illinois. This was a natural transition for me because I’d already been there for over a decade in an IT capacity and had intimate knowledge of how our schedules were run and, more importantly, how they needed to be represented digitally for public consumption.

About 4 years prior to this I managed to cobble together our first GTFS export that allowed passengers to navigate the system using Google Maps, Bing Maps, Here Maps, Moovit, and any other application that used GTFS information. Even though we weren’t broadcasting live data, the ability to retrieve static schedules via any serviceable smartphone made a huge impact and dramatically cut down on phone calls to our dispatchers - who now, ironically, almost exclusively reference the data as presented in Google Maps to give customers information anyway.

When I constructed our GTFS feed I searched far and wide for any and all applications or services that allowed me to submit it to them, and I vigorously tested each of them against each other to make sure our data wasn’t being misinterpreted or misrepresented. More often than not, any errors I found were the result of ambiguous data in the GTFS itself and not a failing on the part of the interpreter. So I refined and restructured and recalculated to remove any and all ambiguity, and I continue to do so every time I update it, even if it’s just a matter of moving the coordinates for a bus stop a few feet and recalculating the stop distances of multiple routes. I’m the authority on the information and I want it to be the best it can possibly be.

And this brings me to OSM and the apps that utilize it. I think that, when possible, for transit information they should first look to the GTFS data if it’s available for that area. Defer to TransitFeeds or Transitland first. If you don’t find anything, THEN start using bus stops and route relations from OSM. I think in most instances this would be preferable to referencing potentially outdated information, and it would preclude a lot of mappers from wasting their time adding information that’s freely available.

But there are exceptions. GTFS doesn’t allow for the granularity of data that OSM does, like whether a bus stop has a shelter or not. In some instances the GTFS data supplied by the agency lacks the shapes.txt file needed to properly draw the routes on the map and instead beelines from one stop to the next, resulting in route shapes that seem to traverse through buildings or even bodies of water. It would be nice if OSM mappers could supplement that information and fill in the gaps instead of replacing it outright.

If this data needs to be in OSM, there should be a workflow/pipeline for importing it and reconciling different schedules. I have the data readily available but I simply do not have the time to manually add/maintain 1200+ bus stops and and their corresponding route relations. We need an import tool that allows us to import our GTFS and to view the differences between one schedule and the previous, to confirm/deny stops that have been added or removed. If that were ever available I would gladly maintain our system in OSM, but until then I’m going to stick to the GTFS and hope developers know how to use it.