Nye ATP?

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

2. 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 utgjereit godt grunnlag for anna transportmodellering: befolkning og arbeidsplassar er mor til (nesten) all forflytning

3. Kva er minusfaktorar – eller utfordringar ved ATP? • ATP-modellenbyggjer 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

4. Kollektivmodellering er ei utfordring • Standardiseringa er ikkjekome 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!

5. 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)

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

7. Og parametrane er… • Mest vanleg er: • Reisetid • Gangtid i turendane • Ventetid • 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

8. F1 F? F2

9. 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 meirtilgjengeleg • Haldeplassregister i NVDB • Digitale rutedata • Datamodellen for kollektivtrafikk er ikkje optimal

10. 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 fleirevariantar) – og Regtopp fungerte som lagrings- og utvekslingsformat • Dei første steg mot nasjonal standardisering

11. 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?

12. Ergo: Regtopp er einde-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

13. 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

14. ”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)

15. Kva treng ATP-modellen som Regtoppikkje har? • Først og fremst manglarRegtopp den fullstendige geografiske dimensjonen: referanse til f.ekseit lag i GIS som kan vise den fysiske traseen til turane • Regtopp er ei ”formatramme” – men den sikrarikkje 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 ikkjelesast frå Regtopp (f.eks koordinatsystemet som er brukt) • Mangel i forhold til standard: Haldeplassar er berreenkeltståande punkt – det kan ikkjedefinerast stoppområde/terminalområde slik som i Transmodel – eller som i NVDB sitt Haldeplassregister

16. Forusetningar for å knytte Regtoppdata til ATP-modellen • Haldeplassane må ha standard ID (nummerering som i NVDB Haldeplassregister) • Dermed vil deivere 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 einhaldeplass består av fleire stopp-punkt.

17. 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

18. Andre utfordringar med Regtopp-data • Ofte eitbetydeleg 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. einmanglandehaldeplass i ein tur) kan ha store utslag i resultat) • Altså: sjekk av datakvalitet og integritet er viktig!

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