news // 2010.10.19 08:10:42 [hh]

"Transiki": Open-Source-Fahrpläne im Stile von "Open Street Maps"

Steve Coast, einer der Urheber hinter den "Open Street Maps" hat jetzt ein neues Steckenpferd, nachdem er in San Francisco einen Zug verpaßt hat. Sein neues Projekt heißt "Transiki" (kurz für "Transit Data Wiki") und soll nach seinem Willen weltweit alle Fahrpläne und Verbindungen erfassen und bereitstellen.

Steve Coast in seinem Blog: "Transiki (will) look a lot like openstreetmap. The API looks similar. Instead of nodes, you have transit points. Instead of ways, you have transit routes. Instead of bizzaro-the-clown ontologies, there is tagging. There will be a GTFS importer. The code is open. The data is open. There will be the ability to modify both the long term and short term data. That means you can modify either the timetable for next season and you can also flag a particular route that is delayed right now today.

Like openstreetmap, the API is open and free. And you can throw services against it to read/write as you see fit.

So this all begs the question, why not build this in openstreetmap? Well there are a number of reasons. OSM isn't really built for that kind of realtime changing timetable data, the transit data has to integrate across all the other data, transit routes aren't exactly trivial to add in to the data as relations... it's just not quite built for it. That aside, there are a ton of reasons to link the two things together. OSM already has a lot of transit point data and some routes for example. But this is easily achieved by just tagging stuff to point from transiki to OSM or the other way around. Or importing the data. One way to think of transiki is as a kind of specialized OSM.

The big problem of course is that transit data changes all the time. But that's kind of the point of having a public API - anyone can write a bot to keep the data up to date from whatever bizarro format they're ingesting from. Then the whole thing can be dumped out for anyone to use.

Also like OSM, you can start from the beginning and throwing out assumptions on what transit data should look like from 1960. The code is very basic right now, which helps you get started if you want to help. The main aim is to get up a functioning API and a GTFS importer, then everyone and anyone can help build all the other services just by talking to the API. And we can dump all the data in to Brandon Martin-Anderson's graphserver to route against."