[roeter]

Hello Dave,

that description exactly matches the definition of 'train' as a column in a timetable file.
In an extreme case, it may even be that none of the cars which are part of the train at the start, are still part of that train when it reaches the end. Other units may have been added, and the original units have been taken off, but it's still the same train.
Another thing that has to be realised is that before these cars are formed into this train, and after they have been taken out of this train, they may well be part of other trains.
The importance to OR in all this is to realise that a 'consist' and a 'train' are two completely different items. A train is formed of conist(s) and a consist will form a train, but it is not a one-to-one relation.

Regards,
Rob Roeterdink

[YoRyan]

Note that as I've defined it, a "train" is just any formation of railcars instantiated into the simulator. Including loose consists waiting for pickup.

As the two of you might understand it, a "train" is more like a scheduled service that operates from point A to point B. It might make sense to introduce a "service" abstraction to represent this instead of using train or car attributes. Each car in a train would contain an index to none, one, or more services.

 steamer_ctn, on 12 August 2020 - 09:51 PM, said:

For clarity, will each CAR have a separate attribute denoting its authorised speed?

Thus the TRAIN authorised speed could be determined by the minimum speed of the lowest rated CAR in the composition. This would be more in keeping with how I understand that railways determine the speed of a particular train composition.

Yes, this is how I envision that attribute working. Speeds would be defined in the .eng, .wag, or future rolling stock file.

 steamer_ctn, on 12 August 2020 - 09:51 PM, said:

Having said this, I suspect that different car speed limits may also apply depending upon track or operational conditions. ... So perhaps the way to handle this is to have an attribute in CAR which OR can use to calculate the authorised speed limit automatically (In this case the TRAIN speed attribute would not be set by the user). If for some reason that it is necessary to override the default CAR values, then the user could set the TRAIN attribute.

A train-specific maximum speed would be good idea, too.

[NickonWheels]

 YoRyan, on 13 August 2020 - 09:12 AM, said:

Yes, this is how I envision that attribute working. Speeds would be defined in the .eng, .wag, or future rolling stock file.

Good intension as two-axle wagons (which you just can´t find in North America) mostly have lower permitted speeds than bogie wagons.

[conductorchris]

A way to think about this is as a chain of authority.

A train exists under the authority of the dispatcher and the dispatcher gets authority because the train is in the timetable or the decision is made by management to run it. The path come from the dispatcher and the train itself generally comes from timetable or management decision.

An engineer drives the train under the authority of the conductor. The conductors authority is because they have the authority of the train.

Rolling stock and combinations of rolling stock exist because they were put there, because the conductor decided to put them there. On the railroad, it isn't scripted in advance which track will be used or in what order; those are decisions of the conductor (or maybe the yardmaster who is somewhat like a conductor for a yard).

Then there is the poor shipper. Skyline Computer's activity generator tries to include them. On the real railroad it seems they aren't relevant at all and have no authority and thus turn to trucks instead.

Or the passenger. Professional train simulators do model boarding and alighting time (number of passengers times speed of boarding/alighting as determined by equipment and platform type).

[Genma Saotome]

Rob, let's make sure we're talking about the same thing> I'm thinking of something I will call a train, that is a transportation service between points A and B on a that starts its journey on a particular date at an approximate time. To accomplish this transportation service one or more groups of units (consists, blocks, whatever) move under the authority given that train. These groups will be coupled together most of the time but when the collective stops subsets may leave this association and other units may join it (there is an event there which may need some software to handle). Some of the groups may travel as separate collectives (called sections) and so long as they are recognized as representing the same train they move under the same authority, even tho they may be separated by a considerable distance.

The train, as a transportation service may originate outside an OR modeled route, terminate outside of that route, or originate and terminate within that route (IOW where A and B are located is probably not germaine if they are off route}.

If the above is correct then what I see as missing from the OR code is the events of associating or de-associating units from the collective that moves... and associating one of more of those collectives to represent the train.

I think these events could be important for signaling purposes. For example, if a train is given the authority to be at DEF and the collective representing that train is split into 4 parts occupying 4 different sections of track, the train has to have the authority to be on all 4 sections.. When that part of the collective has it's relationship severed the authority granted that train ends.
===============


One implication is likely to be a train having authority over an area rather than the individual tracks it's units occupy at any given time.
===============

One way to think of the first section, above, is the idea of a product design vs. making the product itself. The design represents the goal, the work order to make that product is an event.

