Tagged: iRail

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

Advertisement

Killing dead time

Social media is not about losing a lot of time by being social instead. It’s about being productive in the dead-time-continuum. Let me explain…

If I were to become an autobiographist, «killing dead time» certainly would rank high in a list to qualify for a good title. Not that my life is that interesting – although describing the life of the people in it would be an interesting perspective – but it is true however that my life is filled with time that politely asks to be killed.

I used to love walking. I live in Ghent and walking from one side of town to the other is something I preferred rather than riding a bike. Why? If you would have asked some weeks ago I would have answered: “because I’m too lazy to maintain a bike”. But the main reason lies elsewhere. Being on the road gives you the great opportunity to overthink things. For instance if I go to a meeting on foot I know that when I enter the room I will be better prepared. Taking thought-consuming types of transport, such as a bike or a car, will make you lose your X minutes of thinking-time.

It turns out that I’m not the only one who has dead time – dead time being the time you are not doing your maintask -. A good friend of mine told me he always uses the toilet for approximately 16 minutes. That’s exactly the time he needs to finish this mobile phone game, extending his visit but making it a lot more fun. Of course we can recite an endless list – such as queuing at the grocerystore, waiting for a bus or plane or train, sitting on a bus or plane or train… – but that’s something every person can fill out for him- or herself.

When I discussed this idea with my father, people having too much dead time, we were thinking this could actually have a positive side-effect: people may actually do productive things. As he works as a researching in computer assisted language learning at the university of Antwerp he figured this might be exactly why language learning apps are very important. When are you going to learn a language? Not when you’re at your computer working for that customer whose product should have been ready yesterday, but when you’re at the airport waiting for the plane, or even on the plane, on your way to the next customer.


Seems like we weren’t the first to come up with this idea. Although our idea will get better implementations 😉

I think this is the reason for the success of social media. If you would look up the geolocation of your friends’ tweets (twitter messages) I bet you would be able to find out the exact location of the bathroom in their building. This is also the reason why I like the iRail project a lot: apart from planning your trip, iRail will also try to make your commuting as fun and interesting as possible: providing real-time social media updates from your train, letting your friends know you’re on this train or playing augmented reality games such as http://www.chromaroma.com/.

It may be interesting to know that I just got of my bus, which I prefer taking over walking home now. During the trip I’ve catched up on twitter, I have read my email and wrote this blogpost.

-Pieter

No more iRail on BonSansNom

A lot of my latest posts on BonSansNom were about iRail. Because each community member of iRail has his own blog and we want every iRail community statement in one place, we started http://blog.iRail.be. So this is my last post on here about iRail. If you want to stay informed about latest development, please add this blog to your RSS reader.

– Pieter

Meer concreet: Vervotte beantwoordt iRail

http://www.dekamer.be/doc/CCRI/pdf/53/ic039.pdf

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

Transport data roaming

When I’m writing code I’m quite regularly distracted by what-ifs… For instance: what if I’m on a train towards Spain and I boarded in Belgium. As I have a smartphone with an application installed (let’s call it BeTrains for iRail) which gives me real-time information on my trajectory, I don’t want BeTrains to be useless once I cross the border. BeTrains should automatically switch to the trainsystem of that country.

This seems like a pretty good and easy-done concept. However we want to do it the right way: we don’t want other application developers to deal with the same hassle of implementing each country for which it wants to work for. We don’t even want to think about that. Every country should have the same standard for bringing its data to the public. To do this for the EU is a nice start since in Europe transport data is open by law.

We (the iRail team) are however not the right people to make this standard. Our momentum is too small for Europe. Who in Croatia is ever going to think they should be conform to the Belgian system? We need a European open standard for real-time public transport data. We can create a consortium that sets these standards as today everyone is opening its data in their own random way (standards should exist for all open data, whether it’s weather information or geolocation data).

Situation today for standardisation of public transport data

Talking about open data today is more and more accepted. For instance I came across this video about a presentation by the Massachusetts Department of Transportation:

This is an interesting evolution but if we look at their API response itself it looks something like this:

<Root>
<Red Line=”Red”>
<Trip>157</Trip>
<PlatformKey>RQUAS</PlatformKey>
<InformationType>Arrived</InformationType>
<Time>2010-10-07T08:02:42.302875-04:00</Time>
<TimeRemaining>-00:00:18</TimeRemaining>
<Revenue>Revenue</Revenue>
<Route>0</Route>
</Red>
…

</Root>

Clearly this kind of XML would not do the trick for real-time public transport data in Europe. We have some other companies who release their data like this as well, each company in another format, and slightly different information.

To make this «transport data roaming» work, we need someone to tell us what to implement. Just for now we’re telling people that we need this and we hope someone will come up with something we can implement. As at this moment we have an API we’re using this non-standard one we specified ourselves.

– Pieter — @pietercolpaert

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

Yeri

Yeri

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

CountryCode.Company.InternalCompanyID

For instance:

Be.NMBS.IC2345

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:

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

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.

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