DGBuss:Kalenderfunksjoner
Kalenderfunksjonalitet i DGBuss 4.x
DGBuss er basert på et Versjon/Periode og Dagtype – prinsipp, hvilket betyr at hver eneste dato er tilordnet en kombinasjon av produksjonsversjon (‘V’) og dagtype (‘5’) , evt med en ekstra egenskap der man kan aktivere skolefridag (‘-‘). Dette prinsippet har ligget fast siden en eller annen gang på (19)90-tallet - tiden flyr!
Med det menes f.eks. at vinterruter 2019 kobles mot versjon V, (eller f.eks D). Via relativt fleksible definisjoner i periodekalender kan man da definere ulike perioder der V blir aktivert. Man kan også overstyre enkeltdatoer i unntakskalendere. Derved er det enkelt å overstyre en uke og sette den til f.eks. P, man kan aktivere søndagsruter på 1. mai ved å definere 1. mai som en dagtype 7 i unntakskalenderen. Man kan også for perioder eller enkeldatoer definere at det er skolefri (vises med ‘-‘) og derved vil turer i rutene som er merket «S» for skolekjøring, innstilles og turer som er merket «I» for skolefr«I» (evt-. «I»kke skolekjøring), aktiveres ekstra.
Sett at perioderegisteret er fyllt ut på følgende måte:
10 J Jul 24.12.13 02.01.14
20 P Påske 94 16.04.14 21.04.14
30 S Sommer 93 20.06.13 15.08.13
40 S Sommer 94 22.06.14 18.08.14
50 V Hele året 01.01.13 31.12.14
Alle data som skal behandles i systemet sjekkes fra toppen av perioderegisteret.
Resultatet kan illustreres på følgende vis:
Totalkalenderen viser oversikt over kjøretypene for hver enkelt dato:
Denne kjørekalenderen viser skolefri i perioden 1.-7. samt at 17. oktober kjøres som en søndag i periode ‘A’.
Andre muligheter for å begrense gyldigheten innenfor kalenderdefinisjonene man har i kalenderdefinisjonene: Ved å fra ruten gå via Tabell og Ruteinformasjon, kan man begrense gyldigheten, f.eks. i det tilfellet en sommerrute starter senere enn normal overgang mellom skolekjøring og sommerkjøring:
Det finnes dessuten en mulighet til å begrense enkeltturers evt. modellers gyldighet ved å sette FOM og eller TOM dato:
I all hovedsak har dette fungert etter hensikten og dekket de fleste behov.
Spesielt for kollektivselskaper som dekker et større område, kan det bli avvikende overgang mellom sommer og vinter, avvikende skoleferieavvikling etc og derved må man opprette og vedlikeholde ganske mange versjoner for å dekke alle avvikene. Derfor har brukerne både på samlinger og via enkelthenvendelser ønsket forbedringer på denne funksjonaliteten.
FynBus-modellen
En mulighet kanskje ikke alle er klar over: I Fynbus (regionsselskapet på Fyn), har man lenge hatt et annet verktøy som har gitt mulighet for detaljstyring på turnivå. Innenfor hver kommune har de ulike koder som aktiverer en kjøring. Derved kan de dato for dato bestemme om en avgang skal gå eller ikke, dessuten har de valgt at man innenfor hver kommune skal kunne ha inntil 10 ulike kalendermønstre.
Mandag 4.januar 2016 skal f.eks. turene i Assens som er merket AS1,AS2,AS3 og AS6 kjøre, mens andre turer er deaktivert. Dette har vist seg hensiktsmessig for Fyn og alle eksporter tar hensyn til denne kodingen. Kanskje kunne dette være nyttig også for øvrige kunder?
Sikre historikk
For å sikre at man har korrekt historikk for senere utskrift av produksjonsoppgaver, anbefales ved mindre endringer at man korrigerer i avgangskolonnene og evt setter en TOM-dato på gammel kolonne og FOM på ny og korrigert kolonne. Ved større endringer anbefales å kopiere hele produksjonsversjonen (rimelig kjapp rutine under vedlikehold og reorganiser - menyen) og aktivere den nye produksjonsversjonen fra endringsdatoen. Slik sikrer man at man alltid kan ta ut en rapport som viser korrekt produksjon over tid.
Planlagt utvidelse av kalenderfunksjonene i DGBuss 5.x
I hovedtrekk: Det utvides til å definere flere versjoner/dagtyper pr dato.
Vi har lenge ønsket å gjøre standard kalendersystem mer fleksibelt slik at man f.eks. kan definere helårsruter innunder versjon A. Ett område, det vi i definisjonene vil kalle «Kalender-sone» kan kjøre P om vinteren og S om sommeren med skolefri (Q) i uke 8. Et annet område kan kjøre D om vinteren med innstilling av skoleturene (D-) i uke 9.
Det betinger at vi må endre den opprinnelige forutsetningen om at hver dato kun har én versjon og dagtype til at det må være mulig å registrere og behandle flere versjoner / dagtyper pr dato. Denne endringen må gjennomføres i både Periode- og Unntaks-kalenderen.
Derved resulterer dette i at man kan aktivere 1,2 eller flere dagtyper pr dato og dette må også komme fram av kjørekalenderen (som i prinsippet også styrer alle eksporter, rapporter osv. (Det er neppe hensiktsmessig å definere for mange pr dag).
Et komplett eksempel kan se slik ut:
Figur: Eksempelet viser at man for sone 0 har definert P som vinterversjon, men bryter av med Q i uke 8. Parallelt har man innenfor definisjonen: Sone 1, definert en helårsversjon: D. I denne har man definert en ekskludering av skolerutene i uke 9. Mandag – onsdag i Påsken har man aktivert en ekstra kjøring som er lagt inn i versjon Y. Man kan også se at man har mulighet for å definere dagavvik for både sone 1 og sone 2 for f.eks. 1. mai.
Dette vil medføre at man bruker flere produksjonsversjoner, men samtidig vil det kunne bli færre ruter som er identiske i de ulike produksjonsversjonene. (I dag må man splitte opp en rute i f.eks. S og V – versjon selv om kjøringen er helt lik – fordi andre ruter har forskjell på sommer og vinter-ruter.) I stedet kan man ha kun en versjon av helårsrutene og eksempelvis kalle disse versjon ‘D’. På samme måte kan man da enklere definere inn at ulike områder har vinterferie i uke 8, andre i uke 9, tilsvarende for høstferier osv.
Det er ikke tenkt at de enkelte rutene skal kobles mot sone, kun at f.eks. 16. april, vil alle ruter i versjonene Q, D og Y og deres avganger som er merket dagtype 2 blir avviklet (i alle sammenhenger). Ut fra problemstillinger vi har blitt forelagt tidligere, har vi tro på at dette vil forenkle versjons-oppbyggingen vesentlig.
Status i utviklingen pr februar 19, er at (som man kan se: Definisjonene er på plass,) men man må gjennomgå rapporter, eksporter etc for å åpne for at man ikke lenger kun skal sjekke opp mot en versjon og dagtype pr dato, men alle de som er definert inn. Dvs et moderat arbeid å gjennomføre i det øyeblikk prinsippene bak utvidelsen er fastlagt.
