Kolumbus-appene utvikles altså som del av den offisielle leveransen til Kolumbus, men vår egen Jan Magne liker å utforske nye ting: Som eksempel på bruk av SIRI-dataene våre har han derfor laget en “Vehicle Finder”  Android-app som illustrere hvordan info om en gitt buss kan hentes ut og siden plottes på kartet (Faktisk et ganske nyttig “debugging-verktøy” for oss i prosjektet).

SIRI-grensesnittet er ikke helt ferdig ennå, så Jan Mange må trikse litt for å overkomme feil og mangler. Dette er ikke noe vi vil dele ut ennå, hverken appen eller det uferdige grensesnittet. Håper dere fremdeles kan smøre dere med tålmodighet fram til ut på høsten 2012 !

PS.: med ref til tidligere artikler, så jobber vi også videre med NLOD, i paralell.

PS2.:  og dersom du IKKE klarer å vente til ut på høsten, så kan du jo lage noe fint basert på rutedatene våre! Se http://next.kolumbus.no/rutedata/

Her er vår aller første prøvetur med det som skal bli neste versjon av Kolumbus-appene. Det er selvfølgelig fremdeles en drøss med små&store feil&mangler, men vi synes det er morsomt å vise dere at vi er på vei, og det i parallell på de tre platformene vi har valgt.

Funksjonsmessig ser vi på samme nivå som for dagens Kolumbus-apper, men med den viktige forskjellen at avgangstider er justert med Sanntids-info. De som har fulgt med på fremstillingen av slik Avgangsinfo i de andre kanalene (se f.eks denne artikkelen), vil kunne kjenne igjen “holdeplass-skiltet” også i videoen her, med sanntids-prognoser fra en av test-bussene langs rute 4.

I tidligere artikler har vi skrevet litt om tankene bak selve app-utviklingen.

GOD HELG alle sammen!

Her er en ny artikkel der vi ser litt på posisjoneringen (AVL) som ligger i bunn for Sanntidsløsningen.
I tillegg til testing på rute 4 , så tester vi nå tidvis også på den litt spesielle rute 25, som går mellom Byhaugen og Ramsvig her i Stavanger sentrum.  Litt mer om hvorfor vi har valgt rute 25 for testing følger senere i artikkelen, men 25en er et populært tilbud der den snirkler seg gjennom trange boliggater og travle bygater, nærmest “dør-til-dør” for brukergruppen. Fordi det er såpass trangt, bruker bussoperatøren en buss i “krympet utgave”.

Bussen posisjonering er et samspill mellom GPS-tracking og måling av utkjørt distanse fra forrige holdeplass (link-lengde). Utkjørt distanse beregnes fra bussens egen odometer-puls.  Odometeret gir pulser som angir antall omdreininger på bussens hjul. Sammenstiller en så det med omkretsen av hjulet, kan busscomputeren beregne hvor langt bussen har rullet langs den forhåndsdefinerte ruten.

Ved tidligere prøvekjøring med denne lille Storhaug-bussen, fungerte det hele meget dårlig. Annonsering var lite presis, og busscomputeren ga i flere perioder opp å anslå plassering i det hele tatt. De som har lest tidligere beskrivelser av virkemåten i Sanntidsinstallasjonen, vet da at innrapportering til Sentralsystemet blir tilsvarende dårlig, og at prognoser for avgangstider for turen blir unøyaktige og må til slutt fjernes fra visningen (erstattes med “ca”-symbolet og ruteheftets tidspunkter i visningene).

Mistanken gikk til odometer-settingen, og det viste seg å stemme. En variabel styrer utregning pr puls fra odometeret. Selvom en riktigere verdi var satt opprinnelig, var verdien senere blitt overskrevet med samme verdi som for de regulære bussene. Som bildet i dagens artikkel viser, har de vanlige bussene adskillig større hjul en lillebroren på Storhaug!

Med rett verdi innlagt, viste ny prøvetur at bussen “fant seg selv” og alle holdeplasser som forventet, og annonsering  på skjerm og over høyttaler forløp prikkfritt! Noe jobb gjenstår med selve stopp-symbolet på skjermen.

Hvorfor tester vi på rute 25 ?

