Dienstregeling Hengelo 29 januari - 9 juni 2001

[Dre]

Dag allen,

De afgelopen dagen heb ik (al kleine oefening voor het maken van een dienstregeling) de rest van de dienstregeling 2000/2001 gemaakt. De bij de simulatie geleverde dienstregeling loopt van 28 mei 2000 t/m 28 december 2000, daarop heb ik het vervolg gemaakt, welke in dit geval loopt van 29 januari t/m 9 juni 2001.

DOWNLOAD LINK

Belangrijkste wijzigingen t.o.v. de bij de simulatie geleverde dienstregeling:

• De spoorlijn Zutphen-Hengelo is voorzien van assentellers van het type Az-L90-4 voor detectie van lightrail en voertuigen met schijfremmen. Daardoor wordt op dit baanvak de treindienst uitgevoerd met treinstellen DM'90. Het baanvak Hengelo-Oldenzaal is in deze periode niet geschikt voor de detectie van DM'90 (daar wordt tot 1 juli 2001 slechts van laagfrequente spoorstroomlopen gebruik gemaakt). De treinserie 7200 (Zutphen-Oldenzaal) is daarom gesplitst: De serie 7200 rijdt enkel tussen Zutphen/Delden en Hengelo en tussen Hengelo en Oldenzaal rijdt de serie 17200, welke nog steeds door treinstellen DE-III (Plan U) wordt uitgevoerd.
  

In principe geldt dat de serie 7200 in Hengelo aankomt/vertrekt van spoor 302a. De serie 17200 komt aan/vertrekt volgens dienstregeling van spoor 303b (maar het staat de trdl natuurlijk vrij kopspoor 311 te gebruiken waarvoor het oorspronkelijk bedoeld was).

• Het treinenpaar 1148/1149 is komen te vervallen, eigenlijk was dit treinenpaar per 1 november 2000 reeds komen te vervallen (omdat EXPO 2000 in Hannover toen haar deuren sloot). Als gevolg daarvan rijdt trein 1719 vanaf Almelo in het normale treinpad van de serie 1600/1700.
  

• Officieel vanaf 20 april 2001, maar in de dienstregeling ook voor de voorliggende periode opgenomen, de vuiltrein tussen de Vagron locatie in Groningen (nabij Groningen Losplaats) en de bruinkoolcentrale Schwarze Pumpe (nabij Spremberg). Omdat de grensovergang Nieuweschans in de simulatieperiode wegens ombouw gesloten is vind dit vervoer via Zwolle, Deventer en Bad Bentheim haar weg naar Duitsland. Vrijdag's gaat een volle afvaltrein naar Bad Bentheim (trein 69900), waarna de wagens zondags leeg terugkomen (trein 69901). De treinen worden getrokken door één van ACTS' 1200'en die na het afleveren van de trein in Bad Bentheim in Deventer overstaan voor de volgende trein.
  

----------------------------------------------------------------------------

BELANGRIJK: Om gebruik te kunnen maken van de dienstregeling moet een licentiesleutel aanwezig zijn!

Om de dienstregeling te kunnen spelen dien je de volgende stappen te nemen:

1. Download het bestand en sla deze op een willekeurige plaats op de harde schijf op (bijvoorbeeld C:\Program Files\Signalsoft\Post T Hengelo\).
   
2. Start het programma 'Post T Hengelo' en ga in het menu naar de optie 'instellingen'.
   
3. Wanneer er een licentiesleutel is ingegeven zal nu het menu 'simulatie' vertoont worden waar ook de instellingen m.b.t. de dienstregeling kunnen worden gewijzigd. Zet een vinkje bij de optie 'gebruik eigen dienstregeling'.
   
4. Klik op 'zoeken' achter het balkje onder de titel 'waar laden op de harde schijf' en navigeer hier naar de map waar het mdb-bestand bij stap 1 is opgeslagen (in dit geval C:\Program Files\Signalsoft\Post T Hengelo).
   
5. Klik op 'zoeken achter het balkje onder de titel 'voorkeursdienstregeling' en kies hier voor 'Hengelo_Dienstregeling_2001.mdb' en klik vervolgens op 'ok'.
   
6. Start de simulatie door in het hoofdmenu te klikken op 'nieuwe simulatie'.
   

Dan nog 3 huishoudelijke mededelingen:

1. De dienstregeling is gebaseerd op de dienstregeling die verzorgd word door Leo (Hobbyman), zonder zijn werk was deze dienstregelingsvariant er natuurlijk nooit geweest.
   
