[Open-transport] API for Deutsche Bahn Fernverkehr schedules

Thomas thomaskoch at gmail.com
Tue Mar 1 22:25:10 UTC 2016

GTFS requires you to put all the stoptimes in the same time-zone, each
agency has one timezone (and Transit only accepts one agency time_zone per
feed) effectively.
Trips across different timezones are then handled by the time_zone in
stops.txt, so you can convert to local-time.
Of-course there are probably still a ton of caveats here, even for just the
Netherlands on the nights of the DST switch.

Also Google has data for the Russian Railways (GTFS? HAFAS? we dont know
even for DB) allowing you to route Scotland->Vladivostok effortlessly
(transfer-patterns ftw)



On Tue, Mar 1, 2016 at 10:24 PM, Stefan Kaufmann <transit at shutterworks.org>

> Am 2016-02-28 um 17:41 schrieb Stefan de Konink:
>> On Sunday, February 28, 2016 5:33:12 PM CEST, Aleksei Valikov wrote:
>>> This API is a major victory for DB Open Data.
>> Nonsense. DB partners have access to this things for months now, and
>> having the same bugs.
>> These kind of releases are there to shut people up with: "Hey we are
>> open!! Look at our API!!" Because politicians have no context why these
>> kind of publications are done in such way that there is total control
>> over how data is reused.
> I expressed my feelings about that release in the promised blog post on
> Sunday, read it here in German: <
> https://okfn.de/blog/2016/02/offene-fahrplandaten-von-der-bahn/>
> Well, where shall I start. I feel like I'm playing a real-life
> hidden-markov-game, where I have to deduce what's going on behind the
> scenes of DB by carefully examining what's being done and said.
> Remember that we're talking about an entity that a) only a few years ago
> threatened to sue Michael Kreil for publishing their (already published)
> timetable information in another format; b) consists of a myriad of
> subsidiaries that don't even share data _with each other_ and in which c)
> every head of department appears (at least to me, as an outsider) to be
> something of their independent monarch, reigning as s*he sees to be fit.
> Right now we can observe the HAFAS-API being re-engineered to be a)
> legally sound, with an open license attached to it, and, b) a discussion
> being underways as what needs further to be done. GTFS was high on the list
> and from what I've gathered, the feed not being released as well was more
> an issue of time and red tape, not one of (lack of) good will.
> I _really_ wish that discussion would have happened before the release,
> because I can relate very well to the disappointment that has been flung
> around here and on Twitter. Had I not been at the workshop, I'd probably
> been spewing vile comments on Twitter all weekend long and been in a foul
> mood ever since.
> That said, keep in mind that – at least in my opinion – the big launch
> event with all the Schampus was mainly directed at the big-wigs _within_
> Deutsche Bahn, to commit them to finally opening up their goddamn data
> troves. It's a bit unfortunate that this grander scheme of things wasn't
> communicated to the community as a whole.
> I second the calls for a list of things to expect from transit providers.
> It has been ages since the first open transport manifesto, and right now
> would be the time to draw the lines – as has not at all been the case with,
> for instance, SNCFs “open” API that needs you to sign up and puts a cap on
> what you can request per day, if you want it for free.
> Now would also be the time to think about the opportunities and challenges
> to be had with real cross-european rail schedule data, be it in GTFS form
> or through an API.
> Because, just take a look at the issues Philipp Bock ran into with the
> EuroNight 23 Moscow-Berlin-Paris <
> https://github.com/pbock/fahrplan#timezone-support>. This beast runs
> 3169km, and while it “only” crosses two time zones (MSK/FET and CET), CET
> does daylight savings, while FET doesn't. That should bring tears of joy to
> everybody who works with this, and from what I know, GTFS does fuck all to
> help with this situation ;)
> regards,
> -stk
> _______________________________________________
> open-transport mailing list
> open-transport at lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/open-transport
> Unsubscribe: https://lists.okfn.org/mailman/options/open-transport
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/open-transport/attachments/20160301/ff453a9c/attachment-0002.html>

More information about the open-transport mailing list