Tagged: open transport data

Oooh Lambert

I remember the sixth of December 1997 as the day I got to know how to read a map. A holy man came into my house, or that’s what I believed according to the legend of Saint Nicholas, and dropped an atlas and a globe on the couch. That day, I learned the capitals of some countries you wouldn’t have heard of in a million years (probably you have now, thank you Geo Challenge) and most importantly, I learned how to interpret coordinates! I spun the globe around and where it stopped I had to look up the details in the atlas. What a joyful way to spend time without social media around, just yet.

We’re 10 years later. Google has just released Google Earth and to my great pleasure I had a much better globe and atlas in one single program. For old times’ sake I flung my globe, that was after all these years still standing next to me on my desk, and chose a random coordinate, put it in Google Earth and… guess what… it worked!

Today, 2011, I’m an open data enthusiast and so much more. I’m working on the iRail project. The project aims at creating a general webservice for public transport in Europe. At this moment it works for the Belgian railway company and we’re working on support for the Dutch railway company and Belgian bus- and subwaycompanies. It’s the latter that made me feel very insecure.

The result of 100 lines of code (maps.irail.be)

This site let’s you convert an address into coordinates. An incredible tool for location-based open data! In the end an end-user doesn’t want to query on coordinates, but on an address. Let’s turn this tool into a webservice right? We scraped the NMBS (Belgian railwaycompany) before so this will be easy! At least, that’s what I though this morning. Today, in my breaks from studying of course, I have spent my time figuring out what these X/Y-coordinates meant:

X: 65591.206
Y: 171629.285

As this site is hardly documented I started googling what they could mean. On a very Belgian-looking (this is not a compliment) website I’ve found documentation: check it out for yourself. Apparently for some reason, please someone tell me why, Belgium started to use its own “Lambert projection” which uses the Hayford1924 ellipsoid. Too complicated? Well, not yet… It seems that this Lambert 1972 projection didn’t do the trick anymore and everyone was in need for a better, Lambert 2005 projection. Which was a lot better because in 2008 they decided to change this projection into Lambert 2008, which was not that bad because if you wanted to use 2008 instead of 2005 you only had to add 499 000m to each coordinate. This is a good thing because now the Lambert 2008 projection uses the GRS80 ellipsoid. Get it? Me neither. In fact, it feels like filling out my tax bill for the first time all over again.

Of course this had some implications since software that supported this projection became confused. They didn’t know what kind of Lambert they implemented and as a result showed wrong locations (typically exactly 1km off: the 1972 – 2005 problem). In fact I’ve had a hard time today writing a function, because there were no ready-made functions out there and because apparently the math is not that easy. If anyone would stumble upon this problem, the PHP code for the Lambert 1972 projection can be found HERE. You hereby get my permission to steal this “tools” class and reuse it elsewhere (WTFPL).

Is there someone who can tell me more about why Belgium is so keen on the Lambert projection? It is used by a lot of Belgian instances and I figured there most be some benefits over the WGS84 standard, which we have all learned as a kid: longitude & latitude… Any comment welcome

– Pieter


Meer concreet: Vervotte beantwoordt iRail


Samenvatting antwoord Vervotte:

  1. De rechtstreekse aanleiding van de cease and desist brief was een klacht van een klant waarbij de klant een kwaliteitsprobleem met iRail expliciet en onterecht toeschreef aan de NMBS.
  2. De NMBS is verplicht om haar belangen inzake intellectuele rechten te verdedigen. Ik heb wel aan de NMBS gevraagd om zich  wat soepeler op te stellen, als het gaat over het ter beschikking stellen van databanken die gebruikt worden voor gratis consulteerbare, informatieve applicaties op het internet.
  3. De NMBS geeft er momenteel de voorkeur aan om in dialoog te treden en op zoek te gaan naar een minnelijke schikking. Dat impliceert natuurlijk onderling respect van de betrokken partijen.
  4. De NMBS heeft contacten gehad met enkele grote bedrijven waarmee strategische partnerschappen kunnen worden afgesloten. De NMBS zal de contacten tussen andere softwarebedrijven en iRail niet beletten, als de samenwerking gebeurt onder de  voorwaarden die tussen de NMBS en iRail of andere bedrijven kunnen worden afgesproken en gerespecteerd.
  5. Om de rezigers degelijk te informeren en om te beantwoorden aan de doelstelling van het beheerscontract gebruikt de NMBS de  software HAFAS, die ontwikkeld werd door dat gespecialiseerde bedrijf.

