A Car Classification Conundrum
So far my Car Forwarding program has only considered a car’s basic type and length when doing restaging. This is not specific enough to be realistic, but it was sufficient to get the rest of the code working correctly. Now it is time to expand the attributes for a car so that we can have more realistic assignments for cars leaving staging.
After a lot of analysis and discussion, it looks like there needs to be six main attributes to describe a car. It is always possible to add more later on if the need arises, but this should work well for now.
The additional attributes are car Subtype, Class, Door, and Capacity. All of these are user definable as to what they actually mean, but the terms are there to help guide the process and be familiar. None of these are actually numeric, but symbolic, at least for now. For example, a capacity of 6000 cannot be compared to 7000 numerically, but is just a label that can be displayed and printed, and should make some sense to the user. Later on, if there is a need to specify some kind of numeric comparison, such as “any car length less than 50” it can be added.
Not all attributes will apply to a given car, for example, tank cars usually don’t have doors. In this case, the field is simply left blank and it will be ignored.
The purpose of all this is to allow the car restaging process to be able to match suitable roles to the cars in staging. We don’t want to assign a tank car shipment to a boxcar, or vice versa. There is a lot of flexibility in this process, as a role can be told to ignore, or “don’t care” about any or all car attributes so that there is very fine grained control over the assignment process.
The following are some examples of the six car attributes, taken from Colin’s railroad.
Type
Autorack
Boxcar
Covered Hopper
Flat
Gondola
Reefer
Tank
Length
40
50
75
85
Subtype
2 Deck
3 Deck
Auto
Bulkhead
Chemical
Drop Bottom
Ice
Insulated
Mechanical
Oil
Vinegar
Class
Clean
High
Newsprint
Rough
Door
5
6
8
10
Combo
Double
Plug
PS
Capacity
6000
8000
In the car description data any or all of these attributes can be left blank which implies that the attribute is not important and will be ignored when matching the car to roles. Obviously tank cars do not have doors, etc. Even the main car type can be ignored, if for instance we had some generic shipments to a team track that can accept any type of car.
More attributes can be added if necessary, but this should handle most situations based on local discussions.
Other attributes that help identify the car are its owner railroad and reporting mark initials and number. These may get added to the role data model so that roles can be made very specific down to an individual car or set of cars.
Some format is needed to be able to display the complete car attribute information, so the following is proposed. The complete string will consist of a concatenation of the non blank attributes, separated with colons, “:”. Something similar applies to the roles, but more details of that will come later. The order of the attributes was selected to move from most common on the left, to least on the right. All cars should have a type and length, so those are the first two , followed by subtype, class, door, and capacity. So some examples:
- A 40’ boxcar with 8’ doors, for clean loading would be specified by: “Boxcar:40:Clean:D8”.
- A Shipment that needs a clean 40’ boxcar, but with any door width would request it as “Boxcar:40:Clean:*”, where the door width is specified with an asterisk, indicating “any” width will do. The same can be done for the length, etc.
- Another Shipment that only cares that it has any kind of a boxcar would use “Boxcar:*:*:*”, with asterisks for everything except the basic car type.
One issue that is not completely resolved at this time is how to handle missing attributes. If we want to be able to parse a car attribute string, it gets difficult if it has an unpredictable number of parts, for example “Boxcar” versus “Boxcar:40:Clean:D8”. The simplistic approach would be to require all such strings to have a fixed number of parts, but this will look very messy with lots of “*”. A better solution is to require that all of the attribute names be unique and then the program can search for each name and from it determine if it represents the car’s length, class, door, or whatever. This seems to be a good compromise in that each attribute tends to be quite different in the types of names used, so not allowing the same name for different attributes should not be a problem. For example, lengths tend to be two digits (40), while capacities are 4 digits or more (6000). Time will tell if this assumption holds true or not as more car attributes are encountered from the real world.
The format of a role string, on the other hand, must include all of the parts in the correct sequence, because it must know which are to be ignored. It might be possible to make this more flexible with some more thought and testing, but for now this will have to be the case.