DGBuss: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.