DGBuss

DGBuss

Velkommen

VELKOMMEN

Velkommen som bruker av DGBuss - et system for vedlikhold av ruter og planer for kollektivtrafikk.

Denne hjelpefil er en foreløpig utgave for WDGBuss og intensjonen er å bygge inn mest mulig nyttig informasjon.

Lykke til og ring eller ta kontakt på annen måte om du har problemer eller spørsmål!

Tlf +47 55 11 25 00

www.datagrafikk.no

Support

Har du spørsmål eller problemer, anbefaler vi å sende en epost med henvendelsen til [email protected]. Beskriv problemet, dokumenter gjerne med skjermbilder, eller vedlegg f.eks. form av eksportfiler. Om du samtidig beskriver graden av hastverk, hjelper du oss!

F.eks. slik:

caption

Der vil du få en kvittering med saksnummer:

caption

Dersom du har ytterligere opplysninger eller skal svare på våre henvendelser i saken, trykk på svar eller sørg for at vår support-tag følger med i emne-feltet; F.eks. "[#DG07765] DGBuss: Trenger hjelp til å logge på". Derved blir alle henvendelser i saken samlet under dette saksnummeret og det er enklere for oss å sørge for riktig oppfølging.

Om saken løser seg av seg selv, eller evt etter tips fra oss, setter vi pris på en ekstra epost der du beskriver om saken er løst, uaktuell el.l. - så kan vi avslutte saken i supportsystemet.

Hovedmeny

Hovedmenyen i DGBuss gir tilgang til alle funksjoner. Gruppen Programmoduler gir tilgang til Ruteredigering, skift/vakt, vognplaner, turnus, samt vedlikehold tjenesteplan. De modulene som ikke er aktuelle for den aktuelle bruker og lisens, er grå og ikke valgbare.

caption

Programmoduler

DGBuss Programmoduler

caption

Classic

DGBuss Classic

caption

Daglig drift

DGBuss Daglig Drift

MS-SQL

DGBuss MSSQL

Grunnregistre

DGBuss Programmoduler

caption

Kalenderfunksjoner

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:

caption

Totalkalenderen viser oversikt over kjøretypene for hver enkelt dato:

caption

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:

caption

Det finnes dessuten en mulighet til å begrense enkeltturers evt. modellers gyldighet ved å sette FOM og eller TOM dato:

caption

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.

caption

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:

caption

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.

Vedlikehold

DGBuss Vedlikehold

caption

Eksport-rutiner

DGBuss eksport

caption

Eksportfunksjonene ligger under Vedlikeholdsmenyen. Alle eksporter er bygget opp etter samme prinsipp: Man kan utføre eksport for hele datasettet eller kun en (test?) eksport for de rutene som er markert i ruteoversikten.

Man har oppsettsparametre der man kan sette eksportens gyldighet, samt en del andre parametre,.

Man kan dessuten se på log-filen fra siste eksport.

RegTopp-eksport

Huskeliste for RegTopp-eksport (men denne gir gode tips til hva man bør huske også ved f.eks. NeTEx-eksport.)

caption

Figuren illistrerer en del av punktene man må huske på når man skal kode en rute med RegTopp (RT)-eksport.

Ruteendringsbildet.

1. Alle holdeplasser man benytter må ha riktig RegTopp HPL-nr.

2. Alle linjer (destinasjoner) i tabellen som skal eksporteres i RT - overføringen må ha et tall i km-kolonnen. Isolert sett betyr det ingenting hva som står i kolonnen, bare det er et tall. Har mn riktig km-angivelse er dette å foretrekke, bl.a. pga bruk av RuteGrafikk. Korrespondansehenvisninger (Tog til Oslo etc) skal ikke eksporteres og man utelater derfor km foran denne linjen.

3. Husk at passeringstidfontnote skal ligge i 5. posisjon i tid-feltet. Kun en fotnote leses. I RT-1.1d - eksport ignoreres passeringstidfontnoter.

4. Klokkeslett etter midnatt skal skrives som (23:45,) 24:05, 24:45, 25:00 etc Ved utskrifter trekker systemet automatisk fra 24 timer. Det er slik systemet klarer å skille mellom avganger i dag tidlig og i morgen tidlig. Eks. Om en avgang kjøres i dagtype 2 og passeringstiden i stasjon C er 26:10, betyr dette kl. 02:10 onsdag morgen)

5. Alle Dagtyper noteres som Dx67 etc.

RegTopp-oppysninger: (Menypunkt under Endre)

Alle opplysningene legges inn i tur og retur-retning.

1. Publikumsnummer må legges inn: Eks rute/linje 11. I enkelte fylker har man valgt å bruke nummerering etter "NRI-metoden": 19-110 der 19 er fylke osv.

2. Linjenavnet bør tilsvare rutenavnet i et rutehefte

3. RegTopp-linjenummer MÅ fylles ut. Det er samtidig et signal til eksportmodulen om at ruten skal eksporteres (dvs kun ruter der denne opplysningen er fyllt ut blir eksportert). Vi anbefaler at man benytter lokalt rutenummer og legger til 1000 i tur-retning og 2000 i retur-retningen. Vi vet ikke om anvendelser av RegTopp-formatet der dette nummeret blir synlig for publikum så man står relativt fritt vedr system funt nummerering. Vi anbefaler imidlertid at man benytter samme RT-linjenummer for forskjellige sesongvariasjoner fordi dette sikrer en komprimering av data under eksport.

5. Trafikkart må fylles ut (Lokalbuss er 2 osv, Se egen forklaring på Trafikkart)

6. Destinasjonsskilt kreves av enkelte anvendelser. Tips: Skriver du -1, får du en liste over de definerte destinasjonsskiltene og kan velge inn ønsket skilt.

7. Om man ikke har koblet ruten i Koblingsbildet, har man anledning til å fylle ut Versjon (sesongvariant).

Husk at alt man fyller ut av opplysninger i disse 2 bildene, følger med om man kopierer fra en vinter til en sommer-rute. Derved vil det lønne seg å gjennomarbeide den mest omfattende versjonen før man kopierer til en ny versjon. Da slipper man med minimalt arbeid å kode den nye versjonen for RT-eksport.

Selve eksport-rutinen:

Sørg for at rutene og kjørekalender er riktig utfyllt.

Gå via Vedlikehold til Eksport og Eksport RegTopp (5,6,3) - menyen.