Mijn bedenkingen bij de antwoorden van minister Vervotte:

Continue reading

Belgian public transport company teams up with Google

News! De Lijn, a Flemish bus company, is about to share its data with Google. This means you will be able to look up your trip on Google Maps and Google will return you the possibility of going by public transport. It is a nice step in the right direction since they’re thinking about usability.

But let’s be pragmatic: if their customers want to find their way to the timetables as easy as possible, there is no way they can afford it to support all platforms and all ways of providing data. Therefor there is an easy solution: open it up! Let everyone use your data! Dozens of people, such as the iRail-team, can’t wait to get started on developing new apps and tools.

So yes: News, but not good nor bad news. We’re status quo. Except for some politicians who might think they delivered good work. Am I going to use it? Yes, I am! Everything beats the website of the company at this moment. Am I happy with it? No. If I could I would use an application which is optimised for social interaction and works really fast on my non-googlish phone.

– Pieter

Meeting the NMBS

After listening to Michaël Vanloubbeeck on their Internet strategy, he asked us straight away what we thought about their mobile web application. There are three points we thought worth mentioning:

  1. The number of clicks before you can see the right data is about 4 times too much. I only want to click once.
  2. There is no autocompletion on the station names.
  3. There is no button to switch destination and departure station

On top of that we noted that for big phones like most android, maemo/meego, bada and iphone phones, the site was too small. It was a great mobile website optimized for small screens and fast connections. We concluded that they, in comparison to iRail, have a totally different focus. Both approaches are needed however and we need to cooperate on this. The NMBS however responded that their mobile website is aimed to target all phones and anyone, which we can’t agree on. Discussion still open.

The second discussion is one that we started. We are still having difficulties with Stibbe. Stibbe is a respected law firm in Belgium who apparently has been hired by the NMBS to try to close us down. They’re quite aggressive in their approach by sending scary letters that our lawyer (if you read this, thanks for your free support, we appreciate it a lot!) seems to handle a lot  better than we do. They didn’t have a clue about that however. They ensured us however that they will *try* to stop these actions and let us work as we were doing. So the logical question for us is: “Can we hereby officially use your data?”; Yet this seemed to be more complicated as we thought. The real discussion had been started.
The first problem was that for the legal aspect of this we were talking to the wrong people. Personally we still think we are not  doing anything illegal and not one of their arguments makes that statement fall. As they are going to stop their lawyers however, we’re going to assume that there is no-one left to sue us and this has encouraged us to crank up our developing speed. The bad part about this legal story is that they didn’t guarantee us anything and we might get a reply about that matter in quite some time.

Their second problem was that the Internet and mobile devices are changing all the time. And there are so many mobile devices  they don’t know where to start developing. I didn’t really get why they use this against open data, but I guess it might be that they  thought open is just a fad like myspace which will disappear eventually. So this is where I protested heavily and said open data  would be a very good thing to do: they would provide a standard API for the data and provide a standard format. Everyone will be  able to make their app for their phone and their system. For free! Isn’t that something you should be happy with? No they said.  They wanted to be able to delete all the applications that didn’t fit their standard. So I started talking about free market where  people who use a bad app will eventually use another app. Discussion still open.

Some other interesting points:

  • They recognized that they were wrong by using lawyers in the first place without mailing us. They could have filed a bug-report if something did not meet their standards (which was a lot back then, we agreed)
  • They were already planning to provide their own API at some point in the future with a little data in it, to be used under certain conditions.
  • They are not (yet) convinced open data is the future. “It’s not because we’re a public company that our data should be public.”
  • Complaints about iRail that reach the nmbs will be, as good as possible, forwarded to our mailinglist.
  • They think iRail as external API provider is not an option. However, they did not explicitly ask us to stop (nor did they recommend us to continue). They’ll “quality check” iRail and provide us with feedback (probably just the mobile site, not our API)
  • We asked if Nokia could sponsor iRail without being sued by NMBS. That’s a question we expect an answer on in October. They didn’t understand however why Nokia wouldn’t come to NMBS for that instead.
  • They have partners with whom they share data. Partners include MIVB, De Lijn, Google, …
  • They promised they won’t block our IP’s (that’s not something we should be thankful for in fact. In our opinion it would be illegal for them to do so)

