May I ask why the sessions expire so quickly on the DB website? That can be quite annoying—to say the least, for example when one wants to go back in the browser history or check on the status of a certain connection in case of strikes or severe weather.
I'm not on that very project, but my guess would be that sessions are not completely stateles on the server side so they have to have session timeouts to drop obsolete sessions. I'll ask when I meet someone from that project.
Could you explain why a railway operator might not want their data to be opened? After all, better availability of data might convince more people to use trains.
This is a difficult matter. I'm actually on the Open Data side (not the "dark force"), but let me play the devil's advocate here.
* What if the data will be used to convince people to use less trains? Busses and car sharing are now a huge competition. What if someone would take the data and represent it in a way very unfavourable for the long-distance trains? There are multiple ways to "tweak" the statistics without actually lying.
* DB is not a single entity but rather a complex network of smaller companies and departments within them. At the moment there's no Open Data directive from the top so they basically have to decide on their own. This has at least a few problems for department heads:
* responsibility - you can easily get your head off for a wrong data sharing decision;
* losing data as the asset - departments often use data they have as a leverage when negotiating with other departments and companies, it's a valuable assed;
* data ownage question - you normally don't have "pure" data, you have data coming from somewhere else which you enhance/process, so before sharing that you have to clear if you actually have the rights to. Having a few dozen "historically grown" data sources, this may be very difficult;
* have to pay to prepare the data for sharing. Like, convert gigabyte-sized Acces "databases" into something more usable, specifying interfaces and so on. This is a huge effort, and who pays for that?
* Next, there are a few political problems like "non-discrimination" EU directives. Every public stunt for DB Netz, for instance, may lead to a "discrimination" suite from some operator. So there's a risk of legal problems.
* DB gets a few billions a year from the state to maintain and improve the infrastructure (look up LuFV). What if some clever reporter will use the data and prove that DB could have invested and maintained better? And you're getting a few millions fine from the state/EBA?
The list goes on. For decision makers the risks and dangers are obvious but the benefits are not, or at least not yet. So I'm very glad about the rising "hackathon" movement here as it is a good way to show that there may be real and direct benefits. This may really help to persuade people.
Increasingly that data can be obtained using collections of interacting phones in a community-driven way using travelling data from Bahn users, a la Open Street Map. The spectre of this happening might nudge transport companies towards embracing a more open approach.
Just read the posting and have to say, I really would dig the Chrome extension - and having a lot of traveling colleagues here in Hamburg, they would too.
Also the app - this would really be a great app to have.
Adding national identifiers could be useful. "SMG" is St Margarets in London, "SMT" is St Margarets in Hertfordshire, and commuters using either probably know the code — it's exposed on official websites.
There is a field called sncf_id that includes SNCF-specific codes (and similar ones for other carriers); there could be a nationalrail_id field as well. Great suggestion! You totally should create an issue on GitHub.
(Disclaimer, here I speak for myself but work at Capitaine Train.)
Wow! I didn’t know about those ids, thank you. However it would be some work to match the stations.
What call the db_id is called IBNR as Internationaler Bahnhofs Nummer
I am on that list since a while :) We met at the Okfn-conf in Geneva.
I am waiting until we translate the blogpost and our page in English before talking about that on the list.
Pieter Colpaert alreday complained about uri/linked data ;)
Sorry, Tristram, I didn't mean to address this hint to you – I know you're on there already :D This was meant more as a general hint to anybody interested.
Instead, I had to do hack upon hack to match SNCF's station names (like say "Valence (France - toutes gares)") to OSM nodes, or failing that to city names, and in the end fix the remaining ones manually.
This is really nice, though the documentation is a bit lacking in parts (there's already a pull request to make things a bit nicer :)
For example, I can see a station is missing, but is there any way to find its UIC code (or other identifiers) so I can add an entry? It's not clear what `is_suggestable` actually means, so I wouldn't know what to input.
Also, while there are info:* columns for miscellaneous info, there doesn't seem to be multiple name:* columns for the localised station name (a lot of this data may already be in OpenStreetMap)?
Indeed the data is incomplete yet. Bear in mind that the data comes from a specific use on https://www.capitainetrain.com That is why many countries are poorly covered (yet! we plan to eventually cover whole Europe).
There is no magic to find the UIC code, sorry… Sometimes it is in OpenStreetMap, sometimes we get it from a rail operator… But it is not a required value, so you can add it with out the station.
`is_suggestable` means that the user can input the station on capitainetrain.com. Leave it false for now ;)
The idea behind the name vs. info is that name is the station as it is locally known.
Info adds any information extra information to help to find which station it is (that includes translations, “Central Station” for people not understanding „Hbf“, disambiguation between similar names…)
> Info adds any information extra information to help to find which station it is [translations, disambiguation]
These are two separate use cases, which should have their own structured fields. The current uses of info:* seem to be very free-form at the moment.
If I want to travel to Cologne Trade Fair, I should be able to start typing "colo" and find it, without knowing that it's called "Köln Messe" in German. Whereas the info:* fields should separately have useful info, e.g. "Trains transfer from Cologne Main Station every few minutes."
Much like on OpenStreetMap, doing a name search should match against all name:* fields. Info fields should be for info.
Some station names are incorrect. For example, the file lists a UK station named "Yeovil", while there is no such station -- it should probably be "Yeovil Junction".
While some stations in the bigger cities and in Vienna are included, I could not find any stations in lower austria.
They are all listed in OpenStreetMap, and the inofficial ÖBB API (kinda documented here: https://github.com/internetztube/oebb-api) could be used to get the correct names. :)
For now Capitaine Train the only carriers we are connected to that stop in Austrian stations are Deutsche Bahn and Trenitalia. Only those stations are in the database.
Once we connect to ÖBB and Westbahn, we will need a more important cover.
Nice project idea: collect gps data from cell-phone users that are on a train, and based on this data (lots of users moving at the same speed across known tracks), get an overview of where trains are located.
There may be no need soon - most EU countries have very accurate data that theyve traditionally kept to themselves, but are now being mandated to make available. Its very slow, but getting there:
Not using GPS data (which I believe is a flawed idea, too much battery used for the community) but using the API given by the providers, raildar (http://raildar.fr/#lat=46.810&lng=6.880&zoom=6) is already displaying trains in real time with their delay.
That's neat. The train from Trier to Homburg just passed by so I checked its accuracy, and it was showing it one kilometre ahead of the actual train position, then the indicator moved backwards to match the actual location. I guess this is because of the interpolation you do as it's not real time data yet.
I'm a great fan of your (DB's) work and use your apps/website daily. Keep up the good work!
There are a few of ongoing projects which will display the precise real data delivered by trains in near-real-time. But I'm not quite sure, which will be public.
You'd have to convince the users to allow you to track their position though. It's easier to install a GPS module (or similar) onto a train, and publish it in a public API.
(I work at Capitaine Train who published this data)
It is true. This database has not the pretension to have all the stations in Europe. It has all the stations where we can sell tickets to.
As we connect to more carriers, the database will expand. But it is a long process.
I'd be glad if you drop me a message so that we could establish a contact. xing.to/va or valikov-at-gmx.net (Disclaimer: working for the Deutsche Bahn.)
Disclaimer: I'm working for the Deutsche Bahn (German Railways) and try do some persuasion work towards Open Data here internally.