kv55 en pubsub

[John Sirach]

Hai,

 

Via google search naar open source OV implementaties ben ik bij openov terechtgekomen, erg goed initiatief, en ik zal het redelijk op de voet volgen.

 

Korte uitleg, voor thuis bezig met een redelijk groot domotica project met een centrale air app, en één onderdeel is snel kunnen bekijken wanneer de bus vertrekt bij de bushalte om de hoek, en hoe laat de treinen vertrekken op het station.

de bustijden haal ik binnen via kv55, en NS info via pub-sub (net afgerond).

 

Ik heb een paar vragen, ik las dat er een planning was om meer informatie via pub-sub aan te bieden dan alleen de spoorwegen, kun je daar enige info over geven zoals ongeveer wanneer?

want zolang dat er dan niet is, is mijn volgende vraag, rond de hoeveel requests is redelijk om per uur (24/7) naar twee kv55 resources op te vragen (wetende dat bij jullie de info op 1 minuut wordt gecached)?

 

Groeten,

John.

 

[Stefan de Konink]

On 23-03-12 00:23, John Sirach wrote:
> Ik heb een paar vragen, ik las dat er een planning was om meer
> informatie via pub-sub aan te bieden dan alleen de spoorwegen, kun je
> daar enige info over geven zoals ongeveer wanneer?

Ik heb vannacht de laatste hand gelegd aan het eerste functionele
gedeelte van de transitpubsub. Een soort NS-API pubsub, maar dan meer
gericht op internationeel gebruik en open standaarden. Momenteel lag de
focus even op bussen en het afhandelen van de verschillende vervoerders
datastromen om daarbij de statische data (dienstregeling) met actuele
data te integreren.

Bij bus, tram & metro krijgen we gewoon veel meer informatie dan de NS
beschikbaar stelt, en om eerlijk te zijn de nsapi pubsub, voldoet nog
wel even. Komende week zal de boel wel paralel te testen zijn.

> want zolang dat er dan niet is, is mijn volgende vraag, rond de hoeveel
> requests is redelijk om per uur (24/7) naar twee kv55 resources op te
> vragen (wetende dat bij jullie de info op 1 minuut wordt gecached)?

Als je in een gebied zit waar nog geen KV78turbo is heeft het absoluut
geen nut om vaker dan 1x per minuut te pollen per halte.

...en uiteraard snap ik je vraag, want met XMPP zou je alleen de
wijzigingen krijgen ;)

Stefan

[John Sirach]

zou wel gaaf zijn als die transit pub beschikbaar komt. Het gaat er hier dan om regio haaglanden en dan toevallig ook puur een bushalte waar veolia bussen stoppen.

Ik heb trouwens wel gezien dat de trams van HTM (vanwege 9292ov?) niet beschikbaar zijn en dat KV78turbo niet voor haaglanden geldt?

 

Ik was in ieder geval absoluut niet van plan om vaker dan 1x per minuut te pollen, maar mocht het zo zijn dat er wordt verwacht niet vaker dan om de x aantal minuten requests te doen, zal dat uiteraard gehonoreerd worden. De app die hier draait/gaat draaien kan op een gegeven moment "events" uitsturen naar mobieltjes hier wanneer een bus "(te vroeg)-2 minuten" zou rijden.

 

Lang leve het aanleveren van gestandaardiseerde data, heel veel succes ;)

 

John.

[Stefan de Konink]

On 23-03-12 01:15, John Sirach wrote:
> zou wel gaaf zijn als die transit pub beschikbaar komt. Het gaat er hier
> dan om regio haaglanden en dan toevallig ook puur een bushalte waar
> veolia bussen stoppen.

Nouja de twee belangrijkste bushaltes van Nederland liggen in dat
gebied, dus reken er op dat ik zal praten als brugman om de data voor
mijn deur langs ook in KV78turbo te krijgen :)

> Ik heb trouwens wel gezien dat de trams van HTM (vanwege 9292ov?) niet
> beschikbaar zijn en dat KV78turbo niet voor haaglanden geldt?

Iets genuanceerder. KV78turbo is echt een platform dat we goed moeten
doortesten. De keuze voor GVB is dan snel gemaakt, juist omdat ze zelf
ook input geven. Voorbeeldje: ontvangen van alle statische planning
berichten is momenteel iets waar dingen mis gaan, dus gaat handmatig
overnieuw, nog niet duurzaam dus. Eerst even verder debuggen voordat er
uitbreiding komt en het dan 'toch niet zo goed werkt'.

