Nye ATP? Er det tid for modernisering av kollektivdelen i ATP?

Kva er kvalitetane med dagens ATP- modell som vi vil behalde? Den har (relativt) intuitiv grafisk presentasjon av resultat og forutsetningar – GIS - kart Den krever ikkje vesentlig transportmodellkompetanse for å ta ut og ta i bruk resultat Resultata er planleggingsrelevante i seg sjølv Den utgjer eit godt grunnlag for anna transportmodellering: befolkning og arbeidsplassar er mor til (nesten) all forflytning

Kva er minusfaktorar – eller utfordringar ved ATP? ATP-modellen byggjer i liten (nesten ingen) grad på standardar – men binder seg til ein enkeltprodusent sine proprietære løysingar Nettverkskonstruksjonen er stykkevis tungvindt – og ”manuell” - i alle fall kollektivdelen Datamodellen som ligg bak kollektivdelen har manglar – og den lir under mangel på standardardar på feltet – og på datagrunnlag Ein del resultat i beregningane er ”for enkle” – og står i fare for å bli overfortolka

Kollektivmodellering er ei utfordring Standardiseringa er ikkje kome langt når det gjeld modellering av kollektivsystem – Dette gjeld både sjølve datamodellen… – …og nødvendig standardisering av data Datagrunnlag ”i det fri” har vore mangelvare Og modellering av kollektivsystem er i seg sjølv ei ikkje-triviell oppgave!

Kvifor er modellering av kollektivsystemet så vanskeleg? Det er ikkje nettverket i seg sjølv som bestemmer transportforholda, men tilbodet oppå nettverket Tilbodet kan vere komplekst – det vil som regel – bestå av mange ulike linjer og turar i same selskap – Linjene har mange ulike køyremønster – Mange selskap og konsesjonsområde, med vekslande samordning og korrespondanse – Ulike transportmiddel med ulike trasear – Ulike forhold for overgangar Tilbodet er nesten alltid lågfrekvent (mens alle andre transportformer lar deg reise når du vil, har kollektivsystemet ventetider)

Kvifor er modellering av kollektivsystemet så vanskeleg? (forts) Kollektivnettet heng i hop med resten av nettet berre i punkt – det kan ikkje vere funksjonelt utan samanknytting med gangnettet (og kanskje også andre nett) Ein kollektivtur er dermed nesten alltid ein fleirledda, kjeda tur, med overgangspunkt Vi ønskjer å modellere dette samla – og enkelt!

Og parametrane er… Mest vanleg er: a.Reisetid b.Gangtid i turendane c.Ventetid d.Overgangstid Viktigaste grunnlag for c og d er frekvensen Viktigaste grunnlag for b er forholda i gangnettet – og lokalisering av haldeplassar Grunnlaget for a er det operatørane som legg

F1 F2 F?

Kollektivmodulen i ATP – tida er moden? Alle delar av ATP bør handterast i same versjon av programgrunnlaget (ikkje som i dag) Nytt datagrunnlag blir stadig meir tilgjengeleg – Haldeplassregister i NVDB – Digitale rutedata Datamodellen for kollektivtrafikk er ikkje optimal

Regtopp – kva er no det? På 90-talet oppsto bl.a. dei regionale ruteinformasjonsselskapa (”177”), og med dei auka behovet for standardisert utveksling av rutedata. Det filbaserte informasjonsverktøyet Topp vart utvikla (i fleire variantar) – og Regtopp fungerte som lagrings- og utvekslingsformat Dei første steg mot nasjonal standardisering

Regtopp vart vidareutvikla… …og framveksten av elektronisk billettering gjorde at formatet fekk forlenga levetid Mange av dei regionale og lokale systema for samordna billettering brukar Regtopp som format for rutedatainput til billettsystemet Ruteplanleggingsverktøy i ”allmenn bruk” kan eksportere til Regtopp Det same kan Norsk Ruteinformasjon (som står bak rutebok.no) Dette må vi kunne utnytte?

Ergo: Regtopp er ein de-facto standard …og den er ein dinosaur… …men den lever… …enn så lenge… …og det stiller store krav til den som skal bruke, legge inn og kontrollere data

Oppbygginga til Regtopp (”datamodellen”) Filbasert – ingen databasemodell – ingen sjekk av ”integritet” Fire filar er nødvendige for å beskrive ruteopplegget i detalj: – Haldeplassar (HPL) – Turindeks – Turdata – Dagkode – (det fins mange andre – men dei er for andre formål) Når systemet er filbasert skal det lite til før logikken bryt (spektakulært) saman – både talet på tekstlinjer og rekkefølgja spelar ei rolle

”datamodellen” – forts. Modellen har to grunnsteinar – haldeplassen og turen Haldeplassen – punkt der av- og påstigning kan skje Turen – er sekvensen av Haldeplassar, gjennomløpt i ein definert rekkefølgje, med start på eit bestemt klokkeslett, på ein bestemt dag(kode)

Kva treng ATP-modellen som Regtopp ikkje har? Først og fremst manglar Regtopp den fullstendige geografiske dimensjonen: referanse til f.eks eit lag i GIS som kan vise den fysiske traseen til turane Regtopp er ei ”formatramme” – men den sikrar ikkje at den som brukar formatet held seg til lovleg eller vedtatt standard (du kan f.eks ”dikte” dine eigne haldeplassnummer, eller selskapskodar) Det er plass til koordinatar, men det er ikkje nødvendig å bruke det. Viktige ”metadata” kan ikkje lesast frå Regtopp (f.eks koordinatsystemet som er brukt) Mangel i forhold til standard: Haldeplassar er berre enkeltståande punkt – det kan ikkje definerast stoppområde/terminalområde slik som i Transmodel – eller som i NVDB sitt Haldeplassregister

Forusetningar for å knytte Regtoppdata til ATP-modellen Haldeplassane må ha standard ID (nummerering som i NVDB Haldeplassregister) – Dermed vil dei vere ferdig tilknytta vegnettet (evt gangvegnettet) - når det kjem frå NVDB eller Elveg Dei må også vere påført koordinatar slik som i NVDB – Dermed vil dei havne på rett punkt i kartet Det bør også finnast ”mekanismar” for å rydde opp i eller ”filtrere” haldeplassdata, f.eks der ein haldeplass består av fleire stopp-punkt.

Forusetningar for å knytte Regtoppdata til ATP-modellen (2) Overgangsinformasjon på haldeplassnivå bør utnyttast – det er ein del av NVDB, og har også plass i Regtopp-formatet Dersom kollektivtilbodet sine trasear skal kartfestast i ATP, må det skje ei ”mapping” (tilbakekopling) av haldeplass-til-haldeplass- lenkene til det fysiske nettet i kartet. – Dette er ikkje trivielt – men det kan gjerast, f.eks ved bruk av ”Linje”-informasjonen i Regtopp

Andre utfordringar med Regtopp-data Ofte eit betydeleg innslag av feil – Data som er laga for elektronisk billettering har gjerne eit lettvint forhold til dagkode dersom systemet har posisjonering (GPS) – det resulterer i feil frekvensar – Ulike system for køyremønster (som kollektivselskapa ”finn opp sjølv”) – for eksempel ”gafling” – kan skape tilsvarande problem – Små feil (f.eks. ein manglande haldeplass i ein tur) kan ha store utslag i resultat) Altså: sjekk av datakvalitet og integritet er viktig!

Nye konsept i ArcGIS Network Analyst bør også utnyttast i ATP-modellen