Vi har ambisjoner om å få til Sanntid over hele fylket vårt, og ikke bare langs de sentrumsnære hovedrutene.  Lenger ute vet vi at selv om bussene også her har fastlagte ruter og definerte holdeplasser, så er det også endel “uoffisiell” på- og av-stigning, f.eks der gårdsveien møter hovedveien. Denne “servicen” er ikke styrt; Sjåfør og passasjerer  håndterer dette fint i lag, men vi vil ikke gjennfinne tidspunkter og steder hverken i plan-dataene eller i ruteheftene.

Rute 25 kjører litt tilsvarende: det er få offisielle stopp på denne ruten, men de flinke sjåførene tilpasser seg “landskapet” og har en stor gruppe stamgjester som er meget fornøyd med det.  Dermed håper vi å kunne bruke 25en til å teste at Sanntidssystemet ikke vil la seg stresse av et slikt “landlig kjøremønster”, men fortsette å melde posisjon (og prognoser) for de målepunktene som finnes, dvs de offisielle stoppene.

På siste test-tur med 25 så dette ut til å gå fint
(Det er selvfølgelig kun de offisielle stoppene som kan annonseres).

Ellers vil vi gjerne få anbefale en tur med 25en, der de hyggelige sjåførene og deres faste gjester har det riktig trivelig ilag. God stemning!

Systemet skal være klar til drift på høsten 2012, og inntil da vil du kunne påtreffe skjermer ombord i litt forskjellige stadier i sin utvikling,  -slik vi har skrevet om i en tidligere artikkel.

Nok en snik-titt her på Next; denne gangen av en litt mindre teknisk natur:  Markedsavdelingen har alliért seg med en av våre favoritt-tegnere!

Det er et par ting som kan være lurt å tenke på når du skal på busstur. Vi har fått hjelp av Eon til å forklare.

Buss. Rushtid. Mange folk på samme sted. Alle vil fort fram, så snart det lar seg gjøre, både de som er inni og utenfor bussen. Vi har skrapt sammen noen tips vi håper kan gjøre turen bedre for deg som er om bord.  Tetra, Freddy, Gonzales og de andre figurene i  Lars Lauviks univers har hjulpet oss for å få fram poenget.

Hva synes dere? Kanskje vi også kan snike inn flere av disse godbitene her på Next framover…

Vi har kanskje blitt litt stuck in our ways, og latt oss oppsluke av alle de andre sidene ved Sanntidsprosjektet.

Vår tanke har nok vært å leve med dagens ordning framover til høsten 2012, og så ta hele oppsettet opp til ny vurdering, inkl eventuell basering på NLOD, når vi får Sanntidsdata å dele ut i tillegg til dagens åpne Rutedata.

Selvom vi aktivt søker inspirasjon hos andre, har vi ikke alltid gjort og tenkt det samme som i Oslo og hos andre “storebrødre”.  Vi håper det kommer noe godt ut av slikt noen ganger (som GTFS-publiseringen vår, f.eks ).  Samtidig har vi også sagt at NLOD kan komme til å bli vår basis. Dette å åpne opp innebærer en modningsfase også hos oss.

Vi har spurt dere lesere til råds før, og det vi endte opp med finner du her.  Nå kunne vi godt tenke oss at flere gjør som Gorm har gjort: Bruk kommentarfeltet under her nå til å gi oss slik kritikk,  og samtidig tips hvordan vi bedrer oss på dette området. – Skal vi til NLOD? Skal vi forsére den tuviklingen, eller  jobbe videre med SIRI og resten av SIS-prosjektet, og ta det i samme runde til høsten? Andre ting relatert til dette? Fyr løs !!

Her har dere litt av bakgrunnen:

