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

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.

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).

* 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:

CountryCode.Company.InternalCompanyID

For instance:

Be.NMBS.IC2345

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

2. Date/Time

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 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:

http://project.irail.be/cgi-bin/trac.fcgi/wiki/UserInterfaceGuidelines

And a page for user feedback

http://project.irail.be/cgi-bin/trac.fcgi/wiki/UserFeedback

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

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.

Where?

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.

Program

- 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