Se og evt korriger i Oppsett / alternativer:

caption

Pass på at start og slutt-dato stemmer og at stien man registrerer eksisterer. (Om man angir en sti, sørg for å aslutte med '\' (Eks. 'C:\RegTopp\'))

Start eksport (1.1d og 1.2). Etter eksport er ferdig, er det en veldig god regel å sjekke "Utskrift av log-fil til skjerm". Denne log-filen gir mange muligheter for å avsløre feil i en eksport før man sender et datasett fra seg. Her kan man bl.a. merke seg at en advarsel om at en rute har negativ paseringstid kun er ment som en advarsel om at en avgang kan være defekt pga feilinntasting, men dette kan også være tilsiktet. Evt negative avgangstider blir ortert omm automatisk.

Om man ikke har angitt sti, vil man finne eksportfilene igjen i samme katalog som dataene ligger (ofte C:\dg\pcp50).

Pakk ned alle filene av typen R1510.* til en fil og mail dem til din driftsoperatør. Gi samtidig beskjed om hvilket datointervall sendingen er gyldig for.

Spesialfunksjoner for system som ikke er koblet med Plan

Om rutemodulen ikke er koblet med plan, har man større frihet til å spesialkode gyldighet for enkeltkolonner uten at dette gir negative konsekvenser for r.eks. skiftplaner. Systemet må evt settes opp spesielt for dette formålet (Tabellype:62).

Man har 2 spesialfunksjoner som kan utnyttes:

1. Overstyring av gyldighet på tabell og tur.

En tidtabell kan gies et gyldighetsintervall (Endre, Ruteinformasjon i tabellen) som da kan innskrenke øvrig periode definert gjennom kjørekalender. Om f.eks. tabellversjon B kjøres hele vinteren, kan man i rute 10B som er koblet mot preiode B overstyre denne til å avslutte 1. februar 04. Det samme gjelder enkeltkolonner innen tabellen (gå via Kolonne og sPesifikasjon i en tidtabell og legg begrensningene i TOM dato og FOM dato.

2. Automatikk for skolefri.

I hver enkelt tabellkolonne (under Kolonne og sPesifikasjon) kan man sette en "S" i Skolfeltet for å markere at turen går kun på skoledager.

I både periode og kalender - definisjonene lan man i Type-feltet sette en '-' (bindestrek) for å markere at skolekjøring utgår. Resultatet kan sjekkes ved å kikke på kjørekalenderen der det vil framkomme en '-' etter hver dato der skolekjøring utgår.

RegTopp-eksporten samordner dette slik at turene merket 'S' i skol-feltet utgår på datoer der skolekjøringen er kodet som innstilt. NB! Denne funksjonaliteten gjelder kun RegTopp-eksport.

Rapporter

DGBuss Rapporter

caption

Optimalisering

DGBuss Optimalisering

Ruteproduksjon

DGBuss Ruteproduksjon

caption

Hjelp

DGBuss Hjelp

caption

Andre emner

Avansert dagtypekoding

Det finnes 2 alternative dagtypekodinger. Avansert dagtypekoding som for de fleste vil bety en vesentlig forenkling i arbeidet med kobling av rutedata mot skift, samt vedlikehold av dette.

Tradisjonelt har koblingen mellom ruter og plan fungert slik at hver kolonne i PC-Ruter blir tilordnet til et skift ved å skrive inn et skiftnummer i skift-linjen over kolonnen. Det oppstår da en "1 til 1" - kobling slik at turen vil forekomme som en linje i tilsvarende plan Pga. tariffbestemmelsene, må turer som går både hverdager, lørdag og/eller søndag, splittes i separate P-kolonner som kobles mot tilsvarende skift. Dette fungerer og blir ryddig og oversiktlig. Dersom man så får et avvik fra "standarden" på f.eks. torsdag, blir det straks mer komplisert. Alle turer som inngår i et slikt skift, må splittes (også P-kolonner). Dette har tendensen til å forplante seg til andre ruter og skift og derved resultere i et omfattende og omstendig arbeid.

Dersom man har regulær kjøring alle dager uten unntak enkelte dager, vil standard dagkode-kobling være å foretrekke, men de fleste selskap vil nok ha stor glede av å gå over til avansert dagtype-koding.

Avansert dagtype-koding aktiveres ved å velge 5. Vedlikehold/Utskrifter i Hovedmenyen, og deretter 5. Systemoppsett, 3. Brukerdefinerte valg PC-Plan og 5. Spesial-parameter.

Ved å svare 'N' til 4 posisjoner signifikant i skift, aktiveres Avansert dagtype-koding.

NB! Husk å kjøre 1. Sortere fra Vedlikeholdsmenyen under punkt 1. Reorganisering før arbeidet startes opp.

Denne omleggingen kan påvirke eksisterende data. Vi anbefaler derfor at omleggingen foretas i forbindelse med versjons-skifte, og at man tar en komplett kopi av hele installasjonen til et nytt område og fortsetter planleggingen på den nye kopien.

Først av alt bør man venne seg til å tenke på de første 3 siffer i skift-nummeret som skift-gruppe f.eks. 100L = skiftgruppe 100 i Lørdag-versjonen. Det 4. siffer angir dag-typen.

Anbefaling:

Sett av L til lørdag, S til søndag og A, B, C, D og E til evt. spesial versjoner av skift for en enkelt ukedag mandag - fredag. Dersom skiftet går helt uten unntak fra mandag - fredag, settes 4. bokstav blank. Et skift som går ma, ti, to og fr, kan kalles 100G osv.

De første 3. sifrene velges ut fra område/stasjoneringssted e.l.

På denne måten vil alle kunne lese en rekke viktig informasjon ut fra skiftets navn.

En tur i Rute-modulen kobles mot et skift i Plan-modulen ved å angi skift-nummer i 2. hodelinje. I dette tilfellet kan vi tenke oss at vi har 4 turer som er koblet til samme skiftnummer, og kjører daglig med avvik på onsdag. Vi kaller skiftet 100G og legger skiftnummeret inn i 2. hodelinje over hver av de fire turene som skal være med i dette skiftet. OBS. det er i dette tilfellet ikke nødvendig å bruke Type kol feltet over disse turene til annet enn evt. mal-kolonner.

I Plan-modulen vil du nå kunne hente opp skift nr. 100G, og skiftet kommer opp med en linje for hver tur som har fått dette skiftnummer i PC-Ruter. Stå ute i skift oversikten marker skiftnr. 100G, trykk [insert] tasten og det kommer opp en ny meny hvor det står: Opprett: vakt. Markøren står nå å blinker i et grått felt, vi skal opprette et skift for onsdag og skriver inn 100C [Enter] skiftoversikten kommer opp igjen med det nye skiftet. Opprett skift for lørdag og søndag (100L og 100S) på samme måte.

Ta opp skift 100G. Velg End menyen (Endre Vakt-opplysninger) Du får nå tilgang til feltet for dager. Sett inn bokstaver for dagene som skiftplanen gjelder for med blankt felt for dager som ikke skal være med. I dette tilfellet MT TF. Avslutt med [Enter] i siste felt eller [F2].

Velg nå Lin menyen (Endre Linjeopplysninger). Legg inn f.eks. posisjonskjøring på 10 min. i første linje. Legges det inn en D for daglig i kolonnen for dager vil denne grønne linjen også komme opp i skiftnr. 100C, 100L og 100S. Legges det inn Dx67 vil linjen bare komme opp i skift 100C i tillegg til skiftnr. 100G.

Ta opp de tre andre skiftene og sett inn hvilke dager de gjelder. Du vil nå se alle fire skiftene i skiftoversikten og hvilke dager det enkelte skiftet gjelder for, både ved hjelp av skiftnummer og i kolonnen for ukedager.

Ved å benytte denne framgangsmåten, vil man altså kunne legge inn spisepause fra kl. 11.00 til 11.30, for alle 100-skiftene en gang, og dette vil komme fram på alle skiftene hvis dagkoden er gyldig.

Man bør imidlertid også være oppmerksom på at det også er mulig at skift i samme skiftgruppe kan være definert for samme dag. Ved at det f.eks. opprettes et skift i en skiftgruppe for ma, ti, to og fr, og et annet skift i samme skiftgruppe for on og fr. Denne fellen kan lettere oppdages ved at man bruker bokstavene M, T, O osv. når man definerer hvilke dager skiftet gjelder for, skift-oversikten gir et godt overblikk over hvilke dager en skift gruppe er definert for.

En annen feilmulighet er at det kan opprettes en tur som ikke faller innenfor noen av skiftene i en skiftgruppe. Hvis det f.eks. er opprettet et skift for ma, ti, to og fr, og et skift for on, vil en tur som går bare fredag i samme skiftgruppe falle utenfor.

For å unngå slike feilmuligheter er det laget en sjekke-rutine som ligger under PC-Plan menyen punkt 9. Integritetssjekk turer (-) Vakt. Denne sjekkerutinen går igjennom sammenhengen mellom turer og vakter, for den versjon som er ibruk. Rutinen vil først gi en oversikt over vakter som er dobbelt definert på minimum en ukedag.

---

¦DataGrafikk a.s Dato: 02.11.18 Klokken: 14:49:53

¦Integritetsjekk for 3 pos. Vakt-behandling

¦Produksjonsversjon: H

¦

¦Følgende Vakt er dobbelt-definert på minimum en ukedag:

¦------------------------------------------------------------------

¦Vakt MTOTFLS

¦

¦72 A MTOTF

¦72 B MT TF

¦72 L L

¦72 S S

Denne utskriften viser at skift nr 72 er delt opp i fire skift, men 72 A og B er dobbelt definert på mandag, tirsdag, torsdag og fredag. Tar man opp skiftnr. 72A og setter inn at dette skiftet bare gjelder for onsdag vil denne skiftgruppen ikke komme opp som feilmelding i neste integritetssjekk.

Daglig drifts-modul skal bygge videre på all informasjon som ligger i trafikkdatabasen til Ruter- og -Plan. I dette inngår ruter, skift-(vakt-planer, vogn-planer, turnus-(rotasjons-)planer, mannskapslister, kjørekalender, tariff- og kode-register.

Ut fra denne trafikkdatabasen skapes Dagplaner som er en samling av aktiviteter. En aktivitet kjennetegnes ved at den skal utføres av en sjåfør og en buss. Aktiviteten har et planlagt start- og slutt-tidspunkt og en lengde og kan også beskrives gjennom en merknad. Første del av et skift, er et eksempel på en aktivitet.

1. Alle turer i Rute-modulen skal være koblet mot skift. Husk at «null-skiftet» bør være tomt!

2. Man får i så fall en meget god indikasjon på at man ikke har glemt å koble enkelte turer.

3. Kjører man avansert dagtypekoding, bør man dessuten kjøre integritetssjekk - slik at man er sikker på at turen er disponert én, men bare én gang pr ukedag den skal kjøre.

4. Ruteturer som ikke er koblet mot skift, vil ikke bli hensyntatt i Daglig drift.

5. Alle skift bør være disponert mot turnus. Ikke koblede skift vil komme fram av dagplanen uten tilordnet sjåfør.

6. Kjørekalenderen må være utfyllt.

7. Lønnsperiodene må være utfyllt.

1. Opprett en dag. Sjekk dagplanen og gjør evt. endringer i skftene, vogntildeling på turer, koderegister, splittarter e.l. Endrer du en av disse, må du opprette dagen på nytt for for at dagplanen skal endres.

2. Når dagplanen for test-dagen stemmer, kan man opprette en hel lønns-periode.

Utgangspunktet ved oppretting av dag, er registrene for skift, turer i skift, kjørekalender, turnus, personell osv.

Dagplanen er en liste over aktiviteter: Eksempler på aktiviteter kan være: 1. del av et skift, 2. del av et skift, en spisepause, en turbuss-tur osv. Man kan også sette opp systemet slik at et skift blir splittet i en ny aktivitet når sjåføren skifter vogn.

På denne måten vil man få en liste over aktiviteter der listen kan sorteres avhengig av bruksområde:

Sorteringen velges ved å trykke [F2] i dagplanen.

Beregningsfunksjoner

Type (kolonner):

M: Modell(mal),

R: Repeterende mal

m: Henviser til modellkolonne,

r: Henviser til repeterende mal

O: Kun til publikums informasjon (Out-put)

P: Planlegging

S: Supplement; Vises i tidtabell, men stammer fra annen rute

Beregningsfunksjoner:

Vanlige maler:

Ved å opprette egne kolonner først i tabellen og merke disse med en 'M' i 1. pos. 1. linje, vil dette være en mal-kolonne for beregning av andre kolonner. Fyll ut med tiden '9999 ' i første vanlige tid-kolonne.

Repeterende maler:

Opprettes egne kolonner først i tabellen som merkes med f.eks. R01, vil denne danne mal for andre kolonner. Om man fyller ut start-tidspunkt i hodelinje 2, siste mulige avgangstid i hodelinje 3 og intervallet i linje 4: Eks. I30 for en avgang hvert 30. minutt. Kan man via Kolonne-menyen starte en beregning av Repeterende kolonner

Timesammendrag

Utfylling i Tekst-feltet styrer mulighet for å skiver tidtabeller med timesammendrag:

Om man ønsker å komprimere tidtabellen pga repeterende mønster, slik som eksempelet under viser, kan man kode dette gjennom utfyllinger i Tekst-feltet i turspesifikasjonen (F8): I dette tilfellet gjelder det en 30 - minutters-rute fra 18:00 - 22:30.

caption

Her har 18:00 - avgangen ingen utfylling, De 2 første avgangene etter: altså 18:30 og 19:00 - avgangene, har utfyllingene 'F' i Tekst-feltet, resten av avgangene mellom 19:00 og 22:00 har så 'X'-utfylling i Tekst-feltet. Dersom man har valgt å se f.eks. tur-lengde + Tekst - feltet i 2. hodelinje (som i eksempelet), vil man ha grei oversikt over utfyllingene.

Resultatet vil se slik ut: (Forutsatt at man velger utskrift "Publikumstabell, timesammendrag".

caption

Attribut-feltet

Attributt-feltets virkninger:

1. posisjon: Horisontale streker

f; strek før avgang, e; strek etter avgang, b; begge,

2. posisjon: Piler i til/fra-feltet og kommentar etc.

n; pil ned, o; pil opp t; Til, f; Fra, k; kommentar,

S; Skrå, U; Uthevet i tidkolonner,

X; fjerner horisontal strek

V; Vanlig tekst i tid- og ikke utpunktering i sted-feltet

3. posisjon: Korrespondanser etc.

k: Kursiv, h : Halvfet, o: Rød markering

x: utelat ved utskrift av tidtabell

4. posisjon:

X: utelat hpl. ved Bybuss-utskrift

5. posisjon: Billett-system

x: utelat ved eksport (billett-system)?

DGis - lenking steg for steg

Kjør DGis og åpne prosjekt fra Fil-menyen.

Velg ruten du vil lenke i ruteoversikten og åpne for endring (Menypunkt endre rute).

Ruten må være koblet, velg Tabell > Koblinger for å sjekke at ruten er koblet mot riktig produksjonsversjon. Må ha ja (J) i felt for Koble j/N og produksjonsversjon i felt for Versjon.

Opprett lenker for ruten, velg Tabell > Oppdatering av lenkelengder. Lenker som allerede er opprettet hentes inn med korrekt lengde.

Hopper man over i DGis ser man at lenkene tegnes som gule rette streker. Lenkene må lenkes via vegnettet for å få korrekte lengder og geografi.

For å gå gjennom de ubehandlede lenkene velges Turlenker > Håndter tomme lenker fra DGis menyen. DGis kommer automatisk med et forslag til korteste veg. Er forslaget riktig trykker man på godkjenn for å lagre forslaget og gå videre til neste lenke

Start- og sluttretning velges ettersom stoppet ligger på høyre eller venstre side av vegen.

Ved å bytte sluttretning til venstre kan lenken godkjennes.

Dersom lenken ikke kan beregnes via korteste veg må den behandles manuelt. Man velger knappen for manuell behandling.

Lenken er nå klar til å behandles manuelt. Vi bytter vindu til verktøy for manuell lenking.

Vi benytter lenkeverktøyene for å lenke det problematiske området og lenken godkjennes.

Når ruten er ferdig lenket hopper man tilbake i DGBuss. De behandlede lenkene vises med stjerne i tabellkolonnen. For å hente de nye lenkelengder velg Tabell > Oppdatering av lenkelengder.

DGBuss sjekker at alle lenker er behandlet.

Import av RegTopp-data

Import-rutinen blir kraftig forbedret i forbindelse med versjon 5.x ab DGBuss.

Når man vil importere rutedata og annen tilgjengelig grunninformasjon fra RegTopp-filer til DGBuss, gjennomføres det ved en flertrinns prosess.

Trinn 1: Forberedelser

Valg av importparametere, valg av importfiler og justering av linjelengde for eksportfilene.

Importfilene velges via filvalg.

Start menypunktet, velg hvilken trafikkperiode man ønsker å importere til og velg hvilken kalendersone man ønsker å sammenlikne dagkodene i importen med.

Trinn 2: Kalenderinformasjon

Import kalenderdata, analyse av dagavvikene i dagkodestrengene og forhåndsdefinering av kjørekalender.

Systemet leser gjennom dagkodefilen og forsøker å analysere avvikene sammenliknet med gjeldende definisjoner i DGBuss sin kjørekalender. Informasjoner i figuren over, tyder på at 1. mai 19 ikke burde ha vanlig dagkodedefinisjon (normalt er 1/5-19 en onsdag (3).

Når man ser «analysen av dagkodenr 2, viser den at daggyldigheten normalt er lørdagsavganger. Unntakene som blir vist, er at den også er gyldig 17. mai, noe som sannsynligvis vil bety at man i kjørekalenderen for kalendersone 1 bør legge inn et unntak slik at 17/5-19 kjører som en lørdag.

Slik kan man gå gjennom dagkode for dagkode og ut fra informasjonen som oppgis, finne den kalenderdefinisjonen som gir best overensstemmelse med vår kjørekalender.

Rapporten etter kjøring, vil vise:

I dette tilfellet ble det definert at 1/5 skal kjøres som en søndag (D7) og 17/5 kjøres som en lørdag. Deretter gjentar man trinn 2 og får følgende resultat:

Man ser altså at man før de siste definisjonene ville få unntak på 93 av dagkodene til kun 9!

Om man velger å se tips, får man en liste over unntaksdager som kanskje kan foredle definisjonene ytterligere:

Da er man klar til å forberede rutene i trinn 3.

Trinn 3: Generer importerbare ruter

Dette trinnet behandler tur for tur i rapporten og grupperer disse til ruter. Hver tur sammenliknes med dagkode og definert kjørekalender slik at de blir tilordnet en daggyldighet (f.esk. Dx67). Unntak som ikke kan legges direkt på turen, blir kodet inn og lagt inn i med dagkodenummer i turens tekst-felt og forklaringen legges i rutens internnotat.

Trinn 4: Opprett rutene i ruteoversikten

Siste trinn i prosessen oppretter rutene slik at de blir editerbare i rutemodulen:

Årsaken til at dette punktet ikke er lagt innunder trinn 3, er flerdelt:

at det er mulig i eget punkt å behandle kun de 4 første rutene for å sjekke at resultatet blir bra, samt at det er planlagt en fremtidig forbedring der man kan velge ut hvilke av de tilgjengelige rutene som skal importeres. NB! Husk at Trinn 4 overskriver evt eksisterende ruter med tilsvarende navn.

Ser man inn i ruteoversikten, har man fått opprettet tabellene:

Eksempel på importert rute:

Legg merke til at attribut-feltet også fylles ut. Bl.a. merkes enkelte linjer/destinasjoner med en x slik at disse linjene blir undertrykket når man skriver ut en publikumstabell. Destinasjoner som er definert som bytteholdeplasser samt destinasjoner der turer har sin start eller slutt, undertrykkes ikke. Man kan selvfølgelig senere overstyre disse attributtene.

Også andre grunnregistre slik som merknader, holdeplassregister og destinasjonsskiltregister blir opprettet.

Import/oppdatering av stoppunkter fra NSR

I forbindelse med eksport til NeTEx, har det vært et ønske om å kunne hente inn stoppunkter og holdeplasser og å oppdatere disse på grunnlag av det som finnes hus EnTur / NSR.

I håp om å kunne utnytte disse nasjonale data best mulig, har vi splittet opp prosessen i ulike funksjoner.

Hent fra NSR

Rutinen kobler seg opp mot NSRs tjeneste for nedlasting av forrige døgns totaltabell for stoppunkter i Norge og oppretter en lokal tabell for videre benyttelse.

Nb! Forutsetninger:

• MS-SQL – server og et oppsett på server.
• Evt tidsstyrt oppgave på server slik at denne lastes ned og behandles hver natt.

Man kan også starte den manuelt fra DGBuss når man ønsker oppdateringer:

Se på NSR Master-register

Det vil deretter være mulig å se på tabellen via eget menypunkt:

Nb! Enn så lenge vil tabellen se ut som om norske tegn ikke er korrekt overført. Dette er noe unøyaktig i visningen og vil ble rettet ved en senere anledning. Man vil også senere i prosessen se at dette blir korrekt i DGBuss sitt holdeplassregister.

Generer Referansetabell fra NSR

Ut fra Mastertabellen kan man generere en referansetabell som gjør det mulig å knytte Nasjonal holdeplass ID til benyttede Holdeplassnummer oppgitt i regtopp-format.

Se på referansetabellen:

Man kan se at det finnes mange ulike koblinger der de ulike leverandørene (HED, OPP osv) har benyttet ulike koblinger internt.

Oppdater stoppestedtabell med NSR-ID

For de som ikke allerede har NSR-ID’er i holdeplassregisteret, kan man la DGBuss skape denne knytningen. Her er resultatet fra en kjøring:

Husk at det dannes log-filer der man kan se hvilke endringer som har blitt foretatt. Denne vil automatisk bli vist (og i og med at det første gang er veldig mange endringer, kan det ta noe tid før bildet blir opprettet)

Kjører man rutinen en gang til, vil den vise 0 endringer. Kanskje vil man få endringer i NSR innen neste dag og da vil kun endringene bli oppdatert og meldt.

Figur: Legg merke til at alle disse holdeplassene har blitt tilordnet NSR ID. UTM nord og Øst-koordinater er tidligere lest inn via RT-importen. Longitude og Latitude er tom.

Oppdater fra NSR Master

Rutinen oppdaterer holdeplassregisteret fra NSR-Master-registeret. Navn, koordinater etc oppdateres. Under importen konverteres dessuten også UTM-koordinatene og disse blir erstattet. Foreløpig legges ikke Type overgang inn, da det ser ut til å være langt flere byttemuligheter definert hos NSR enn lokalt. Dette kan enkelt endres ved behov.

Log-filene viser alle endringer som har blitt foretatt.

Resultatet kan man også se i holdeplassregisteret:

Figur: Legg også merke til at man via egen knapp kan konvertere fra Lat/Lon til UTM i holdeplassbildet.

I mappen: NSRLog under pcp50, kan man kikke gjennom alle log-filer etter importen:

Forutsatt at man har valgt # 9 som visning av oppslagskolonne under Rutemodul, oppsett, vil man deretter kunne se også SI i ruteredigeringsbildet:

Oppdatere DGBuss

Hvordan oppdatere

Oppdatering til DGBuss 4.00: (Generelle endringer, samt forbedringer innen NeTEx) 1.11.2018 Det er ca 6 måneder siden forrige rapport fra NeTEx-arbeidet og annen info ang oppdateringer. Spesielt ang NeTEx-eksport:

Det meste av de påkrevde eksportfunksjonene var da på plass og det har vært få feilsituasjoner og lite behov for oppfølgning i mellomtiden.

Et av problemene som har dukket opp i 3.60, er at eksporter av store datamengder kombinert med flere unntaksperioder, har medført at systemet har gått tomt for minne før eksporten er gjennomført. Det ble løst ved å bruke 4.0 til eksport. Årsaken er at 4.0x er basert på en helt ny versjon av vårt utviklingsverktøy, og denne versjonen har en forbedret minnehåndtering som derved også har løst utfordringene vi hadde med store NeTEx-eksporter.

En feil behandling av unntaksdager oppdaget i NeTEx-eksporten:

Vi nærmer oss jul og for mange, en god del avvik fra normal produksjon. Naturlig nok dukker det da opp kombinasjoner av perioder og unntak som da blir benyttet for første gang. Ikke overraskende dukker det da også opp feil. Vi har bl.a. registrert at en unntaksdag (f.eks. en J7) på 26. desember, som etterfølger en normal J-periode, gir en feil eksport og søndagsturene uteblir for den 26. Problemet er funnet og rettet. Det er også en del andre mindre rettelser i eksportmodulen og vi distribuerer derved en oppdatering med bl.a disse rettelsene. Selv om det er lenge siden sist vi fikk rapport om avvik ifm NeTEx-eksport, blir dette neppe siste gang det er behov for korreksjoner og oppdatering av NeTEx-modulen.

Som vanlig anbefaler vi å starte med å ta en backup. (Bruk bkd.bat - rutinen som finnes i menu - katlogen)

Hent oppdateringen (filen: WDGBusUpdxxxx, velg den nyeste) via Dropbox:

https://www.dropbox.com/sh/p6116sgh4pxs998/AACwRgEswjPk_Zf8_SG8P6ica?dl=0

(Dersom lenken ikke lenger stemmer, ta kontakt med oss!)

Pakk ut hele innholdet til pcp50-katalogen(e).

Kjør konvertering og sortering.

I forbindelse med operativsystemoppdateringer får enkelte problemer med den gamle Backup-rutinen: BKD.bat som normalt ligger i menu – katalogen.

Benytt sjansen til å hente ned en oppdatert versjon av denne også!

Det er uttrykket ønsker om å fortsette utvikling av NeTEx-modulen:

Det velkjente begrepet «additionalNetworks» (eller også populært beskrevet som: separasjon av ruter pr. eier i NeTEx-data. Konkret betyr dette at vi nå kan lese og bruke flere authorities per codespace/datasett.)

Oppdatering fra NSR:

Det er ønske om å kunne koble seg opp mot NSR og hente over alle endringer innenfor det utvalg man har definert:

- Oppdatering pr punkt (evt egenskaper, naavn og posisjon).

- Nye punkter innenfor et avgrenset området (tidligere kunne man ha definere et utvalg av kommuner, men dette er også under endring og vi må finne den beste løsningen på dette)

- Kanskje et analyseverktøy slik at vi kan se i hvilken grad endringene har påvirket f.eks. definerte lenker 

 -  Eksport av vogntjenester
 -  Eksport av detaljtrasé

Gi gjerne beskjed dersom dere har andre behov for utvidelser eller endringer innenfor NeTEx-eksport

Versjonshistorikk

Siste utgitte versjon: DGBuss 4.00A72

DGBuss versjon 4.0

DGBuss versjon 4.00.A70

Desember 2018:

Ang NeTEx - eksport: I desember gikk VKT på et minneproblem når de skulle eksportere en lang tidsperiode som bestod av mange ruteperioder. Selv om vi har jobbet med minneproblematikken tidligere, viste det seg at eksportrutinen likevel gikk over det som var tilgjengelig av minne – med påfølgende krasj.

Etter nitidig gjennomgang av alle funksjoner i NeTEx-eksporten, har vi fått redusert minneforbruket til et minimum – noe som forhåpentligvis medfører at minneproblemet under NeTEx-eksporten er løst en gang for alle En bi-effekt er at rutinen derved vil kreve mindre ressurser mens den går.

4.00.A60 // 26. nov 18: NeTEx - rutiner skrevet om - stadige minne-forbedringer

4.00.A70 // 11. des 18: NeTEx: Feil:  ::ServiceJourneyNode-krasj, rettet

DGBuss versjon 4.00.A57

Oktober 2018:

Vi har lenge jobbet med versjon 4.0 av DGBuss. Denne nye versjonen er basert på en nyere versjon av utviklingsverktøyet vårt og dessverre har vi hatt noen gjenstridige bugs som har gjort at vi inntil videre ikke kunne distribuere de siste nyhetene. De fleste av disse er nå funnet og rettet og det nærmer seg at DGBuss 4.0 kan erstatte DGBuss 3.60. DGBuss 3.60 og DGBuss 4.0 kan fungere “side om side”. De benytter samme database og det skal ikke være noe problem å lage og lagre en rute i 3.60 for så å hente den opp for redigering i 4.0 og omvendt (forutsatt at DGB 3.60 er av nyere dato - altså at filstrukturen er oppdatert til siste versjon.

For å lette denne prosessen, har vi fra nå av begynt å distribuere 4.0 i samme oppdateringsfil som 3.60.

Kjørere man oppdatering til 3.60A111 eller nyere, er altså samtidig 4.0 tilgjengelig hos dere.

Oppdateringen finner man i Exe20-katalogen. Let fram WDGBuss.exe – filen, lag snarvei, endre denne til at den peker på pcp50-katalogen og derved er man klar til å kjøre!

Her er et utvalg av nyhetene man finner i 4.0:

Menystrukturen er justert.

Målsetningen har vært både å samle utgående og erstattede funksjoner/menypunkter under en egen meny Classic, samt å muliggjøre det å kunne arbeide med flere funksjoner samtidig.

- De nye grensesnittene ligger under Programmoduler.

caption

- De gamle (karakterbaserte) ligger under Classic-menyen:

caption

(Disse kan som hovedregel kun kjøres en av gangen)

Flere samtidige funksjoner:

Det at de karakterbaserte modulene, som kun kjøres en av gangen nå er samlet under ett meny-punkt, åpner bl.a. for at man kan kjøre flere funksjoner samtidig. F.eks. kan man åpne Grunnregistre selv om man har en rutetabell under redigering. Man kan kikke og endre holdeplassregister, destinasjonsskiltregister, merknadsregister etc uten å lukke ruten:

caption

Det at man enklere kan jobbe med flere funksjoner samtidig, medfører også at man f.eks kan ha en rute åpen, justere tilordning/endring av destinasjonsskilt underveis på turen, endre definisjonene på destinasjonsskiltene, trykke lagre-knappen (se kommende avsnitt) og samtidig ha holdeplass-skilt / -tavle-registeret åpent og teste resultatet helt ut til forhåndsvisning, utskrift eller .pdf.

Forbedret oversikt i ruteredigering.

Tidligere hadde man tre Tab’er: Hovedopplysning, Tur og Retur. Rutens «hovednavn / destinasjon leses inn og vises sammen med TUR og RETUR-begrepene i tab-grensesnittet.

Den gamle tab’en «hovedopplysning», er fjernet;

caption

I 3.60 er markørfeltet sort skrift på mørk blå bakgrunn som er vanskelig å lese. Som man kan se av grønn innringning; Nå gir markøren hvit skrift med mørk blå bakgrunn.

Andre visuelle forbedringer:

Beregningsfunksjoner / Modellkolonner / fargekoder:

Litt repetisjon innledningsvis:

Det er 2 typer Modellkolonner:

- Vanlig Modellkolonne: (Type ‘M’)

caption

Kolonnen må ha ‘M’ i første posisjon i Type-feltet (Bruk F8).

Deretter anbefaler vi å nummere Modellkolonnene fra 1 – 99.

Utgangspunktet for beregningen på turen defineres ved å sette ‘tiden’ til ‘9999’

Deretter definerer man relativ kjøreavstand i minutter som eksempelet viser.

Om man skal definere fotnoter, må disse settes i pos. 5.

Bruker man av og påstigningsbegrensinger (‘-‘, ‘+’ osv), settes dette i 6. posisjone, mens henvisningsbokstav til destinasjonsskiltendringer, settes i 7. pos.

Husk at avgangstidspunktet for beregningene (‘9999’) ikke trenger å starte på endeholdeplass. F.eks. i pendelruter kan dette defineres på et korrespondansepunkt inne i turen. Over avgangstidspunktet kan man sette tidene med ‘-‘ som fortegn, så regner man baklengs.

Bruker man Kolonne / ‘Beregn alle kolonner’ eller snarveien Alt+F3, vil man få oppdatert alle kolonnene som peker mot modellkolonnene ved type ‘m’ og tall. Tips, når man har laget en modellkolonne, kan også disse kopieres via høyre musetast

- Repeterende modellkolonne (Type ‘R’)

caption

Hensikten er å definere et avgangsmønster: F.eks. en avgang hvert 15 minutt fra 08:00 – 16:00. I utgangspunktet må man definere en avgangsmodell som vist over i ‘M’-kolonnene.

Kolonnen må imidlertid ha ‘R i første posisjon i Type-feltet (Bruk F8).

Deretter anbefaler vi å nummere Modellkolonnene fra 1 – 99. Kolonnenummereringen må ikke bruke samme nummer som evt. M-kolonner.

For å definere starttidspunktet, tjuvlåner vi vakt/skift – feltet i og med at dette likevel ikke er aktuelt å ta med over til de beregnede kolonnene.

Deretter benytter vi vogn-planfeltet til å definere siste minutt intervallet skal bregnes. Til slutt setter vi i30 (intervall 15 minutter) i Turnr-feltet:

caption

For å generere opp kolonner, går man via menyene Tabell / Repeterende modeller. Kusk at om man har generert opp et uttall avganger, satt inn vakt og turnummer, kan man endre detaljer i tidsforløpet på modellen og oppdatere med Alt+F3 og derved beregne nye passeringstider uten å overskrive turnummer etc.

Mer bevisst bruk av fargekoder:

Avgangshode: Klar grønn bakgrunn: Modellkolonne, lysere grønn: tilsvarende avgangskolonner, Skarp rød: Repeterende modell. Lysererød/rosa: De tilsvarende avgangskolonner.

caption

Bakgrunn i avgangsfot: Grønn: Alle dager, Blå: Hverdager (Dx67), Gul: Lørdag, Rød: Søndag, Grå: Avvikende dager (f.eks. Dx567 eller 5). De skarpe klammene omkring lørdagskoden i kolonne 8, betyr at kolonnen har en datobegrensning: En utfylt startdato og sluttdato. Man kan også legge merke til at man i denne installasjonen har valgt å vise disse fom og tom – datoene i 2. hodelinje, noe som gir god oversikt om man har mange turer med avvikende datogyldighet.

Lagre-knapp i ruteredigering

Det er også laget en Lagre-knapp i ruteredigering. (Da sparer man mye tid i forhold til å avslutte og lagre ruten for så å åpne den igjen):

caption

Samtidig ser man at ikonene er forbedret for å gi en mer beskrivende illustrasjon av funksjonene bak ikonet.

Ny forbedret dynamisk rutegrafikk:

Modulen er helt nyskrevet, og blant forbedringene det har gitt, er: Hurtigere oppdateringer, vinduet er justerbart i størrelse og plassering, grafikken oppdateres mens man jobber i ruten. Man kan velge ukedager som skal vises i diagrammet, man kan generere en fil som dokumentasjon – og mye mer.

caption

Ved F5, veksler man mellom detaljert og komprimert visning (Komprimert betyr at man da kun får rette linjer mellom turenes endepunkter, som er tilstrekkelig detaljering om det f.eks. er det å kombinere turer til vognløp man jobber med).

caption

Før et skarpt øye påpeker feilen: Teksten til venstre viser de 2 første destinasjonene i listen og ikke som det burde, de nødvendige byttepunktene, noe som må fikses.

Kalender tilgjengelig direkte fra ruteredigering.

Jeg har bistått en kunde med å legge inn juleavvik for en rekke ruter. Noe av det jeg stadig savnet, var å kunne kikke evt endre kjørekalenderen mens man stod inne i en rute. Resultatet er at det har kommet til en ny Cal-knapp i ruteredigering der man kan åpne og endre kjørekalenderen direkte:

caption

(Årsaken til at vi har valgt beskrivelsen Calender og ikke Kalender, er at snarveien Alt+K var opptatt og innarbeidet som kolonne-meny)

Slett innhold i tid-felt

I Ruteredigering har det lenge vært ønsket en funksjon for å raskt kunne slette deler av rutetidene innenfor en avgang.

Om man ønsker å slette en del avgangstider i en kolonne, kan man nå benytte F7 også i den nye ruteredigeringsmodulen.

caption

Se også Slett innhold ‘X’ / med snarveishenvisning F7 i kolonne-menyen.

DGBuss forberedt for å kunne håndtere planlegging med sekundoppløsning.

I forbindelse med nytt oppdrag med å levere system til Odense Letbane, var kravet bl.a. at man måtte planlegge med sekundoppløsning. Alle stopp må beregnes ut fra ankomsttid, avgangstid med en normal stopptid på f.eks. 18 sekunder. Utover dette skal det beregnes passeringstider ved mulige vendepunkter, inn og utkjøring til depot osv. Disse data skal eksporteres til driftssystemet TimeKeeper fra Efacec, samt over til Rejseplan og Rejsekort.

Arbeidet har pågått de siste 9 månedene og nå er vi ajour med planen.

Her kan man se eksempel på hvorledes Letbanen jobber i 4.0 med sekundoppløsning.

caption

Har dette betydning for de av dere som planlegger busstrafikk: Sannsynligvis ikke, men jeg vet at det er noen av dere som har fått melding fra Google via EnTur: Det er ikke mulig å kjøre 300 meter mellom stop A og B på 0 minutter…..

Kanskje blir det etter hvert påkrevd å planlegge i sekunder? Nye superbuss-traseer vil kanskje kreve høyere nøyaktighet? Metrobuss? Kommer det mer trikk (Bybaner) i Norge? Greit å vite at DGBuss er forberedt!

Hvem jobber i DGBuss?

Systemoperatører og de som kjører eksportene, kan ha behov for å vite om noen og evt. hvem som jobber i DGBuss.

Fra den nye ruteoversikten, kan man nå trykke på en egen knapp (Aktive) for å se hvilke ruter som er under bearbeiding av hvilke operatører.

caption

Feilrettinger oppsummert:

Begge versjoner:

Tidligere hadde man via Classic ruteredigering mulighet for å produsere tavler direkte ved å gå via holdeplassoversikt, tavler etc. Dessverre hadde dette tendens til å krasje når man deretter ønsket å forlate ruten uansett om man skulle avbryte uten lagring, eller med lagring. Dette er må forbedret.

4.0: NeTEx-eksport for store datasett krever mye minne. Enkelte har fått out of memory-meldinger. NeTEx-eksport i 4.0 – versjonen fungerer mye bedre og vi kjenner ikke til at noen har fått minneproblem gjennom den nye DGBuss.

Et utvalg av andre feilrettinger og justeringer i 3.60 de siste 6 mnd:

A90: Import av vognnummer fra .vpl-filen i RT-eksport henter kun 4 siste siffer fra vognnummeret.

A91: Ny eksport av holdeplasskiltregister til .csv-fil (fordi operatør trengte en oversikt)

A92: Feil i Hstus-eksport: manglende lenkelengde var blank, ble justert til 0

A93: RT-eksport: Datoer etter 2020 ble feil i dagkodestreng

A94: Forbedringer på Repeterende modellgenerering

A95: Nytt valg om det er 3 eller 4 av posisjonene fra vognplanimport som skal benyttes

A96: Vognplanimport: Kan nå også håndtere alfenummerisk linjenummer

A97: Finjusteringer på holdeplasskilt for å kunne få fler avganger pr time uten konflikt

A98: Justering etter ny spec på Hastuseksport

A99: Mulighet for å velge å se datobegrensning: FOM og TOM-dato i hodelinje 2 i ruteredigering

A100: Forbedring av import for områdekalender (FynBus)

A102: Forbedring på vognplanimport (alfanumerisk lokalrutenummer)

A103: Holdeplasskilt: Forbedring vedr formattering av merknadstekster

A104: Innlesning av destinasjonsskiltregister for oppslag i rute er forbedret slik at disse blir oppdatert med nye og endret innhold

A105: Feil i Netex-eksport der ruten forandrer forløp i ny versjon (sommer), er forbedret (men ikke perfekt). Men nå OK mot Entur

A106: Manglende definert destinasjonsskilt i rute, er kun påkrevet i NeTEx – eksport og varsles nå kun der.

A107: I eksportene: Varsel om at trasedetaljer mangler, varsles ikke lenger dersom fra og til-stopp er lik (altså rute med definert ventetid på stopp).

A108: Forbedringer på krasj ved lagring av rute (classic) etter holdeplassutskrift forsøkt forbedret.

A109: A108 ytterligere forbedret.

A110: Ny funksjon F7: blank felt i ny ruteredigering

A111: NeTEx-eksport: Forbedring der unntaksdag følger etter unntaksperiode ikke gav avgang.

I 4.0 er de samme rettelser/forbedringer foretatt, men også følgende er utført:

Forbedret menystruktur: Bedre gruppering.

DGBuss versjon 3.60A89

Februar 2018:

Siden forrige oppdatering, er det jobbet med følgende:

- Feil ved sammenkobling av likefomede turer ble komprimert til én er fikset

- Det er nå mulig å kjøre med oppdelt installasjon med ulike kjørekalendre. Hver installasjon defineres med prefiks før eksport og alt kopieres sammen og .zippes.

- Fotnoter definert på NRI-dialekt: p = påstigning osv. feilet. Dette er nå fikset.

- Dersom et turforløp var eksakt likt i tur- og returretning, ble ikke eksporten korrekt. (Kunne oppstå dersom man hadde snudd en rute fra f.eks. vinter til sommerrute). Rettet. Samtidig blir da turmønstrene mer logisk nummerert (fra 1 i begge retninger).

- Dersom # - feltet inneholdt f.eks. V-H osv ble det uoverensstemmelse i eksporten. Dette er fikset, men bruk av annet enn 0-9 i #-feltet frarådes likevel.

- Merknadsfeltene / fotnotene fra rutetabellene er utvidet til 120 karakterer

- NeTEx- skjemaene er oppdatert til versjon 1.08 / 1.1 og order på elementet PointOnRoute er implementert (Etter anbefaling fra EnTur)

DGBuss preview kommende versjoner

DGBuss versjon 5x

Rutekalkulator

Formålet med denne nye funksjonen er å gi brukeren et kjapt og enkelt estimat over kostnad / kostnadsendring ved en rute.

Som grunnlag for kalkulasjonene må man via menyene: Administrasjonskostnad / rutekostnad definere ulike kostnadselementer:

caption

Man kan differensiere både timekostnad og km-kostnad på hverdager, lørdager og søndager

I f.eks. P-versjonen av rute B3, vil dette gi følgende resultat:

caption

Her har man altså mulighet til å sette inn erfaringsverdier og ut fra dette foreta et kjapt og enkelt estimat for hva en rute koster pr uke – og evt over året (der man ikke tar hensyn til periodeversjoner).

Om man ønsker å sette timekostnaden til 0 og km-kostnaden til f.eks. 33 kr flatt, er det også en mulighet, men vi tror samtidig at en kombinasjon av timepris og km-pris med differensiering på hverdag, lørdag og søndag vil gi mulighet for å definere en prismatrise som gir et godt estimat.

Vi har for øvrig også diskutert å differensiere ytterligere ved å gi en pris på skoleavganger og en annen pris på øvrige avganger, noe som ville kunne gi utslag i enda mer nøyaktig estimat over et år (ved å benytte et fast antall skoledager som grunnlag).