• Del av utfordringen fra Gorm går på om Kolumbus har “åpne nok” Rutedata pr idag:  Gorm mener at Kolumbus idag hindrer Openstreetmap.org tilgang til dataene. Vi har fått lov av Gorm å gjengi konversasjonen vi har hatt på dette temaet; -i vår oppsummering går uenigheten på det at Kolumbus har satt krav om at noen tar ansvar for å hente data fra oss når det er endringer i holdeplass-plasseringer, for å unngå at feil informasjon blir vist for brukerne av Openstreet-kartet (Resten av GTFS-settet var ikke relevant å bruke i openstreetmap på dette tidspunktet). Slike endringer skjer jevnlig.
• Gorm ønsket ikke å påta seg ansvaret for slik oppfølging. Om man velger å se praktisk eller prinsipielt på saken, så er det likevel en kjensgjerning at vi har til hensikt å si ok dersom noen påtar seg en slik oppfølging, -altså under den ordningen vi har nå.
• GTFS er et åpent format som Kolumbus tilbyr for Rutedata. Det ble valgt av oss bl.a. fordi vi mente at det har et større nedslagsfelt enn det “lokale, norske formatet”  (se under). Ja, opprinnelig ble GTFS  etablert/”eid” av Google, men alle kan fritt benytte data på slikt format.  Det er fullt tillatt for alle å tjene penger på bruk av Kolumbus sine GTFS-data.
• Kolumbus har også frigitt sine data på REGTOPP, som er et format “eid” av Trafikanten. Dette formatet var lite kjent utenfor bransjen, men Trafikanten var raske til å frigi det til almennheten når vi i Kolumbus spurte om det.  Det er fullt tillatt for alle å tjene penger på bruk av Kolumbus sine REGTOPP-data.
• Ja, Kolumbus gir også Rutedata til Google Maps . Søk på Kolmubus-reiser er dermed tilgjengelig på “alle” plattformer, -også som en “ferdig-installert app” omtrent overalt. Dette er et valg vi har tatt, i tillegg til punktene over.  Målet er at kunden skal få tilgang på Kolumbus reiseinfo der de er. -Dess flere plattformer, dess større er sjansen for at vi treffer deg der du liker å være.  Vi vil vurdere andre tilsvarende muligheter, der det er relevant (men det handler også om hva vi  har kapasitet til å rekke over..). Det er forøvrig fullt tillatt for Google å tjene penger på bruk av Kolumbus-dataene.
• Og så jobber vi som sagt videre med SIRI for å utvide tilbudet når Sanntidsdata kommer. Ingenting er gratis her i verden, men vi har altså valgt å legge ressurser i å kunne tilby også dette for dere 3dje-parts utviklere, gratis.

Håper det kan bli en grei debatt ut av dette. Takk til Gorm !

En annen måte å dele kode mellom plattformene er å bygge apper helt eller delvis i HTML5. En fordel ved å bygge på en åpen standard som HTML5 er at den resulterende appen kan kjøre mer eller mindre ”overalt”. -Likevel har vi valgt å ikke gjøre det for de nye appene, forklarer Lars, og det er flere grunner til det: Et mål for oss er at appene skal føles som om de hører hjemme på de plattformene de kjører på. Da må vi kunne lage brukergrensesnittet slik at Android-appen ser ut som en Android-app og ikke en Windows Phone eller iPhone-app. Samtidig kan vi ved å bruke C# som språk bygge på koden fra en tidligere leveranse av et lignende produkt.

Kolumbus har operert med fritt tilgjengelige rutedata en stund nå, og vi har som erklært ambisjon at vi også vil stille sanntidsdata til fritt bruk når den tid kommer. Dermed kan andre utvikle egne løsninger som benytter avgangsinfo, dvs prognosen for når bussen vil komme til å gå fra en gitt holdeplass.

I tillegg til å vise avgangsinfo, har Kolumbus-appen også et annet bruksområde, gjennom sin Reiseplanlegger-funksjon (se gjerne dagens Kolumbus-apper) . I forbindelse med produksjonen av de nye appene vil det bli laget et REST-basert API som appene vil hente data fra,  også når det gjelder  reiseplanleggings-funksjoner. Dette vil være spesialtilpasset mobile enheter. Vi kunne se på om det er mulighet for å kunne frigi også dette, dersom det er av interesse.

Vi er ydmyke for oppgaven vi har tatt på oss med SIS2012-prosjektet her i Rogland. Det er tusenvis av puslebiter som skal på plass, og vi har satt oss høye ambisjoner. I en så kompleks leveranse vil vi kanskje ikke få til alt akkurat slik vi helst ønsker oss, men grunnfunksjonaliteten må være god nok, og noe som kan bygges videre på. Så langt er det mye bra som er på plass, og som dere har sett her på next.  Gjenstående ting jobbes det videre med fram mot lanseringen Høsten 2012, og det er også fint å merke seg at selve monteringsarbeidet i alle bussene ligger godt an så langt.