[iRail] APIv1.1

[Yeri Tiete]

In short, we want any data that's supposed to be public.
Longer: mainly route planning data, time tables, and, where possible, location of vehicles. 

This can be done in several ways, preferably implementing our API (but what are the odds), but we can also act as 'translator' (converting their API/xml/... to our standard), or, worst case, static data dumps. 

So far, we have not managed to get an agreement with MIVB (and were unable to go talk to them in person). 

On the other hand, we received test data of De Lijn, and hope to get access to their real data in a couple of days/weeks. 

--
Kind regards,
Yeri Tiete
yeri at tiete.be
www.yeri.be
+32 (0)474/61.01.39

On 06 Apr 2011, at 22:20, Bart De Gruyter wrote:

> Do we need to ask Els Ampe to try to get things movin' in the right direction at the mivb or are things not yet too bad? If you want I can give Els Ampe a call... 
> But before calling her we should decide what we want to obtain from the MIVB and from her.
> 
> 
> On 2011-06-04 22:18, Christophe Versieux wrote:
>> 
>> Dear mailing list, 
>> 
>> As you know , the MIVB didn't want to share his data with us and I am therefore planning to add these informations to my current application.
>> 
>> I think that feature may start a bigger war than with the NMBS. They seem to be faster to react, and I think eMich will see us a threat for his application (eMich, if you are on the mailing list, feel free to send us your opinion).
>> 
>> I would like to have your opinion on this point, should we begin to code applications or is it time to think a little bit before, and maybe try to contact them?
>> 
>> Yeri, Pieter, I was not there at the meeting you had with their staff, so I don't know their feelings for us.
>> 
>> Kind regards
>> 
>> Christophe
>> 
>> 
>>> <compose-unknown-contact.jpg>	Pieter Colpaert
>>> 8 mars 2011 19:44
>>> 
>>> Dear Communitah,
>>> 
>>> I have been writing code; In fact I've rewritten the entire stack behind
>>> the iRail API. The code now is extensible for inputs (can handle
>>> different companies) and is extensible for outputs (you can add your own
>>> outputmethod in no time.). Supported output methods at this time: json,
>>> jsonp and xml. Supported inputs are: NMBS and I'm working on MIVB. De
>>> Lijn is coming soon as well.
>>> 
>>> The new API code needs to be tested on http://dev.api.irail.be
>>> 
>>> PLEASE TEST YOUR APPS ON THIS API AND FILL IN THIS DOODLE:
>>> http://www.doodle.com/3bschxxv9z6k9vp3
>>> 
>>> Changelog:
>>> ----------
>>> 
>>> * add «&system=company» to your request to get the API responses for
>>> other companies. Default remains NMBS (STIB won't work at this moment,
>>> you'll have to use the Flemish name MIVB. If you don't like this, feel
>>> free to hack this in)
>>> 
>>> * MIVB status: liveboard and stations kind of work
>>> 
>>> * the liveboard call for the NMBS will return the information for the
>>> next hour. This was not like this by default until now.
>>> 
>>> Additions to the json:
>>> * stationinfo: in each call this will contain more information about a
>>> station
>>> * platforminfo: more information about the station
>>> * the Liveboard bug if only 1 train arriving for json has been fixed
>>> * the array bug in json has been fixed
>>> 
>>> Next steps:
>>> * End of the week I want to see this new API code go public
>>> * After next week APIv1.1 will be frozen and will get the "stable" flag
>>> * I'll start coding APIv2.0 and ask feedback on specification
>>> * MIVB will get coded in meantime
>>> 
>>> Pieter
>> 
>> 
>> _______________________________________________
>> iRail mailing list
>> iRail at list.irail.be
>> http://lists.rootspirit.com/mailman/listinfo/irail
> 
> _______________________________________________
> iRail mailing list
> iRail at list.irail.be
> http://lists.rootspirit.com/mailman/listinfo/irail

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/irail/attachments/20110407/75eb1f1d/attachment-0003.html>