DGBuss:Versjonshistorikk: Forskjell mellom sideversjoner
| Linje 356: | Linje 356: | ||
[[Fil:DGB40Kjørekalender.png|none|600px|caption]] | [[Fil:DGB40Kjørekalender.png|none|600px|caption]] | ||
''(Årsaken til at vi har valgt beskrivelsen Calender og ikke Kalender, er at snarveien Alt+K var opptatt og innarbeidet som | ''(Årsaken til at vi har valgt beskrivelsen Calender og ikke Kalender, er at snarveien Alt+K var opptatt og innarbeidet som 'K'olonne-meny, derved ble 'C'alender slik at det ble samsvar med snarveie Alt+C'' | ||
Sideversjonen fra 1. jun. 2019 kl. 05:12
Det jobbes for tiden med større endringer. Bl.a må vi pga stadig større installasjoner utvide kapasiteten på stoppunkter fra dagens maksantall på 10.000. Kommende versjoner kan håndtere inntil 1 mill stoppunkter. Endringen er såpass gjennomgripende i systemet at det må testes grundig i alle sammenhenger før vi kan distribuere de siste og oppdaterte versjonene ut til driftsmiljøer.
Gjeldende utgitte versjon: DGBuss 4.00A72
DGBuss versjon 4.0
DGBuss versjon 4.00.A85
Innvalg / vedlikehold av destinasjonslisten i rute.
Vesentlige endringer:
I forbindelse med installasjoner med mange stoppunkter, samt overgang fra maks 10.000 til maks 1. mill stoppunkter, oppdaget vi både feil og ytelsesutfordringer:
Innvalg av stoppunkt respekterte ikke holdeplasser med internnummer større enn 10.000 -> fikset.
I stedet for at stoppunktlisten leses inn til minne ved første åpning av en rute, er rutinen flyttet til oppdatert av DGBuss. Dersom du har endret innhold i stoppunktregisteret, leses det inn igjen ved lukking av stoppunkt-tabellen. Dette kan også benyttes for å få fornyet listen om du vet at andre har gjort tilføyelser eller endringer.
I installasjoner med store stoppunkttabeller (over 5.000?), opplevet man at det å åpne et destinasjonsfelt for endringer, gikk relativt tregt. Om man ikke hadde tålmodighet til å vente på markøren, kom systemet på etterskudd og var derfor vanskelig å jobbe effektivt. Årsaken var at stoppunktlisten – som har en vesentlig dimensjon, ble tung for systemet å behandle.
Fra A85 har vi gjort vesentlige endringer. Dropdown-listen er nå i utgangspunktet tom. Det betyr at man ikke kan få opp liste over mulige stoppunkter ved å verken trykke på dropdown-symbolet eller ved Alt-Pil ned som tidligere.
Som erstatning har man følgende funksjonalitet:
Ved tomt felt:
Trykk Enter for å åpne for endring. (Feltet åpner momentant). Skriv så mye av stoppnavnet du ønsker, (f.eks. ‘hamar s’) og avslutt med Enter.
Du vil da få opp en begrenset forslagsliste, kun alle stoppunkter som starter med ditt valgte begrep (nå også case insensitivt):
Velg så fra listen med piltaster og avslutt med Enter.
Sjekk at oppslagskolonnen bekrefter at du har valgt riktig stoppunkt.
Dersom du ønsker å få opp hele listen over stoppunkter: Trykk Enter i tomt felt. Da vil du få følgende valg:
Velger du OK, forblir feltet blankt og du hopper til neste destinasjon. Dersom du velger ‘Liste’ går det et par sekunder – så får du opp den komplette stoppunktlisten. Du kan så navigere til nærmeste startbokstav ved å trykke bokstaven (listen respekterer kun en bokstav).
Dersom du ønsker å endre stoppunkt innenfor et holdeplassområde: (Eksempelvis at man ser man har valgt feil stoppunkt under Hamar skysstasjon) Åpne feltet for endring med Enter, bruk deretter piltast opp eller ned for å åpne listen og velg et nytt stoppunkt med Enter.
Systemet har dessverre ingen mulighet for å velge forrige stoppunkt som utgangspunkt i listen.
Andre mindre endringer:
Ved beregning av alle kolonner (Alt+F3). Dersom en avgang mangler tidspunkt i startcellen, stopper systemet for å innhente dette. Der var det tidligere nødvendig å klikke OK med venster musetast. Dette er endret til at man kan benytte Enter.
Visning av traseer i dGIS:
'Vis Rute i dGIS' fungerte ikke -> fikset
Endring av 'hint' i kolonne-heading og fot:
Tidligere har alle utfyllinger i tur-spesifikasjon fremkommet av hintet i kolonne-headeren.
Dette var litt ulogisk fordi f.eks. begrensning i dato-gyldighet på tur vises i Foten (F.eks. slik: ' [ Dx67 ' ), mens hintet for foten viste kun ' Dager: Dx67 '.
Nå er rutinen endret slik at alle utfylte spesifikasjoner vedrørende gyldighet, slik som Dager, Skoledag / SkolefrIdag, datobegrensning og kalender-kode, vises i fotens hint. Hintet for kolonneheaderen vil kun vise øvrige utfyllinger.
Eksempel på hint for en kolonnefot:
DGBuss versjon 4.00.A71 - A84
I perioden desember 2018 - mai 2019 er det utført en vesentlig videreutvikling av DGBuss og dGIS.
Her er en foreløpig beskrivelse av endringene:
Legg merke til at mange av forbedringene vil være en del av vedlikeholdsoppdatering, mens andre forbedringer vil bli tilbudt som en oppgradering. Den endelige fordelingen mellom disse, er ikke endelig bestemt.
Her følger et utdrag av nyhetene:
A. Følgende vil (sannsynligvis) bli en del av neste vedlikeholdoppdatering:
A1. Dokumentasjon:
1. Nytt WEB-basert system for bruker- og systemdokumentasjon: (WikiMedia). Dokumentasjonen er oppdatert og inneholder også mange nye kapitler som egner seg for selvstudier. Dokumentasjonen er direkte tilgjengelig via Hjelpemenyen i DGBuss, men man kan også lese den direkte i en nettleser.
A2. Rutemodulen DGBuss:
2. Pålogging først, gir operatørinfo i vindusrammen.
3. Brukerdefinisjoner er forbedret. Brukere kan nå også få skreddersydde menyer (fjerne unødige menypunkt fra hovedmenyen). Mer:
4. Forbedrede logg-funksjoner der: På- og avlogging av bruker, samt endringer på de enkelte tabellene registreres.
5. Import fra RegTopp 1.2 er kraftig forbedret. Kan nå vise til nær 100% gjenoppbygging av database på grunnlag av eksempelsett av kollektiv-data på RT 1.2nri. Mer:
6. Automatisert opprettelse av nødvendige, nye holdeplass-skilt ut fra rutetabell (tidligere meget arbeidskrevende oppgave).
7. Lenkemodulen er forbedret og bedre synliggjort fra ruteredigering med egen knapp.
8. Lenkemodulen har egen rutine for å beregne kjøretider i 3 ulike rush-nivåer. Disse beregnes ut fra virkelig hastighetsbegrensning og kjørelengder beregnet av dGis
9. Visning av ikke-lenkede ruter i dGIS: Som kvalitetssikring under registrering av nye ruter: (f.eks: Har vi valgt riktig stoppunkt innen et holdeplassområde?) , er det nå mulig å vise og sjekke rutetraseer i dGIS før man oppdatere/oppretter lenkene.
10. Det er utviklet konverteringsrutiner for koordinater mellom ulike koordinatsystem; Det er nå mulig å jobbe f.eks. i UTM 32, men under eksport konvertere og skrive til ønsket koordinatsystem.
11. Endelig kan man fra ruteoversikt starte ruteredigering ved dobbeltklikk eller ved å markere ruten og trykke Enter (og ikke kun ved F2 som i dag)!
12. Ved opprettelse av ruter: Km-kolonnen fylles nå ut med standardverdien 0.
13. Lenkeavstander kan hentes fra databasen og oppdatere Km-kolonnen med korrekte avstander
14. Markøren er ikke lenger sort på blå, men hvit på blå (hadde for dårlig kontrast).
15. Nytt system for vedlikehold av filstrukturer innebygget i programmet (prg-katalog overflødig). Blir automatisk varslet ved nødvendig konvertering.
16. Oppslag holdeplass fra ruteredigering: Betydelig raskere.
A3. Gis-modulen: dGis
17. Man kan nå kombinere inndata fra UTM32 og 33. Dette har medført at det er mulig å lese fagdata (b.a. svingbegrensinger) slik at automatisert lenking foreslår større andel korrekte lenker og prosessen speedes opp betraktelig.
18. Forbedring på lenkefunksjon: Løsning for velge retning på kurver som starter og slutter i samme punkt Mer
19. Forbedring på lenkefunksjon: Mulig å korrigere korteste veg og få beregnet ny korteste veg.
20. Utskrift av kart utsnitt.
21. Visualisering av ruter før de er lenket og detaljdefinert (Nyttig for å avsløre feil valg av stoppunkter før man oppretter lenkene)
22. Forbedring ifm tema/flatekart inklusiv tekst og punkt (håndtere ukjente objekttyper samt vis/skjul).
B. Vi kan også tilby en rekke nye opsjoner / oppgraderinger i DGBuss og dGIS som kan leveres etter avtale:
1. Pålogging kan skje ved å koble Active Directories og Single Sign On til brukeren i DGBuss for å overflødiggjøre egen pålogging . Mer:
2. Samtidige rutiner: Det er nå mulig å jobbe med mange rutiner samtidig, også flere ruter av gangen.
3. Kalenderfunksjonalitet: Utvidet til å kunne definere ulike kjørekalendre for ulike drifts- og fysiske områder. Alle variantene kan overstyre skole og skolefridager, samt datogyldighet pr tur. Mer
4. NSR-support: Det er laget rutiner for automatisert oppdatering fra NSR, enten brukerstyrt eller f.eks. nattlig oppdatering. For brukere som registrerer nye eller endringer i NSR, er det i tillegg bygget støtte for momentan innhenting av alle stoppunkt innenfor gjeldende holdeplassområde. Mer
5. Brukerdefinerte felt på alle grunnregistre. Brukeren kan selv ta i bruk og navngi/definere type på tilleggsfelt. Mer
6. Kostnadskalkyle på rute-nivå. Enkel og rask rutine som baserer seg på både km- og time- kostnader på hverdager og helgedager. Endres forutsetninger, f.eks. endrer dagtyper eller legger om en kjørelenke, vil ved rekalkulasjon se differansen i km, timer og kostnader. Mer
7. Utvidelser ifm tidligere begrensing: DGBuss ble opprinnelig laget for å kunne håndtere inntil 10.000 stoppunkter. Flere av våre kunder er i ferd med å nå dette taket. Dette var en gjennomgripende begrensning, men nå er systemet oppdater slik at man kan håndtere inntil1 mill stoppunkter. Samtidig er antall stoppunkter pr holdeplassområde økt fra 10 til 100.
8. Nytt designverktøy for rapporter basert på FastReport.
9. Man kan opprette en mal-kolonne og opprette/kalkulere denne med forslag til kjøretider ut fra parametere. Grunnlaget for beregningene er avstand og gjennomsnittlig hastighetsbegrensning (fra dGIS) korrigert med en faktor + en stopptid i sekunder. Mer
10. Visning av flere ruter i kart samtidig, den sist viste blir rød, de andre «grået» ut (alle med de kjente varianter av linje og tur-visningene)
11. Visning av alle linjer som passerer et stopp
12. Endret vegnett: Hjelpefunksjon for å vise lenker som ikke lenger følger veinettet etter kartoppdatering.
13. dGis: OSM som kartgrunnlag
14. Planlegging med sekundoppløsning (Nødvendig ifm bybane-planlegging / Metro?)
15. Spørring på gyldige turer pr dato.
16. Kalenderfunksjon som viser gyldighet for rute og tur.
Sist men ikke minst:
C. Til høsten kommer DGuss i MSSQL – versjon, status:
17. Det er utviklet konverteringsrutiner slik at det er mulig å konvertere en rutedatabase fra Foxbase-databasen til MSSQL – Ingen nyregistrering er nødvendig.
18. I DGBuss er vi langt på vei klar med nye databasekoblinger, slik at vi kan skifte fra Microsoft Foxbase databasert til MS-SQL. Hente, endre, skive ut og lagre er klart til visning.
19. De viktigste funksjonene i dGis støtter nå MSSQL
20. «SQL-Light»: For de som er fornøyd med dagens database, vil det likevel være en mulighet til å sette opp en rutine som dumper DGBuss-databasen til MSSQL (tidsstyrt eller brukerstyrt) slik at datagrunnlaget kan være tilgjengelig til andre formål (datavarehus?)
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 'K'olonne-meny, derved ble 'C'alender slik at det ble samsvar med snarveie Alt+C
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).
Kjørekalender: Større fleksibilitet
Kjørekalenderfunksjonaliteten utvides slik at man kan definere skoledags- og fridagsmønsteret uavhengig i ulike områder eller rutekategorier.
Les mer:
[[1]]