I would like to thank the NMBS for inviting us and I hope this will be one of many meetings. We sure did have a lot of arguments but I think that’s a positive thing. We are not satisfied with the outcome of this ffrst meeting, but rumour has it that Rome wasn’t built in a day as well.

Afterwards Yeri and I had a very good and inspiring chat. Keep informed because very soon we will cover you with awesomeness! (we’re serious about this)




-Pieter — Follow me on identi.ca

iRail meet-up: Report

Ironically we started a little later as planned due to unforeseen traffic-jams for Yeri and Christophe. Nevertheless  we did a great job and I want to start off by thanking all the participants and of course the hackerspace of Ghent.

From left to right: @Waza_Be, @pietercolpaert, @louisdedecker, @tuinslak, Arno, @maleadt, @coreation, @mathiasbaert - Missing: @hansbxl, @joristimmerman - Photo by Tuinslak (CC by-nc-sa)

Decided and discussed:

1. What should be in the API

We decided on 4 maincalls to the API (on picture, 4 black arrows to the right):

* Connections

How to get from a station to another with realtime information (delays, platformchanges, …), transits, stops, vehicle numbers, and so on. We also came up with the fact the we might want pricing information included, with a url to buy a ticket online, and whether tickets are still available or not (arrows on the left).

API 1.0 Brainstorm whiteboard at whitespace - Photo by Yeri Tiete (Tuinslak) (CC by-nc-sa)

* Lifeboard

Realtime information about arrival and departure of one specific station. A lifeboard contains the same information that you would see on the displays at a station.

* Stations

A list of all available stations in the API with geocoordinates. We might as well want to give each station a unique id. Someone suggested to use the already existing ID of Open Street Map. Personally I haven’t found any documentation about that yet. If someone can point me to that I would be very glad.

* Vehicle

Information about a specific vehicle. For instance the current geocoordinates of a train or plain, the stops a vehicle usually makes, … The most important thing we decided is the vehicle id. There is no such thing as an international ID that’s unique for 1 specific vehicle. Therefore we’re going to specify our international ID as:


For instance:


would be a valid ID for a Belgian NMBS intercity train.

2. Date/Time

The whiteboard about timestamps (Photo by Yeri Tiete (Tuinslak) - CC by-nc-sa)

An important discussion was how we will format the time returned for each connection. We found out that programming languages work with: ISO 8601 or with unixtime. So we will provide both in the way provided on the whiteboard.

3. Name of the project

BeTrains is the client of Christophe Versieux (@Waza_Be) and Jan Vansteenlandt (@coreation) for android. They have a lot of users and they started to use iRail as their content provider. BeTrains is a known name for android people.

On the other hand is iRail a well known name for people who are interested in open data. However the i in iRail is a little dangerous for abcdefghi™jklmnopqrstuvwxyz reasons. That’s why we will not name any broader projects after iRail. That being said project.iRail will be our mainplatform to develop. But clients will most preferably be called after BeTrains.

4. User-interfaces

Christophe Versieux on BeTrains

Christophe Versieux on BeTrains (Photo by Pieter Colpaert - CC by-sa)

Christophe Versieux gave a very good presentation about how to write a good user (/mobile) interface. We came up with some guidelines that are posted on project.iRail.be here:


And a page for user feedback


5. Legal actions

As usual, we discussed some legal matters as well. We comforted everyone that what we do is in our opinion 100% legal. We will give everyone an update 1 October. We’ll keep you posted.

6. Misc

You can reach our development API over here:

http://dev.irail.be/api/connections.php?from=Brugge&to=Brussel &lang=EN

This API version is not a stable version and should not be used for official releases!

If you want to contribute, our developer habitat is still at project.iRail.be.

– Pieter — follow me on identi.ca