HTM rail ligt genuanceerder, HTM draait (als ik me goed heb laten
informeren) op SIRI VM. In Nederland hebben we afgesproken dat we KV6
gebruiken om actuele data uit te wisselen. Het is dus puur een
technische aangelegenheid dat die data er nog niet is, heb begrepen dat
er wel wat moet gaan gebeuren in die richting.

> Ik was in ieder geval absoluut niet van plan om vaker dan 1x per minuut
> te pollen, maar mocht het zo zijn dat er wordt verwacht niet vaker dan
> om de x aantal minuten requests te doen, zal dat uiteraard gehonoreerd
> worden.

Met de huidige KV55 gaat er gelukkig niet meer zoveel mis, vroeger was
het echt wachten op elkaar.

> De app die hier draait/gaat draaien kan op een gegeven moment
> "events" uitsturen naar mobieltjes hier wanneer een bus "(te vroeg)-2
> minuten" zou rijden.
> Lang leve het aanleveren van gestandaardiseerde data, heel veel succes ;)

Laat je het ook even aan iedereen weten dat je een app hebt? Die paarse
balk staat er niet voor niets op de website ;)

Stefan

[John Sirach]

Nouja de twee belangrijkste bushaltes van Nederland liggen in dat
gebied, dus reken er op dat ik zal praten als brugman om de data voor
mijn deur langs ook in KV78turbo te krijgen :)

Laat dat dan hopelijk toevallig in delft zijn ;).

 

 

Iets genuanceerder. KV78turbo is echt een platform dat we goed moeten
doortesten. De keuze voor GVB is dan snel gemaakt, juist omdat ze zelf
ook input geven. Voorbeeldje: ontvangen van alle statische planning
berichten is momenteel iets waar dingen mis gaan, dus gaat handmatig
overnieuw, nog niet duurzaam dus. Eerst even verder debuggen voordat er
uitbreiding komt en het dan 'toch niet zo goed werkt'.

Duidelijk punt. Ik nam aan dat er meer informatie in handen zou kunnen zijn. Maar ja, dit is eigenlijk wel erg logisch zo.

 

 

HTM rail ligt genuanceerder, HTM draait (als ik me goed heb laten
informeren) op SIRI VM. In Nederland hebben we afgesproken dat we KV6
gebruiken om actuele data uit te wisselen. Het is dus puur een
technische aangelegenheid dat die data er nog niet is, heb begrepen dat
er wel wat moet gaan gebeuren in die richting.

Dan is dit dus gewoonweg afwachten :).

 

 

Met de huidige KV55 gaat er gelukkig niet meer zoveel mis, vroeger was
het echt wachten op elkaar.

Dan houdt ik iig de max op 1 minuut voor de beide haltes op zich zijn (24*60)*2 haltes op zich niet veel, maar je weet maar nooit natuurlijk.

 

 

 

> De app die hier draait/gaat draaien kan op een gegeven moment
> "events" uitsturen naar mobieltjes hier wanneer een bus "(te vroeg)-2
> minuten" zou rijden.
> Lang leve het aanleveren van gestandaardiseerde data, heel veel succes ;)

Laat je het ook even aan iedereen weten dat je een app hebt? Die paarse
balk staat er niet voor niets op de website ;)

 

De app die ik hier heb draaien (en nu nog continu in ontwikkeling is). is bij lange na nog niet rijp om de open source wereld in te gooien, ik gebruik deze OV info dus in een domotica app en alles wat ik heb is hardcoded naar m'n XBMC/HD recorder ed, m'n sensoren en de mobiele "client" apps die ook terug babbelen met de centrale domotica app.

Het is dus op dit moment nog echt voor persoonlijk gebruik.

 

Versie twee van m'n app(s) liggen al wel al in de roadmap en dan vooral om hier een community versie van te maken naast m'n persoonlijke versie, mischien ondanks dat deze dan voor zo een 5% met openov te maken heeft, mischien wel leuk om te vermelden ja.

 

John.

[Stefan de Konink]

On 23-03-12 01:45, John Sirach wrote:
> Nouja de twee belangrijkste bushaltes van Nederland liggen in dat
> gebied, dus reken er op dat ik zal praten als brugman om de data voor
> mijn deur langs ook in KV78turbo te krijgen :)
>
> Laat dat dan hopelijk toevallig in delft zijn ;).