As for the overall collection of units, one way to think of those is a club and it's individual members. In our case the clubs are consists/blocks/groups of the same and the members are the individual units on wheels.

[roeter]

 conductorchris, on 13 August 2020 - 09:38 AM, said:

On the railroad, it isn't scripted in advance which track will be used or in what order; those are decisions of the conductor (or maybe the yardmaster who is somewhat like a conductor for a yard).

That's all US freight again. I wish people stopped saying "that's how my railway does it so that's how railways work".

Here, in many European countries, most services are ordered by diagrams. Engines, multiple units, sets of coaching stock - all are ruled by diagrams which determine what that equipment will be doing this day, and often the next couple of days as well. When a piece of equipment has to be stabled between duties, the road where it will be stabled is determined by its diagram such that it will no be 'locked in' by some other equipment which has its own diagram. Those stable requirements are worked out by the same people as who work out the diagrams and no conductor or whatever has any influence on that.
Such diagrams have been around for ages. Diagrams are one of the least known aspects of the railroad world, but personally I find them very fascinating.
It's quite possible diagrams don't exist in US freight traffic. But OR is not intended for US freight only.

Regards,
Rob Roeterdink

[roeter]

 Genma Saotome, on 13 August 2020 - 11:18 AM, said:

Rob, let's make sure we're talking about the same thing

Dave, I very much think so.

Quote

If the above is correct then what I see as missing from the OR code is the events of associating or de-associating units from the collective that moves... and associating one of more of those collectives to represent the train.

What about the $attach, $detach, $pickup and $transfer commands in timetable mode? That's exactly what these commands do - adding or taking away items to or from that collection and, if required, adding them to another collection or describing them as a new collection.
I know there are many differences in operation between US freight and European passenger workings. Presently, the timetable mode is specifically set up for the latter and in that sense is an almost perfect representation of those workings. Not surprisingly, as the concept is based on the Working Timetables (WTT) as were and are still used in the UK and which lay down all that happens on the railway in quite some detail.
In that sense they may not quite match the US freight environment where more is done on 'as needed' bases and more is determined 'on the spot' rather than detailed in documents. By the way, in that sense it is interesting to note that the documents known as 'timetables' in the US are completely different and bear no relation to the UK "WTT" whatsoever. Perhaps that's part of the confusion about what 'timetables' are.

I agree, though, that such functions are missing in activity mode. That's why I haven't run any activities for many a year now.

Quote

I think these events could be important for signaling purposes. For example, if a train is given the authority to be at DEF and the collective representing that train is split into 4 parts occupying 4 different sections of track, the train has to have the authority to be on all 4 sections.. When that part of the collective has it's relationship severed the authority granted that train ends.

That's allready implemented. For instance, take a train which attaches to another train, and the total then forms a new train. If the path for the new train does not cover all sections the train now occupies, the system will extend that path backward to include these additional sections. Similarly, if a train is split and therefor now no longer occupies certain sections, those sections are taken away from that train and allocated to the new train. A section which is occupied by both trains is indeed allocated to both.

Regards,
Rob Roeterdink

[Genma Saotome]

Rob, this is good!



A brief history of US (and quite possibly Canadian) train operations: Timetable only was used everywhere until around the 1970's when one railroad introduced Timetable and Train Order. Timetables used train class (1st thru nth) and direction of travel to establish priority of movements -- class over direction was the norm (i.e., direction of movement only came into play when meets of opposing trains were of the the same class). The train order dynamically altered the timetable and telegraphs communicated that change to all stations not-yet-arrived-at by any affected train As electric signals came in they only supplemented T7TO by their indications conveying safety information. That changed in the 1930's as CTC was developed. With CTC teh idea of class and direction was depreciated... the signal aspects controlled everything; Some trains retained a representation in the timetable, almost always passenger trains, and the time shown was always earliest possible time for departure, entirely for the convince of boarding passengers. Once moving their class was irrelevant. Under CTC, most trains were classed as Extras and whatever they did while moving was controlled via the signal system; Whatever they did while stopped was controlled by the conductor.