P.S. – If you were at the meeting and I forgot to mention something, do not hesitate to contact me. I will include it asap

iRail meet-up – Friday 17 sept

On Friday the 17th of September we are meeting up with all people interested in open data to specify the iRail API. Whether you’re a graphical artist, a low-level coder, a mobile app developer, openness enthusiast, journalist, etc… you’re more than welcome.


We will meet up in the hackerspace of Ghent. The address of the location is:

Blekerijstraat 75 Gent, room 1.21

If you want to get there by public transport, the best way is to take the train to Gent Dampoort and walk from there (5 minute walk)

At the gate

When you arrive at the location you will find a closed white garage-door. If you’re unlucky and could not make it at 18:00 you can call me on +3248415542nine. We will open the gate again at 19:00, 20:00 and 21:00 or on ping.


– Gate opens each hour

18:15 – Welcome to the event. Explanation about the evening. This is the perfect moment for general questions.

19:15 – discussing the API specification on the whiteboard

20:15 – Talks:

  • How will we manage project.iRail.be as an open-source project (Pieter Colpaert)
  • Current legal situation (Yeri Tiete – @Tuinslak)
  • An example of a good user interface for iRail (Christophe Versieux – BeTrains – @Waza_be)

21:15 – Managed coding

  • Explanation on usage of github (Yeri)
  • Coding of the API with interested people (Pieter)
  • Coding of various clients with interested people (BeTrains with @coreation and @Waza_be, QT trains with Tim Besard, IPhone app with Ben Turner, Mobile site with Yeri…)

22:15 – Picture of all attendees

22:30 – Unmanaged coding

  • code whatever you want and stay until you want
  • talk to us about your specific ideas
  • have a good time

More links

Website of the hackerspace

Official event on project iRail

– Pieter – follow me on identi.ca

Creating an open transport API

This is also posted on the mailing list of iRail.be. It’s an update of what we’re doing and what we’re trying to achieve with the project.

Yeri Tiete started almost 2 years ago with only one goal in mind: A simple
mobile application that anyone could use to find information for his
train connection. As he was proud to have written an application that
snappy he informed the NMBS/SNCB with an e-mail. Their reply (after 2
years) however, was quite surprising.

After the letter of the NMBS/SNCB asking iRail.be to stop, the buzz
started. Instead of closing the iRail.be down he, after consideration
with his attorney Ywein Van den Brande, decided to put it back online and open
source it all. Apparently that was a good decision because else you
would not be reading this.

The Goals

For this project to succeed, we’d like to achieve 3 goals:

1. Mobile train schedules for all mobile devices by taking the KISS
(Keep It Short & Simple) principle into account. This was the first goal
and it has more or less been achieved by Yeri. With an average of ~120
users/day iRail.be is currently providing a good service.

The next 2 goals are not at all achieved yet. They were only added
recently, after the NMBS/SNCB letter.

2. Open transport data and an official API. Our webscraping API is only
a temporal solution and should disappear as soon as possible. The
NMBS/SNCB should make an *open-source* API theirselves and provide us
with *open* data: the trainschedules.

3. An international API specification. We want to be able to use the
same calls and get the same responses with the German or French railway
system, as with the Belgium one. We already have the SNCF guy on the
mailinglist, and we’re hoping for German people pretty soon too. All
other European countries should follow our example of course. Imagine
what this could mean for a client developer: implementing a system that
returns the fastest connection from Orange (France) to Berlin (=
ultimate goal)

As a secondary goal of course we will need a lot of awesome people that
use this API to create things we could never have dreamed of. For
instance we’ve heard of people writing a chat application that enables you to chat
with people in the same train. Someone else is writing an application
that will show live tables of a station on you mobile device, someone
else is using the API to make a subscribe to this train service (and if
it experiences delays, it will notify you in time), and so on.

I’m really excited about this project and I hope it has the right effect on the right people. Oh yes, and for now, enjoy using http://www.iRail.be.

– Pieter — Follow me on identi.ca

Related Links:

iRail.be mobile website

The current API specification wiki

The mailing-list anyone can join

iRail.be github source page

(This post is licensed CC By-Sa, like all other posts on this blog, for more information check the about page)