Sa'n sintrale doar foar de merkpartijen makket it makliker om oare partijen as applikaasjes ta te foegjen oan 'e keten, ek wol MaaS - Mobility As A Service. Noch binne d'r noch in soad obstakels te oerwinnen om it protokol folwoeksen te neamen. Tomp waard faaks krekt wat tefolle ûntwikkele troch technisy. Wichtige keppelings nei ferfier fan ticht keten ûntbrekke en dit wurdt no hieltyd dúdliker no't elkenien Tomp wol omearmje foar ymplemintaasje. De TOMP API (Transport Operator to Mobility Provider-Application Programming Interface) is in standerdisearre en technyske ynterface tusken MaaS-tsjinstferlieners en ferfierders.
wat is in keppeling?
Fergelykje in keppeling yn software tusken twa partijen, mar mei it gebrûk fan Google Translate. Jo stjoere it yn 'e lofterkant en it komt yn in oare taal oan' e rjochterkant út. Mar lykas faaks it gefal is mei Google Translate, wat rjochts útkomt, is it better om net folslein as wierheid te akseptearjen en it net te brûken te brûken of te publisearjen. En dat is krekt wat ûntbrekt by in protte links. D'r is gjin standert, sis in korrekt oersetproses, en de útkomst nei elke oersetting is iepen foar ynterpretaasje troch de brûker. Heech tiid foar ôfspraken en in standert. De lêste tiid hawwe wy it wurdboek sjoen foar doelgroepferfier fan it kennisplatfoarm KROUW ûntstean wat de skaaimerken fan 'e reizger beskriuwe moatte. In goed begjin, mar wy binne der noch lang net.
in stikje skiednis
Kritysk as net, it moat wurde skreaun dat de Tomp API mear die yn 'e taksy-sektor as alles dat der ea foargong. Wat gie der yn it ferline mis? Oanbieders fan softwaresystemen hawwe herhaaldlik har eigen keppelings betocht om in kliïnt bliid te meitsjen. Elkenien hie syn eigen fisy en woe boppe alles net bouwe op wat der al wie. It idee wie in strang plan om de merk te lûken. D'r is noch gjin sprake fan in iepen standert regissearre troch de sektor sels. In nije link komt út elke oanbesteging, mei as gefolch dat wy no in pallet software hawwe om te ûnderhâlden. Mar wat slimmer is, ynnovaasje wurdt tsjinhâlden troch alle beheiningen fan it besteande 'âlde' kommunikaasjemodel tusken partijen.
De sektorferiening KNV, dy't, as in ynnovatyf kearpunt yn har belied, in foaroprinner wêze wol yn alles dat MaaS brûkt as ferbinende faktor, hat de lêste jierren ek skuld west fan 'e spaghetti fan keppelings. Nettsjinsteande it hawwen fan in eigen ynnovaasjekomitee, wêr't de lêste 10 jier geregeldwei foarstellen binne yntsjinne om dit probleem oan te pakken, kamen se net fierder dan wat elke 'stipegroep' de lêste jierren hat dien. Miste kâns, in standert as protokol kaam net op. Des te mear reden om foarút te drukken en TOMP geskikt te meitsjen foar de sektor.
reizgerskenmerken
De Tomp API is spitigernôch lykwols noch net geskikt foar it betsjinjen fan alle fasetten fan taksyferfier. It mist noch in ôfspraaksysteem. Net op technysk nivo, krekt oarsom, hoeden. Mar d'r is noch in soad te dwaan yn termen fan passazjierskenmerken, budzjetoerienkomsten en tsjetteltochten dy't in taksy omfetsje. Dat betsjuttet net dat it in miste kâns is, om't de Tomp-wurkgroep der alles oan docht om it ta sukses te meitsjen en foaral harket nei sinjalen fan ferfierders en merkpartijen.
It hat in lange tiid west foar de komst fan in universele skeakel yn 'e taksy-sektor. De needsaak om sintrales te keppeljen bestiet 20 jier, mar elk ICT-bedriuw hat syn eigen tsjil útfûn. De trein is no yn folle gong mei allerhanne ferskillende tsjillen. De kosten foar ûnderhâld fan al dizze systemen skyrocket.
De tomp De wurkgroep moat no besjen wat eins technysk needsaaklik is om in boeking te realisearjen en hokker ûnderlinge partijen harsels moatte regelje. In budzjetprodukt dat troch in budzjetoanbieder oan in reizger wurdt tawiisd is in goed foarbyld hjirfan. Alle reizgerskenmerken dy't wurde registrearre yn 'e rekken fan' e reizger lykas it type budzjetprodukt, autorisaasjenûmer, jildigensperioade en in ferwizing nei termen en kondysjes en reisbetingsten kinne net fûn wurde binnen de Tomp API, wylst se in essensjeel diel binne fan de boeking. Mar dan komme oare faktoaren yn it spul, lykas de privacywetjouwing, wêr't in protte ynnovaasjes de lêste jierren oan 'e kop binne kommen.
De Tomp-wurkgroep is in publyk-partikulier partnerskip tusken MaaS-oanbieders, transportoperators, oare mobiliteit-relatearre organisaasjes en oerheden. De wurkgroep is derfan oertsjûge dat de Dragonfly-ferzje fan de API no stabyl is foar in langere perioade. De gegevensútwikseling fia de Tomp befettet alle ynformaasje yn ferbân mei planning, reservearjen, reservearjen, beteljen en reisstipe.