Railroads were divided between yards and everything else. Movement in yards was under the authority of the Yardmaster; everything was under the authority of the dispatcher. Yard limits were often defined to be well outside anything we would recognize as a yard... in some cases that I know of YL were over 40 miles long. Trains could move just about anywhere within Yardlimits, so long as they went slow enough to stop at any place where they would cross a switch. The idea of track warrant may come into play here as well as when working a location out on the main (what I've called area control). The dispatcher had to obtain permission from the Yraimaster to authorize a train to enter YL, a train had had to contact the Dispatcher for clearance to enter the main.

I rather doubt your spreadsheet timetable methods can handle T&TO and neither your spreadsheet can handle track warrants and/or the relationship between yards and the main. What about class and direction of travel?
========================


WRT $attach, $detach, $pickup and $transfer, does OR need to code these events?
========================

Last, I acknowledge these last few posts are mostly about train operations and not about groups of cars. Would it help if we used TrainAuthority() as the high level concept that collects one to n Train() (several for multiple sections) where Train(), which usual moves, is one or more ordered consists/blocks (plus the occasional loose car picked up or dropped off somewhere en-route), where each of those consist/blocks is an ordered list of units? With this TrainAuthority() keeps everything together logically, even if the component elements are not coupled together and consist/blocks are those groupings of units that move in common purpose and are ordered start to end, pretty much as KUJU defined in the body of the .con file.

[Genma Saotome]

P.S. WRT mu8ltiple sections... in the height of US passenger service, the premiere passenger trains often had multiple sections. I've read accounts where as many as 5 sections were called. These cleared their originating yard with as little as 10-15 minutes of clearance and in a logical sense they were managed as-if they were connected together. On occasion one section would get tied up unexpectedly, perhaps a brief equipment problem, and one or more trailing sections would be authorized to pass it. That didn't make any difference tot he overall authority of movement... everybody had to stay out of the intervening spaces.

I know that post WWII high priority fast freights sometimes ran in sections too.

[roeter]

Genma Saotome said:

I rather doubt your spreadsheet timetable methods can handle T&TO and neither your spreadsheet can handle track warrants and/or the relationship between yards and the main.

No, not as things are now.

Quote

What about class and direction of travel?

I have considered that, but the problem is to know how trains progress. It could only be done if somehow all intermediate timings for all classes in both directions were explicitly made available. The program could then 'predict' when each train would be where, and thus decide where trains should be held. A dispatcher would know such details from experience. I know that in some UK WTT's, such information was actually shown in the timetables.

Quote

WRT $attach, $detach, $pickup and $transfer, does OR need to code these events?

One of the main basic elements of the OR timetable is that it may make no difference as to what train the player selects as player train. A consequence of this is that an AI train must be able to perform the same actions as the player train would do. Whereas I can see a player would be able to decide what to attach or detach and where, I cannot see an AI train (i.e. the program) working this out by itself. So the only way this major ruling of the timetable can be maintained is that every move must be defined in detail for every train.

Genma Saotome said:

P.S. WRT mu8ltiple sections... in the height of US passenger service, the premiere passenger trains often had multiple sections. I've read accounts where as many as 5 sections were called. These cleared their originating yard with as little as 10-15 minutes of clearance and in a logical sense they were managed as-if they were connected together. On occasion one section would get tied up unexpectedly, perhaps a brief equipment problem, and one or more trailing sections would be authorized to pass it. That didn't make any difference tot he overall authority of movement... everybody had to stay out of the intervening spaces.

I know that post WWII high priority fast freights sometimes ran in sections too.

That's one of the many examples where it is clear that different nomenclature creates real misunderstandings.
On this side of the ocean, a 'section' would be part of a train which is attached/detached somewhere along the way. So a train of five 'sections' would be a train which would be split along the route with parts going off to 5 different destinations. And that's how I read your question on sections.
What you call 'sections' is called 'relief trains' in the UK. In Dutch, they would be called 'voortrein' ("fore train", i.e. running ahead of the original train) or 'natrein' ("after train", if following behind the original train).

:offtopic: As for five 'sections' - just a sidenote : I just completed the Manningtree simulation for PCRail, based on 1953 timetable. Among the trains in this timetable were the London to Harwich boat trains, connecting with the ferry from Harwich to the Hook of Holland. There was one advertised train (the famous 20:00 "Hook Continental"), but the timetable allowed for 5 relief trains for which paths were included. The difference, ofcourse, is that these paths were laid down in the WTT, and took account of other traffic as required. The relief trains were not run in 'straight' sequence requiring everything else to wait until they had all passed by.

And yes, this discussion is a bit off-topic but on the other hand, it brings to light the many differences in railroad operation in different areas, and these differences may well influence the way the data must be defined. If these differences remained unidentified, there is a real risk that the data structure would be suitable for one particular type of operation only.

Regards,
Rob Roeterdink