KV78Turbo beschikbaar om te testen
Stefan de Konink
Niets te doen vanavond? En wil je graag wat meer dan KV55 zien? Alle
data van het GVB is beschikbaar via KV78Turbo. De data is gelicenseerd
onder de "Utrecht Voorwaarden" wat weer betekent dat je er alleen
reisinformatie van mag maken.
<http://openov.nl/license/GOVI-1.0-TravelInfo>
KV55 kon al 1 halte tegelijkertijd opvragen, nu krijg je data in JSON.
<http://openov.nl:5078/tpc/090861>
KV78turbo kan meer dan 1 halte opvragen:
<http://openov.nl:5078/tpc/090861,020862>
KV78turbo kan vertellen van welke haltes er uberhaupt informatie is:
KV78turbo kan ook op lijn niveau kijken naar haltes, beschikbare lijnen:
En de locatie van een bus gegeven de lijn:
<http://openov.nl:5078/line/GVB_65>
Je ziet in deze output ook al een ritidentificatie terug, alle ritten
uit het systeem:
<http://openov.nl:5078/journey>
En kijken naar alle haltes die nog worden aangedaan:
<http://openov.nl:5078/journey/GVB_2012-03-10_25_200>
Omdat alles nu in test draait, zowel de aanlevering als het
bevraagsysteem zijn dit niet de definitieve URLs, maar kan het kwa
functionaliteit alleen beter worden.
Kijken naar de code? (En meehelpen...)
<https://github.com/StichtingOpenGeo/Koppelvlakken/tree/master/kv78turbo>
Losse eindjes? De TargetArrivalTime, TargetDepartureTime en
PublicLineNumber zitten nog niet in de output. Daarvoor moet wat
koppelvlak 7 verwerking gedaan worden.
Stefan
Teuniz
Door een bericht op Webwereld raakte ik geïnteresseerd in jullie werk.
Ik las dat GVB realtime informatie geeft, en dan kun je natuurlijk
leuke nieuwe dingen doen.
Ik vroeg me af in hoeverre bovenstaande api nu definitief is? Of is
het in Bèta fase?
Groet,
Teunis
Stefan de Konink
On 15-03-12 16:51, Teuniz wrote:
> Door een bericht op Webwereld raakte ik ge�nteresseerd in jullie werk.
> Ik las dat GVB realtime informatie geeft, en dan kun je natuurlijk
> leuke nieuwe dingen doen.
>
> Ik vroeg me af in hoeverre bovenstaande api nu definitief is? Of is
> het in B�ta fase?
Zowel het formaat als locatie is nog niet definitief.
De locatie gaat worden: http://kv78.openov.nl/json/ voor de json ingang.
Aan het formaat worden nog een aantal attributen toegevoegd die uit KV7
komen. De complete planning van het GVB zal vannacht worden ververst
(opnieuw opgestuurd door GOVI) en compleet worden gemaakt. We staan ook
open voor semantiek suggesties om het een en andere effcienter over te
sturen. Zeker bij complete vertrekstaten kan dat een (enorme) winst
opleveren.
Omdat we een ZeroMQ PubSub gebruiken die alle berichten van GOVI
doorstuurt naar de losse componenten kunnen we in tegenstelling tot KV55
wel een los beta platform draaien om op te ontwikkelen.
Stefan
Teuniz
Op donderdag 15 maart 2012 17:09:46 UTC+1 schreef Stefan de Konink het volgende:
Goeiemiddag,
On 15-03-12 16:51, Teuniz wrote:
> Door een bericht op Webwereld raakte ik ge�nteresseerd in jullie werk.
> Ik las dat GVB realtime informatie geeft, en dan kun je natuurlijk
> leuke nieuwe dingen doen.
>
> Ik vroeg me af in hoeverre bovenstaande api nu definitief is? Of is
> het in B�ta fase?
Stefan de Konink
> Bedankt voor de snelle reactie. Weten waar de bus is waar je op wacht, dat
> alleen is al gaaf.
Ambitie is natuurlijk dat iedereen straks z'n realtime routeplanner in z'n
broekzak heeft ;)
> Ik krijg geen resultaat op /journey. Rijdt het GVB vandaag niet, of is de
> api even niet beschikbaar? ;)
"Gelukkig" blijkt maar weer dat de API compleet los gekoppeld is van het
ontvangt gedeelte. Vanmorgen heeft GOVI planning pakketten gestuurd. Daar
gingen een aantal pakketten van fout, reden onbekend. Om 05:21:57 werd het
laatste KV8 pakket succesvol gestuurd en daarna zag ik aan onze kant
alleen nog timeouts. Nu zijn waarschijnlijk de KV7 fouten de oorzaak van
het niet verder gaan.
Als je hier kijkt zie je ook direct waar het probleem was:
<http://kv7.openov.nl/KV7planning/>
Inmiddels doet 'Journeys' het weer :)
Stefan
Stefan de Konink
> Inmiddels doet 'Journeys' het weer :)
Iets te voorbarig.
Er zit oude data in... zie ook voor actuele statistiekjes:
<http://openov.nl/stats.svg>
Stefan
Teuniz
Op vrijdag 16 maart 2012 12:43:25 UTC+1 schreef Stefan de Konink het volgende:
Stefan de Konink
> Hij lijkt nu half te werken. Ik kreeg even beeld in de kv78demo, maar hij
> update niet regelmatig en is nu weer leeg.
Concreet wat er gebeurt:
Er gaan tijden en posities in, en in KV78 worden de posities alleen
gebruikt. Iedere 120s wordt de cache van informatie geleegd op basis van
de tijden in de database. Dus daarom kan een tijd van 6 uur (die nu pas
verstuurt is door GOVI) er 2 minuten staan en na de flush weer een lege
lijn geven.
...we zouden natuurlijk ook direct de onzin resultaten kunnen filteren van
aankomsttijden die in het verleden liggen.
Stefan
Teuniz
Op vrijdag 16 maart 2012 13:20:18 UTC+1 schreef Stefan de Konink het volgende:
Stefan de Konink
> Als ik het goed begrijp is de info die binnenkomt (van GOVI?) niet altijd
> compleet, maar wordt de gehele cache hier wel mee overschreven. Toch?
Concreet hebben we te maken met:
/KV7planning = geplande informatie
/KV7kalender = gebruik op dag deze geplande informatie
/KV8 = actuele data van uit bus, tram en metro
De API die nu naar buiten werkt 'bouwt' alle informatie zelf op, dus op
basis van waarnemingen heb je 'opeens' het hele netwerk van het GVB. De
cache zorgt er voor dat specifieke waarnemingen worden gewist, maar op dat
moment blijft de structuur van het netwerk nog wel bestaan. Immers: je
weet nu dat lijn 1 via straat X en straat Y gaat.
Omdat je ook wil weten wat nu eigenlijk de vertraging is, heb je statische
data nodig die zegt: eigenlijk had *die specifieke bus* zolaat hier moeten
zijn.
> Zou je niet alleen een update kunnen van op informatie die gewijzigd is?ￜ
Als ontwikkelaar of wij als openOV?
Diffjes sturen implicieert enige synchronisatie, en dat kan natuurlijk
best op best effort werken. Alleen het doorsturen van een 'key' en
eventueel het verschil met de statische data. Maar dit is wel een
optimalisatie stap, als je hier ideeen over hebt, we horen ze graag.
> Een app developer kan aan de hand van de timestamp wel zien of hij met
> verouderde informatie te maken heeft. Als de informatie oud is, kan de app
> nog wel een voorspelling doen over waar de bus zich nu bevindt.
Je krijgt in principe alle data van alle haltes op de route, gegeven de
situatie nu. Dus je hoeft zelf niets te voorspellen (makkelijk he).
> Ik ben trouwens alleen nog maar aan het oriï¿œnteren op wat er allemaal
> beschikbaar is hoor. Ik heb nog niets concreets geprogrammeerd en weet ook
> niet of dat er van gaat komen.
Ga vooral door met orienteren, houdt iedereen scherp.
Stefan
Carl Mangold
Stefan de Konink
> Ik ben een iPhone app aan het bouwen op basis van
> deï¿œhttp://openov.nl:5078/line/GVB_1_1 (en andere lijnen) json. Maar ik krijg
> ineens geen actuele informatie meer door. Enig idee hoe dat komt?
Ik denk dat er wat mis gaat bij aanlevering. Maar ga even zoeken.
> Verder zou ik de app graag liever vandaag dan morgen richting Apple's
> AppStore sturen. Maar is de data op bovenstaande url daar eingenlijk wel
> betrouwbaar genoeg beschikbaar voor?
Nee, de bovenstaande URL is echt beta. Totdat het op kv78.openov.nl draait
niet voor productie doeleinden gebruiken.
Stefan
Herrie
het HP/Palm webOS platform (HTML en JS). Ik loop alleen een beetje
vast met de JSON die terugkomt vanuit de KV78.
Heeft iemand een idee/suggesties hoe ik hier fatsoenlijk mee om kan
gaan in Javascript?
Stefan de Konink
> Ik ben nieuw hier en probeer op dit moment een App te schrijven voor
> het HP/Palm webOS platform (HTML en JS). Ik loop alleen een beetje
> vast met de JSON die terugkomt vanuit de KV78.
> Heeft iemand een idee/suggesties hoe ik hier fatsoenlijk mee om kan
> gaan in Javascript?
<http://openov.nl/kv78demo/>
Stefan
Herrie
dan wellicht wat beter werkt :)
Ik ga daar eens mee aan de slag :)
Herrie
hetgeen het erg lastig maakt voor mij om er mee te werken (kan ook aan
mij liggen hoor, maar ik kon niet zo 1-2-3 voorbeelden vinden hoe ik
nu met deze gegevens kan omgaan :(
Wat ik dus bedoel is dat er op dit moment de volgende structuur wordt
teruggegeven in JSON:
LinePlanningNumber
DataOwnerCode_LocalServiceLevelCode_LinePlanningNumber_JourneyNumber
Gegevens van de betreffende rit
De meeste API's die JSON teruggeven maken geen gebruik van nested
data, bijv. de OpenBahn API voor Deutsche Bahn op
http://www.marcusschiesser.de/2011/06/openbahn-api-%E2%80%93-bahn-webseite-als-webservice/
Een voorbeeldje van de output
http://openbahnapi.appspot.com/rest/stations/list?contains=karlsr
Wanneer OpenOV het in hetzelfde "niet" nested formaat zou teruggeven
zou het verwerken een stukje makkelijker zijn?
Dan zouden we gewoon "Gegevens van de betreffende rit" hebben. Hier
zitten immers toch ook al de waardes van de andere "nests" in?
Er is vast een reden waarom het op de huidige manier is opgebouwd,
alleen vind ik het persoonlijk een draak om mee te werken ;)
Herrie
"DataOwnerCode_LocalServiceLevelCode_LinePlanningNumber_JourneyNumber"
omdat ik niet van tevoren weet wat daarvan de waarde gaat zijn...
Suggesties zijn natuurlijk welkom :)
On May 9, 10:00 am, Herrie <herri...@gmail.com> wrote:
> Het probleem zit het vooral in het feit dat de data "nested" is,
> hetgeen het erg lastig maakt voor mij om er mee te werken (kan ook aan
> mij liggen hoor, maar ik kon niet zo 1-2-3 voorbeelden vinden hoe ik
> nu met deze gegevens kan omgaan :(
>
> Wat ik dus bedoel is dat er op dit moment de volgende structuur wordt
> teruggegeven in JSON:
> LinePlanningNumber
>
> DataOwnerCode_LocalServiceLevelCode_LinePlanningNumber_JourneyNumber
> Gegevens van de betreffende rit
>
> De meeste API's die JSON teruggeven maken geen gebruik van nested
Stefan de Konink
> Het probleem zit hem vooral in
> "DataOwnerCode_LocalServiceLevelCode_LinePlanningNumber_JourneyNumber"
> omdat ik niet van tevoren weet wat daarvan de waarde gaat zijn...
> Suggesties zijn natuurlijk welkom :)
object terug. Daar mag je toch helemaal zelf mee doen wat jou goed dunkt?
Dat wij er voor hebben gekozen om de primary key op die manier te
modelleren als uniek nummer is toch geen reden waarom jij dat niet op een
andere manier zou doen?
Kun je even beschrijven wat je precies wilt doen? Dus van welke input naar
welke data je wilt komen. De data is nu toegankelijk op lijn, rit en halte
niveau. Ik kan me niet voorstellen dat dat niet genoeg zou zijn.
Stefan
Herrie
Het probleem is dat ik de naam van de primary key niet weet en ik dus
niet de items in de primary key kan benaderen...
Het is m'n eerste app met JSON en heb naar de nodige voorbeelden
gekeken, maar ik kom er niet uit in Javascript :(
Stefan de Konink
> Het probleem is dat ik de naam van de primary key niet weet en ik dus
> niet de items in de primary key kan benaderen...
>
> Het is m'n eerste app met JSON en heb naar de nodige voorbeelden
> gekeken, maar ik kom er niet uit in Javascript :(
is dat ook vrij beperkt. Geeft wel een beeld met ERDs.
Stefan
Joel Haasnoot
> gekeken, maar ik kom er niet uit in Javascript :(
<code>
for (key in data.actuals) {
record = data.actuals[key];
}
</code>