2. naast alle wijzigen in dienstregelingstechnische zin zijn ook alle wijzigingen door opmerkingen die in dit topic geplaatst zijn (up to date tot 3 december '11) meegenomen in deze database.
   
3. Enige op- of aanmerking met betrekking tot de dienstregeling mag in dit topic geplaatst worden. Mocht de opmerking zich betrekken tot een oneffenheid in de database, dan zal ik dat zo snel mogelijk aanpassen. Ook aanvullingen die in het topic m.b.t. de orginele database worden gedaan en verder niet direct op deze database betrekking hebben zullen worden meegenomen voor een eventuele update van deze database.
   

[TjoeTjoe]

Hallo Dre,

allereest natuurlijk complimenten en dank voor je werk.

Ik zal er zeker mee aan de slag gaan.

Positief kritisch nootje: je doet jezelf tekort door de Metatable gegevens niet aangepast te hebben. Je mag best je naam daar in het veld "author" zetten

En voor het mooie ook het veld "Version" aanpassen. Daar staat een zogenaamde GUID, waarmee je een unieke identificatie van jouw dienstregeling maakt. Op deze SignalWiki pagina staat een link naar createguid.com . Deze site genereert een GUID die je zo over kan nemen in het Version veld. Het voordeel hiervan is dat bij het opslaan van de Simulatie (SIM bestand) deze identifier ook bewaard wordt. Hiermee kan een gebruiker nooit een opgeslagen SIM gebruiken met een "verkeerde" (lees: niet bijhorende) dienstregeling.

Maar nogmaals dank voor je werk. Helemaal top

Erwin

[TjoeTjoe]

Hallo Dre,

Ik kon het toch echt niet laten om gisteravond even met jouw drgl te gaan simuleren.

Wow, dit geeft echt leuke hoofdbrekens m.b.t het knoopje in Hgl.

Naast de nodige poespas in Almelo, vooral de 7000-serie, moet je als trdl nu wel heel goed in de gaten houden wat en wanneer je qua-rijwegen instelt rondom Hengelo.

Al met al is er nog meer dynamiek op dit paneel te beleven.

Helemaal super.Nogmaals dank voor je inzet

Erwin

[Hobbyman]

Hallo Dre,

Dat is een mooi stukje werk geworden. Vooral de materieel wijzigingen maken het extra interessant.

En historisch gezien ook compleet juist.

Overigens, hoe langer ik naar de oorspronkelijke dienstregeling kijk des te meer raak ik ervan overtuigd dat de gegevens stammen van de dienstregeling mei1999- mei 2000, met als extra toetje de 1148/1149. En dan heb ik dus het verkeerde spoorboekje gekocht

Dat lijkt ook bevestigd te worden door de tabel SpecialDates met gegevens van 1999 en 2000.

Als dat gewenst is, kan ik de tabel aanvullen met de gegevens van 2001.

Technisch vraagje: Als ik de volgende update vrijgeef, moet je dan alle wijzigingen handmatig overnemen in jouw drgl?

Of ben je in staat om jouw records te importeren in mijn drgl ?

Als voorbereiding op het zichtbaar worden van DarkTerritory's in Hgl, ben ik op dit moment namelijk bezig met alle rangeerbewegingen voor het dieselmaterieel (tanken in hengelo, splitsen en combineren in Es en Hgl, afrangeren naar spoor 36,37 en achter 4c)

En dat is best wel ingrijpend.

Groetjes,

Leo

[signalsoftRC]

wat je ook kunt doen is de "periode" te gebruiken in de drgl. daarmee kun je de oriignele 1999-2000 drgl naast de 2001 drgl in een tabel hebben.

je kunt heel veel doen met "kopieren & invoegen" ook bij datums!

[TjoeTjoe]

wat je ook kunt doen is de "periode" te gebruiken in de drgl. daarmee kun je de oriignele 1999-2000 drgl naast de 2001 drgl in een tabel hebben.

je kunt heel veel doen met "kopieren & invoegen" ook bij datums!

Ja, dat is inderdaad een hele goede manier.

Twee gevalletjes van 'maar ..':

- de periode-functie werkt Niet in de huidige versie van Hengelo. Dre heeft over dit onderwerp al eens eerder een topic in Vragen & Antwoorden geopend. De conclusie in dat topic was dat het zoals gezegd in Hgl nog niet werkt

In Asd werkt het wel, dus met de update van Hengelo is dit punt ook opgelost.

- het lost het probleem waar Leo op wijst namelijk niet op. Dre probeert zijn timetable synchroon te houden met de officiele drgl (welke door Leo wordt onderhouden). En dat is, waar Leo eigenlijk min of meer op wijst, inderdaad een hele grote uitdaging. Zeker gezien het feit dat de meeste een Auto-numbering ID gebruiken. Slim en handig, maar onhandig op het moment dat iemand zijn drgl op wil blijven baseren met natuurlijk de nodige toevoeging. Op het moment dat in de bron-database records toegevoegd worden, heeft de eigenaar van de afgeleide database al meteen een enorme klus te doen. De bron zal namelijk voor de nieuwe records, dankzij auto-numbers, ID's gebruiken welke in de afgeleide database mogelijk al bestaan. Zie hier slechts één van de complicaties.

Ik heb wel wat ideeën over hoe een en ander toch uitvoerbaar is. Bij interesse bij Leo en Dre wil ik daar best wat meer in technisch detail over uitweiden.

Erwin

[signalsoftRC]

De autoID is alleen maar belangrijk bij de "predecessor" van de rangeeropdrachten. Voor de rest wordt de autoID NIET gebruikt als referentie!

[TjoeTjoe]

Ik heb geleerd dat je de Chef nooit mag tegenspreken, dus ga ik dat ook niet doen

Er is hier sprake van een Babelonische spraakverwarring denk ik.

Goed. We gaan dan maar de technische details in.

Hoewel ik Dre, Leo en Richard niet hoef uit te leggen hoe de diverse tabellen in de Timetable mdb aan elkaar hangen, zo nu en dan toch wat aanvullende info zodat ook andere geinteresseerden het nog een beetje zouden kunnen volgen.

Het *probleem* is dat Dre zijn database (database , behoudens het stukje drgl tussen Delden-Hengelo en Hengelo-Oldenzaal, zoveel mogelijk synchroon wil houden met de (master)database van Leo (database A).

Ikzelf heb eenzelfde probleem met mijn scenario voor Gelsenkirchen, waarbij ik de *ingebouwde* drgl wil aanhouden, maar wel met enige eigen toevoegingen.

Waar het al direct mis kan gaan, is wanneer in database B een nieuwe trein wordt toegevoegd. Deze trein krijgt automatisch een unieke ID toegewezen, dankzij het feit dat dit veld op Auto-numbering is gezet. Dit ID is overigens ook de verwijzings-ID voor de bij deze nieuwe trein horende rangeeropdrachten.

Als in master-database nu ook een trein wordt toegevoegd, dan zijn de rapen eigenlijk al gaar. Deze nieuwe trein zal ook een automatisch ID toegewezen krijgen, en groot is de kans dat het ID hetzelfde is als dat voor de nieuwe trein in database B. De eigenaar van database B zal dus telkens heel goed moeten controleren of er geen conflicten op gaan treden. En dat werkt door tot in de rangeeropdrachten.

Ikzelf denk dat de beheerder van database het zich in zekere zin makkelijker kan maken door ...

- in zijn database in alle tabellen de ID velden met Autonumbering te wijzigen in velden met Number, maar dan wel met de voorwaarde dat het een Unieke waarde moet zijn

- voor alle eigen toevoegingen, in welke tabel dan ook, voor ieder nieuw record een ID invullen die theoretisch gezien, qua-waarde dermate hoog is dat het zeer onwaarschijnlijk is dat dit nummer ook in de master-database voor zal komen. Bijvoorbeeld: ieder eerste *eigen* record per tabel laten starten met het nummer 10001. De rest natuurlijk opvolgend.

Met wat handigheid voeg je een routine toe aan de Default value voor het ID (max[iD] + 1 en voila, geeft een zelfde soort resultaat als auto-numbering)

Hierbij wil ik meteen een belangrijke opmerking maken. Voor de rangeeropdrachten per trein geldt dat de eerste opdracht altijd het laagste ID moet hebben. De tweede de op een-na-laagste etc

- eventueel een kolom in elke tabel waar je wijzigingen (gaat) maken toevoegen, bijvoorbeeld "Gewijzigd" genoemd. Met die kolom kan je als database B -eigenaar bijhouden waar je eventueel wijzigingen hebt gemaakt. In Dre's zijn voorbeeld kan ik me voorstellen dat hij de originele 7200 treinen op Skip heeft gezet, en daarvoor in de plaats nieuwe records heeft aangemaakt (ben te lui om te verfiëren of dit ook daadwerkelijk het geval is)

- persoonlijk denk ik dat originele records uit de master database ongemoeid gelaten zouden moeten worden in database B, behoudens dan het Skip veld. Maw, wijzigen van drgl details van een trein uit de bestaande masterdatabase A doe je door het record te kopieren naar een nieuwe record (ID > 10001) en het origneel zet je op Skip.

In kort de acties voor database B eigenaar na verschijnen update master-database A, als je deze werkwijze aanhoudt:

- kopie trekken van master database, dat wordt de nieuwe versie van database B

- auto-numbering van ID velden in de diverse tabellen op Number zetten. Waarde van ID moet wel gedwongen worden een Unieke waarde te zijn.

- de 10001+ velden uit de tabellen van de vorige versie van database B kopieren naar de tabellen van de nieuwe database B. (juiste volgorde van "over"kopieren is uit mijn hoofd Vehicles, ConsistTemplates, Physics,Timetable, MovementOrders en StabledTrains)

- de met Gewijzigd aangemerkt records in oude database B controleren op bijv waarde Skip, of wat je er ook mee hebt gedaan en deze wijzigingen voor die records doorvoeren in database B

(hier zit een adder onder het gras in het geval de master database op record ID niveau overhoop gegooid is)

OK, ik zie de bomen door het bos al bijna niet meer.

Denk dat deze werkwijze moet kunnen gaan werken.

Eerlijksheidshalve moet ik zeggen, dat ik dit principe nog moet doortesten voor mijn EG scenario/timetable

Erwin

[Hobbyman]

Een zeer goede en complete analyse van de problemen die kunnen optreden.

Mijn opmerking was inderdaad ingegeven door het feit dat er ook veel wijzigingen zijn die niet in het forum zijn genoemd.

Vooral de rangeeropdrachten laten niet toe om de nieuwe records zo maar even te importeren in de originele tabel.

Dan gaat onherroepelijk het verband in het veld predecessor verloren !

De beschreven methode is een goede manier om dat te voorkomen.

Misschien is het de moeite waard om deze werkmethode vast te leggen in de WIKI ?

De niet benodigde records zijn door Dre verwijderd uit de database.

Wijzigingen in het origineel doorvoeren in zijn database zal dus geheel handmatig moeten gebeuren.

Van alle kleine wijzigingen heb ik niet altijd een aantekening gemaakt, dus daar kan ik ook geen volledig overzicht van maken.

Enne, niets doen is ook een oplossing. De huidige stand van zijn database vwb de andere treinen functioneert immers goed.

Groetjes,

Leo

[signalsoftRC]

als ik, zeg maar, 30 treinen overkopieer van tabel 1 naar tabel 2, worden ze gewoon onderaan toegevoegd en krijgen een nieuwe autoID.

als in die 30 treinen er DEZELFDE treinen zouden zijn die al in tabel 2 waren, moet ik de periode bewerken, of de weekdag of the techID met een tagje verzien. Zodat je ze uitelkaar kunt houden. het beste is een kolom te maken met "PatternCode" zoals in Eg. (een colom die NIET door de sim gebruikt wordt)

Daarmee kun je ze lekker uitfilteren.

Met de rangeeropdrachten (die een verwijs hebben naar zaken in Tabel 1) moet je bij het kopieren natuurlijk oppassen. Dit omdat TrainTechID "natuurlijk" een referentie is (intern in MS Access een nummer dat verwijst naar de autoID. in MS Access zie je dat lekker als een textje natuurlijk)

Daar moet je met 't handje eraan... en goed nummeren.

Maar als je vooraf de trainTechID goed had "getagged", gaat dat vlot.

Dann MOET je in de rangopdrachten de predecessors invullen voor die 30 treinen.

Hebben we in keulen ook gedaan.

Is mogelijk, je moet wel nauwkeurig werken.

[Wim Vos]

Hallo allemaal,

Ik heb problemen als ik de nieuwe dienstregeling voor Hengelo wil downloaden.

De link verwijst bij mij naar de pagina van Google Docs en ik weet niet hoe het dan verder moet.

Weet iemand wat ik nu moet doen.

Alvast bedankt voor de reacties,

Wim

[TjoeTjoe]

De link verwijst bij mij naar de pagina van Google Docs en ik weet niet hoe het dan verder moet.

Weet iemand wat ik nu moet doen.

De IT-policy op mijn werk weerhoudt me ervan om dit even voor je testen alvoren te antwoorden, dus dan maar in mijn geheugen graven

Als je op die Google Docs link klikt, verschijnt er rechtsbovenaan een knop met Download oid

Klik er op en er wordt een mdb-bestand gedownload

Noot: misschien eens met Dre overleggen of de timetable op mijn webspace gehost mag worden. Of, misschien wil Richard hem zelf hosten.

Erwin

[Hobbyman]

Ja, je moet wel 2 keer kijken, voor je dat ontdekt.

Een logische plaats waar je kijkt is midden onder in het beeld, maar daar staat niks.

Echter rechts boven in het beeld staat een knopje "Download 2 Mb"

Wedden dat er dan van alles gaat gebeuren als je daar op klikt met de muisaanwijzer.

[TjoeTjoe]

De beschreven methode is een goede manier om dat te voorkomen.

Misschien is het de moeite waard om deze werkmethode vast te leggen in de WIKI ?

Als ik tijd en zin heb zal ik in het Developer hoekje hier wat over neerkrabbelen. Zal ik pas doen als ik voor mezelf heb bewezen dat het een werkbare methode is.

Eerlijk gezegd denk ik dat het werkbaar is, maar ik wil bewijzen zien

De niet benodigde records zijn door Dre verwijderd uit de database.

Ah ok. Nou ja, kan op zich geen kwaad. Heeft bijna hetzelfde effect als het Skip veld aanzetten.

Enige is dat verwijderen, zeker als Auo-numbering toegepast wordt, het een min of meer onomkeerbare actie is

Wijzigingen in het origineel doorvoeren in zijn database zal dus geheel handmatig moeten gebeuren.

Van alle kleine wijzigingen heb ik niet altijd een aantekening gemaakt, dus daar kan ik ook geen volledig overzicht van maken.

Voor de werkwijze welke ik beschreven heb, is het niet zo zeer van belang dat jij een Change Log bijhoudt.

Dat geldt wel voor diegene die zijn werk op jouw database heeft gebaseerd, en in bestaande records wijzigingen doorvoert (wat in Dre's database dus blijkbaar niet het geval is)

Met wat handig query werk zijn eventuele verschillen denk ik wel te traceren. Men moet er dan wel heel zeker van zijn dat de query/queries zijn werk goed doen

Enne, niets doen is ook een oplossing.

Alsjeblieft geen Griekse toestanden hier ... LOL ....

De huidige stand van zijn database vwb de andere treinen functioneert immers goed.

Dat kan ik alleen maar beamen

Erwin

[Wim Vos]

Beste allemaal,

Ik heb het bestand inmiddels gedownload; ik moest eerst even inloggen in Google Docs en daarna verscheen er rechtsbovenaan een knop met Download oid.

Bedankt voor de adviezen.

Wim

[TjoeTjoe]

ik moest eerst even inloggen in Google Docs

Heel bijzonder. Dat heb ik namelijk niet hoeven doen.

In principe doe ik niet met *Google docs* en wil het ook niet.

Ikzelf heb het bestand kunnen downloaden zonder in te moeten loggen of accounts aanmaken etc. (als dat wel zo geweest was had ik dit aan me voorbij laten gaan)

Maar goed, je hebt hem binnen, en daar was het je om te doen

Erwin

[Dre]

Kort antwoord even (in de baas z'n tijd), uiteraard mag dit bestandje gehost worden op je site Erwin, geen probleem (graag zelfs, dan bij alle downloads voor de simulaties mooi bij elkaar op 1 site). Google Docs heb ik alleen gebruikt omdat het een makkelijke plek is om iets neer te zetten zonder poespas (een berg reclame, 1 minuut wachten voor je kunt downloaden, etc.) Inloggen op Google Docs klinkt ook mij vreemd in de oren, ik heb de instellingen zo gewijzigd dat iedereen zonder inloggen het bestand kan downloaden, om het eenvoudige feit dat ik niemand wil verplichten om een Google-account aan te maken (ik heb er geen aandelen van ofzo en ben zelf ook niet echt gecharmeerd dat je overal moet inloggen om wat te krijgen.

Vanavond zal ik even op de rest van de reacties een antwoord geven, dat is iets teveel om nu te doen.

Groeten,

Andreas

[Dre]

Technisch vraagje: Als ik de volgende update vrijgeef, moet je dan alle wijzigingen handmatig overnemen in jouw drgl?

Of ben je in staat om jouw records te importeren in mijn drgl ?

In principe worden mijn records in de tabel TimeTable in de door jouw geupdate database geïmporteerd (dus niet andersom). De toevoegingen in de tabel MovementOrders voeg ik handmatig toe, in verband met de verwijzingen naar ID_Predecessor die gekopieerd wordt uit de oorspronkelijke tabel en dus niet meer verwijst naar de 'nieuwe' ID van de oorspronkelijke opdracht die vóór de huidige opdracht uitgevoerd moest worden.

Als voorbereiding op het zichtbaar worden van DarkTerritory's in Hgl, ben ik op dit moment namelijk bezig met alle rangeerbewegingen voor het dieselmaterieel (tanken in hengelo, splitsen en combineren in Es en Hgl, afrangeren naar spoor 36,37 en achter 4c)

En dat is best wel ingrijpend.

Daar heb ik voor mijn database uiteraard ook over nagedacht. Nu is het nog niet zichtbaar, maar voor de sporen die onderdeel uitmaken van Tc1, Tc2 en Hgl4c zit er wel degelijk een opstelplan in, dat in sommige punten afwijkt van de bezigheden die daar volgens de oorspronkelijke database afspelen.

wat je ook kunt doen is de "periode" te gebruiken in de drgl. daarmee kun je de oriignele 1999-2000 drgl naast de 2001 drgl in een tabel hebben.

je kunt heel veel doen met "kopieren & invoegen" ook bij datums!

Zoals gezegd hebben de kolommen "PeriodStart" en "PeriodEnd" (nog) geen functie in de Hengelo-simulatie. Dat zou dus opleveren dat tussen 05:35 en 05:50 tegelijk bijvoorbeeld trein 7209 en 17209 op spoor 303b worden geladen. Dat moeten we natuurlijk niet hebben, dus heb ik het maar opgelost door mijn database geheel apart te houden van de orginele gegevens. Een optie is inderdaad dat ik mijn database update door de records van de oorspronkelijke 7200-serie weer toe te voegen (of mijn records in de originele database invoeg) en bij deze records de skip-functie gebruik.

- het lost het probleem waar Leo op wijst namelijk niet op. Dre probeert zijn timetable synchroon te houden met de officiele drgl (welke door Leo wordt onderhouden). En dat is, waar Leo eigenlijk min of meer op wijst, inderdaad een hele grote uitdaging. Zeker gezien het feit dat de meeste een Auto-numbering ID gebruiken. Slim en handig, maar onhandig op het moment dat iemand zijn drgl op wil blijven baseren met natuurlijk de nodige toevoeging. Op het moment dat in de bron-database records toegevoegd worden, heeft de eigenaar van de afgeleide database al meteen een enorme klus te doen. De bron zal namelijk voor de nieuwe records, dankzij auto-numbers, ID's gebruiken welke in de afgeleide database mogelijk al bestaan. Zie hier slechts één van de complicaties.

Maar als je de records uit 'mijn' database naar de brondatabase overbrengt (en dat bij een update elke keer herhaald) dan hoeft dat geen problemen op te leveren. 't is even wat werk met de rangeeropdrachten, maar daar kom ik wel uit.

Waar het al direct mis kan gaan, is wanneer in database B een nieuwe trein wordt toegevoegd. Deze trein krijgt automatisch een unieke ID toegewezen, dankzij het feit dat dit veld op Auto-numbering is gezet. Dit ID is overigens ook de verwijzings-ID voor de bij deze nieuwe trein horende rangeeropdrachten.

Als in master-database nu ook een trein wordt toegevoegd, dan zijn de rapen eigenlijk al gaar. Deze nieuwe trein zal ook een automatisch ID toegewezen krijgen, en groot is de kans dat het ID hetzelfde is als dat voor de nieuwe trein in database B. De eigenaar van database B zal dus telkens heel goed moeten controleren of er geen conflicten op gaan treden. En dat werkt door tot in de rangeeropdrachten.

In feite worden mijn treinen elke keer 'nieuw' toegevoegd in de geüpdate dienstregeling. De 'unieke' ID is dus enkel in die betreffende database uniek en wordt niet overgedragen naar een nieuwe database, want daar worden die treinen gewoon geïmporteerd en krijgen vanzelf een unieke ID volgens de nieuwe database. Aangezien het veld 'Predecessor_ID' niet automatisch wordt aangepast voeg ik de rangeeropdrachten apart in. Ik heb namelijk een tabelletje achter de hand waar in de tabel MovementOrders de kolom Predecessor_ID leeg is gelaten (behoudens de verwijzing naar de eerste rangeeropdracht, aangezien die -1 is).

Ah ok. Nou ja, kan op zich geen kwaad. Heeft bijna hetzelfde effect als het Skip veld aanzetten.

Enige is dat verwijderen, zeker als Auo-numbering toegepast wordt, het een min of meer onomkeerbare actie is

Zover ik kan nagaan wordt de Auto-nummering niet aangepast, een vergeven ID blijft behouden.

Voor de werkwijze welke ik beschreven heb, is het niet zo zeer van belang dat jij een Change Log bijhoudt.

Dat geldt wel voor diegene die zijn werk op jouw database heeft gebaseerd, en in bestaande records wijzigingen doorvoert (wat in Dre's database dus blijkbaar niet het geval is)

Met wat handig query werk zijn eventuele verschillen denk ik wel te traceren. Men moet er dan wel heel zeker van zijn dat de query/queries zijn werk goed doen.

Ik heb inderdaad (voor mezelf) een Change Log waarin vastligt welke treinen verwijdert, toegevoegd of aangepast zijn, rangeeropdrachten, TrainUnits (welke treinnummers behoren bij elkaar), Vehicles (draagwagens voor afzetcontainers zaten standaard niet in de Vehicles tabel).

Wanneer de "DarkTerritory's" zichtbaar zijn én de functie PeriodStart/End werkt (dus na de update), dan pak ik de database die Leo op basis daarvan levert erbij en kopieer mijn dienstregeling daarin. Uit mijn hoofd is er één bestaande trein aangepast, dat zijn de tijden van trein 1719, aangezien trein 1149 niet meer rijdt. De in dit topic gedane opmerkingen leiden ertoe dat ik bij de volgende versie de 'oude' serie 7200 niet verwijder, maar de skip-functie gebruik. Na de update van het programma krijgen de beide dienstregelingen dan een PeriodEnd en PeriodStart. Dan zit dus de gehele dienstregeling 2000/2001 erin en is deze grotendeels speelbaar zoals deze periode zich toentertijd heeft afgespeeld.

PeriodEnd/PeriodStart zal ik daarna ook gebruiken om extra treinen toe te voegen die slechts op 1 enkele dag rijden. Ze zullen wel iets regelmatiger voorkomen dan oorspronkelijk het geval was in 2000, maar om ze nu voor elke week standaard te gaan toevoegen, dat gaat iets te ver... Ook zal er dan een open dag scenario in een weekend gepland zijn. Dat kan beter in een aparte database (omdat er toch materieel in komt dat niet in de huidige database vertegenwoordigt is, zoals 1500, DD-IRM en SGM). Ook werden de toen gloednieuwe Lint's tussen 28 mei en 9 juni 2001 ingezet tussen Almelo en Mariënberg (aangezien de de beide Blauwe Engelen van Connexxion niet meer inzetbaar waren, de 180 is op 1 april '01 definitief terzijde gegaan na een brandje en de 186 kwam in mei '01 niet door de veiligheidskeuring en keerde pas met ingang van de dienstregeling 2001-'02 terug.

Dat zijn allemaal nog zaken die ik in de aangepaste database ga invoeren.

[Hobbyman]

Dat ziet er goed doordacht uit.

Er is denk ik nog 1 aanvulling nodig:

Ik denk dat ook de rangeernummers (4072xx, 4172xx, 4272xx, etc) van de serie 7200 moeten worden voorzien van een "skip".

Er is immers een gerede kans dat we beiden dezelfde rangeernummers uitdelen.

En dan gaat jouw rangeernummer wellicht de verkeerde rangeeropdrachten uitvoeren.

Als de velden Periode_Start en Periode_End (weer) werken, kunnen de oude treinen worden voorzien van de periode ? mei 1999 tot 28 jan 2000.

Daarmee ontstaat dan een database die historisch correct weergeeft hoe de dienstregeling in 1999/2000 werd uitgevoerd. Of is het beter om de beide databases apart te houden ?

[TjoeTjoe]

... uiteraard mag dit bestandje gehost worden op je site Erwin, geen probleem (graag zelfs, dan bij alle downloads voor de simulaties mooi bij elkaar op 1 site)...

En aldus geschiede ... hij staat er bij als download

Erwin

[TjoeTjoe]

Dat ziet er goed doordacht uit.

Helemaal mee eens.

Er is denk ik nog 1 aanvulling nodig:

Ik denk dat ook de rangeernummers (4072xx, 4172xx, 4272xx, etc) van de serie 7200 moeten worden voorzien van een "skip".

Er is immers een gerede kans dat we beiden dezelfde rangeernummers uitdelen.

En dan gaat jouw rangeernummer wellicht de verkeerde rangeeropdrachten uitvoeren.

Ja daar zou je wel eens heel erg gelijk kunnen hebben. Ondanks het feit dat de MO's met de HardID aan de juiste trein hangen, bestaat het risico dat als beide treinen met dezelfde SoftID op dezelfde dagen rijden, de sim nou net de verkeerde pakt. Goede opmerkingen Leo

Als de velden Periode_Start en Periode_End (weer) werken, kunnen de oude treinen worden voorzien van de periode ? mei 1999 tot 28 jan 2000.

Daarmee ontstaat dan een database die historisch correct weergeeft hoe de dienstregeling in 1999/2000 werd uitgevoerd. Of is het beter om de beide databases apart te houden ?

Dat zou natuurlijk heel mooi zijn en optimaal benutten van geboden functionaliteit zijn

Erwin

[Dre]

Er is denk ik nog 1 aanvulling nodig:

Ik denk dat ook de rangeernummers (4072xx, 4172xx, 4272xx, etc) van de serie 7200 moeten worden voorzien van een "skip".

En dan gaat jouw rangeernummer wellicht de verkeerde rangeeropdrachten uitvoeren.

Dat spreekt voor zich natuurlijk, het zit niet zozeer in de rangeeropdrachten (aangezien ik de rangeeropdrachten via de TimeTable-tabel invoer, dus altijd bij de correcte trein), maar om het simpele feit dat er dan twee treinen geladen zouden worden. In mijn database wordt doordeweeks bijvoorbeeld trein 7209 niet geladen vanaf Tc1, om het simpele feit dat er slechts 1 Plan U de hele dag tussen Hgl en Odz pendelt (ik zit erover na te denken om deze af en toe te laten wisselen met een stel dat op tractie blijft staan en in een vast patroon omgewisseld wordt). Die is dus voor trein 17207 (rangeernummer 401707) al van Tc1 gekomen.

Als de velden Periode_Start en Periode_End (weer) werken, kunnen de oude treinen worden voorzien van de periode ? mei 1999 tot 28 jan 2000.

De dienstregeling 1999/2000 liep van 30 mei 1999 t/m 27 mei 2000. Zover ik kan nagaan verschilt de dienstregeling 1999/2000 niet zo heel veel van de dienstregeling 2000/2001. De grootste wijzigingen (de stoptrein uit Zwolle (serie 7900) rijdt door naar Enschede, de stoptrein (serie 7200) uit Zutphen rijdt door naar Oldenzaal i.p.v. Enschede en de stoptrein uit Deventer (serie 7000) rijdt slechts tot Almelo i.p.v. de gehele dag naar Enschede zijn in de voorgaande dienstregelingen ('98-'99 en '99-'00) doorgevoerd. Het zal alleen in samenstellingen van met name de serie 1600 en 1700 hebben gezeten, die wijzigt eigenlijk zo'n beetje elk wijzigingsblad. Sinds de opening van de Zuidtak bij Amsterdam wordt de serie (2)1600 echter consequent met ICM gereden. (bij de serie 1700 was dat, vanwege de splitsing van het Gvc- en Rtd-deel in Utrecht, als sinds de buitendienststelling van Mat '54 bij de ingang van de dienstregeling '94-'95).

Qua goederentreinen (nummers en ladingen) komt de dienstregeling echter overeen met het de dienstregeling 2000/2001 t/m het wijzigingsblad van 16 december 2000. Mijn dienstregeling vormt daar een vervolg op. Momenteel is de periode 16 december '00 - 28 januari '01 niet vertegenwoordigd omdat de serie 7200 toen nog doorgaand Odz-Zp reed.

Daarmee ontstaat dan een database die historisch correct weergeeft hoe de dienstregeling in 1999/2000 werd uitgevoerd. Of is het beter om de beide databases apart te houden?

Van mij mag het best samen gaan. Mijn dienstregeling geeft de dienstregeling vanaf wbl 16 december 2000 t/m einde dienstregeling 2000/2001. Het tableau geeft de situatie weer zoals deze tussen oktober '99 en april '01 was. Vóór oktober 1999 bestond tussen Enschede Drienerlo en Enschede nog overweg 49.826 (Auke Vleerstraat), waarvoor onder de eindknoppen nabij sein 216/218 een stop/door-schakeling was aangebracht (en men de P-seinen in het rechterspoor vanaf Hengelo nog een beetje verplaatst heeft, maar dat is niet zichtbaar). Vanaf april 2001 is de OTC-sectie Almelo Bedrijvenpark aansl. (wissel/stopontspoorblok 801) vervangen door een wissel met stopontspoorblok (441) met 3 seinen (440, 442 en 444) en is het tableau daarop aangepast (later dat jaar hebben zich ook nog aanpassingen voorgedaan omtrent de oostzijde van Enschede i.v.m. reactivering van het spoor naar Gronau.

Ja daar zou je wel eens heel erg gelijk kunnen hebben. Ondanks het feit dat de MO's met de HardID aan de juiste trein hangen, bestaat het risico dat als beide treinen met dezelfde SoftID op dezelfde dagen rijden, de sim nou net de verkeerde pakt. Goede opmerkingen Leo.

Dan houdt ik daar uiteraard rekening mee, dank alvast voor het mee vooruit denken, dat scheelt een hoop corrigeerwerk achteraf. Uiteindelijk krijgen we dan:

• Simulatie zoals ie nu is, voor de periode 28 mei 2000 - 16 december 2000, verlengd tot 27 januari 2001
  
• Toegevoegde simulatie voor de periode 28 januari 2001 - 9 juni 2001, waarin nog wat zaken worden toegevoegd omtrent Aml-Mrb
  
• Een aantal "exclusieve" ritten die op slechts 1 specifieke simulatiedag plaatsvinden (o.a. de overbrenging van de Lint treinstellen van Syntus van Salzgitter via Bad Bentheim naar Amersfoort, een NVBS-excursie naar Bad Bentheim, waarvoor in Hengelo nog een leuke line-up gemaakt wordt) of veranderingen in de geplande dienstregeling (werkzaamheden tussen Aml en Hgl, waardoor de 7900 slechts Zl-Aml rijdt en de 1600/1700 in Almelo keert en de 2300 via Go/Zp wordt omgeleid)
  
• Een weekend lang een open dag gebaseerd op de open dag van 2 oktober 1999 (
  kun je op YouTube een impressie krijgen van wat er toen te doen was) met als voorgerecht de dag ervoor:
  .
  

Dan worden de mogelijkheden van de simulatie toch totin de puntjes benut!

[Hobbyman]

Dan blijft de vraag over of het de moeite waard is om de materieelomloop van de serie 16/1700 aan te passen ?

Voor de drgl 1999/2000 in de huidige database is het vooral op za/zo een fantasie, omdat de oorspronkelijke database daar geen uitsluitsel over gaf. Elke za/zo bleven er veel te veel stellen in Es staan en dat kan natuurlijk niet.

Dus met enige fantasie op za/zo een deel van de stellen niet aangevoerd naar Es en het teveel afgevoerd met diverse treinen uit Es.

De materieelomloop van de serie 16/1700 voor 2000/2001 is tot in detail bekend.

Dat completeert het historisch juist zijn van de simulatie.

Omdat de drgln identiek zijn stoort het niet in de drgl 1999/2000.

Het is alleen een bult werk, ik denk al gauw enkele maanden.

[Dre]

De geplande (de treinen die in het spoorboekje voorkomen) treinen verschillen niet tussen de dienstregeling 1999-2000 en 2000-2001. De materieelomlopen verschillen echter per dienstregeling (daarbinnen zelfs per wijzigingsblad). Zolang het maar enigszins weergeeft zoals het in de betreffende dienstregeling had kunnen gaan, dan is dat voor de simulatie al heel wat (zit er overigens zoveel verschil tussen de dienstregeling 1999/2000 en 2000/2001?). Mocht het tot in detail bekend zijn, dan is het uiteindelijk jammer om er niets mee te doen (zeker als uiteindelijk Post T Deventer ook het levenslicht ziet, dan heb je een compleet doorgaande dienstregeling voor het treinverkeer tussen Apeldoorn en Enschede voor de dienstregeling 2000/2001. Voor Dv hoef je namelijk geen onderliggende stukken te hebben (de baanvakken Deventer-Zutphen en Apeldoorn-Zutphen kenden geen goederenverkeer, en het goederenverkeer op het baanvak Rijssen-Apeldoorn/Zwolle is feitelijk het doortrekken van de goederenpaden vanaf Hengelo richting Amersfoort en passagierstreinen staan in het spoorboekje [materieel van de overige treinseries die wél in Deventer, maar niet in Hengelo (serie 3600, 17000 en 17800) kwamen is bij mij bekend] alleen LM-ritten Dv-Zp en de bediening van Apdvam (via Dvge/Zlr) kunnen kleine problemen opleveren, maar in de grootspoorwereld is nog wel iemand aanwezig die dienst heeft gedaan op Post T Dv).

Zelf wil ik nog wel even achterhalen welke weekenden er daadwerkelijk buitendienststellingen zijn geweest die betrekking hebben op de simulatie. Een weekend met buitendienststelling is sowieso wel in te bouwen, maar het is natuurlijk altijd leuk om dat te plannen in een weekend dat NS Railinfrabeheer daadwerkelijk bezig is geweest met een van de baanvakken (dat kan ik me, aangezien in die tijd assentellers op Zp-Hgl en later Hgl-Odz werden geïnstalleerd zomaar voorstellen (sowieso is het niet aannemelijk dat er in een jaar tijd geen enkel buitendienststellingsweekend is geweest in het gebied dat door Post T Hgl bediend wordt).

Overigens ben ik even achter de samenstellingen voor de serie 2300 en 370 aan gegaan (aangezien daar nu nog een samenstelling 1700+1 ICR-A+1 ICR-AB+7 ICR-B rijdt die ogenschijnlijk wordt gedriehoekt na aankomst in Hoofddorp Opstel). Die is:

2340, 2342, 2344 en 2346: 1700/1800+Aim260.1+ARkimbz262.2+Bimz264.2+Bim263.3+Bimz264.7+Bim263.3+Bimdz268.4

2341, 2343, 2345 en 2347: 1700/1800+Bimdz268.4+Bimz264.7+Bim263.3+Bimz264.7+Bim263.3+Bimz264.2+ARkimbz262.2+Aim260.1

[1e klas zat altijd aan de Amsterdamse zijde, eventueel kunnen de namen ook vereenvoudigd wordt tot UIC-X-A, UIC-X-AR en UIC-X-B(D).

370 en 371 heb ik wat van gevonden, maar ik moet even nakijken of welk deel van trein 370 uit Praag doorging naar Amsterdam en welk deel naar Dortmund. Dat was over 't algemeen een bovengenoemde stam versterkt met 3 ligrijtuigen (die kwamen uit Praag met koersrijtuigen voor Dortmund, vervolgens gingen die er in Berlin Ostbahnhof af en werden ze vervangen door een 'normale' 2300-stam voor de rit naar Schiphol/Hoofddorp Opstel. De rijtuigen kwamen van NS Internationaal en waren één Bcvmh, één WLAB174 en een Bcmh. Ik moet alleen nog even in de archieven om te kijken of die nu vóór of achter de de reguliere stam geplaatst werden.

Verder heb ik voor mezelf mijn dienstregeling even opnieuw in de huidige database (stand 13 november + gemeldde oneffenheden eruit) ingevoegd en de skip-functie toegepast (en ze een onderscheidend Train_ID_Tech meegegeven (de ene keer is het 7220_2000, de andere 7220_2001). Wanneer de PeriodStart en PeriodEnd-functie werkt dan kunnen de 'oude' 7200 voor de periode t/m 28 januari 2001 'ontskipt' worden en is er in beginsel een speelbare dienstregeling voor 2000/2001. Nu nog even sleutelen aan Aml-Mrb (aangezien de DE-II'tjes daar in 2001 eigenlijk op de laatste benen liepen en Syntus vanaf mei de spitstreinen 31013-31022-31017-31026-31051-31060-31055-31064 met Lint reed (tussen 2-4-2001 en 27-5-2001 waren de spitstreinen verbust omdat DE-II 180 op 1-4 terzijde ging na een brandje te Vz).

[Dre]

Overigens heb ik net wat zaken aangepast in de bestaande dienstregeling:

• PathTemplates voor LM-ritten. Als je in de huidige dienstregeling (die met de sim meegeleverd wordt) de sim bijvoorbeeld op een doordeweekse dag om 6:43 uur laadt dan begint trein 77022 op spoor 338, omdat er geen Path is ingevoerd in de dienstregeling en de sim dus gaat berekenen waar de trein zou kunnen zijn. Als ik 'em een eigen pad (Hengelo4c-Almelo4a_0 van SPAWN_HGL4C_0 naar A66T) geef, dan loopt het allemaal perfect en komt trein 77022 op spoor 304c terecht. Datzelfde heb ik voor de treinen van Aml richting Hgl gedaan.
  
• Toevoegen van doorkomsttijden, sommige treinen (m.n. goederentreinen en LM-ritten) hebben geen doorkomsttijden te Hengelo Oost, Enschede Drienerlo, Almelo de Riet en Borne. Dat heeft 3 voordelen:
  

1. De weergave in het tijdtafelscherm (opgeroepen met F12) is analoog aan de weergave op het drgl-kaartje van de betreffende machinist (daarop staan alle dienstregelingspunten, ongeacht of er gehalteerd wordt of niet)
   
2. De simulatie is beter in staat te 'berekenen' waar een trein is tussen twee stations.
   
3. Voor minder ervaren trdl's biedt het tevens de optie om via eerder genoemd tijdtafelscherm te zien 'waar' de trein daadwerkelijk is op een bepaald baanvak (er is nogal een verschil tussen 'ergens tussen Almelo en Hengelo' en 'ergens tussen Borne en Hengelo').