Leidschendam, maar je hebt geluk, ik Delft kom ik ook nog wel eens ;)

> Dan houdt ik iig de max op 1 minuut voor de beide haltes op zich zijn
> (24*60)*2 haltes op zich niet veel, maar je weet maar nooit natuurlijk.

Met 62seconden zit je denk ik het veiligst ook wat betreft 'expire' tijd.

> Het is dus op dit moment nog echt voor persoonlijk gebruik.
> Versie twee van m'n app(s) liggen al wel al in de roadmap en dan vooral
> om hier een community versie van te maken naast m'n persoonlijke versie,
> mischien ondanks dat deze dan voor zo een 5% met openov te maken heeft,
> mischien wel leuk om te vermelden ja.

Ben benieuwd naar de foto's of een blog ;)

Stefan

[John Sirach]

> Met 62seconden zit je denk ik het veiligst ook wat betreft 'expire' tijd.

Dan zal ik de 62 seconden aanhouden, ik heb trouwens verder niet
gekeken, maar stuur je ook expire dates mee in de headers? Dat zou het
voor mij in ieder geval makkelijker maken om rekening te houden met
expires.

> Ben benieuwd naar de foto's of een blog ;)
>

Op dit moment alleen ff snel op een facebook account, flinke drukte
houdt me er wat van tegen om echt een blog bij te kunnen houden, mocht
die er komen zal ik het wel laten weten.

John.

[Stefan de Konink]

On 23-03-12 12:09, John Sirach wrote:
> Dan zal ik de 62 seconden aanhouden, ik heb trouwens verder niet
> gekeken, maar stuur je ook expire dates mee in de headers? Dat zou het
> voor mij in ieder geval makkelijker maken om rekening te houden met
> expires.

Ze staan er in ja.

Stefan

[John Sirach]

hmm... my bad..

 

Toch nog een vraag over die NS pub-sub. Aangezien het de bedoeling is om dus alleen de wijzigingen binnen te krijgen:

 

Ik zie die retract nodes verschijnen, en daarna krijg ik een complete lijst binnen. Prima voor het ontvangen natuurlijk van de eerste initiele data uiteraard. Maar bij daaropvolgende gegevens die ik binnen krijg zijn zijn dat natuurlijk de retract nodes, maar wederom de complete lijst van ritten die op dat moment van toepassing zijn en niet de ritten die zijn toegevoegd aan de xml of alleen gewijzigd.

 

Klopt het bovenstaande en gaat dat mischien nog veranderd worden of is dit niet mogelijk? Want als we iedere keer de nieuwe lijst binnen lijken mij de retract nodes overbodig?

 

John.

[Stefan de Konink]

On 23-03-12 12:39, John Sirach wrote:
> Ik zie die retract nodes verschijnen, en daarna krijg ik een complete
> lijst binnen. Prima voor het ontvangen natuurlijk van de eerste initiele
> data uiteraard. Maar bij daaropvolgende gegevens die ik binnen krijg
> zijn zijn dat natuurlijk de retract nodes, maar wederom de complete
> lijst van ritten die op dat moment van toepassing zijn en niet de ritten
> die zijn toegevoegd aan de xml of alleen gewijzigd.

Ik zal er even naar kijken. Ik ging er vanuit de de deduplicatie gewoon
goed werkte.

Stefan

[John Sirach]

Op vrijdag 23 maart 2012 12:55:27 UTC+1 schreef Stefan de Konink het volgende:

Mischien dat ik het niet goed uitlegde

 

Het gaat om node: "stations/dt/avt"

en om user "roomframe at jabber org"

Ik zie mijzelf als het goed is eenmalig een presence sturen.

 

 

De retracted xmlnodes welke ik binnen krijg worden netjes uit de xml lijst gehaald welke ik daarna binnenkrijg:

 

initiele xml: item id: station_dt_avt_2249

 

daarna een retract xml met: id=station_dt_avt_2249

Deze verdwijnd ook netjes, maar direct daarna krijg ik de volledige zeg maar initiele xml binnen welke niet meer het item id station_dt_avt_2249 bevat.

 

Zou ik dan niet alleen de retract binnen moeten krijgen als er verder niks is veranderd?

 

Groeten,

John.