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.
- De gamle (karakterbaserte) ligger under Classic-menyen:
(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:
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;
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’)
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’)
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:
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.
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):
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.
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).
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:
(Å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.
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.
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.
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:
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:
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).
