|Version 22 (modified by Greet, 23 months ago) (diff)|
Date & Time
- 17 Sept 2010
- Christophe Versieux
- Pieter Colpaert
- Louis De Decker
- Yeri Tiete
- Tim Besard
- Jan Vansteenlandt
- Mathias Baert
- Hans F.
- Joris Timmerman
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):
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).
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.
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.
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.
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.
Christophe Versieux gave a very good presentation about how to write a good user (/mobile) interface. We came up with some guidelines.
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.
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.