Loading timer

LTSV > Rail Data > More > Forum > Forum Post (ID 29)
<< An aversion to reversions Why did I make the approvals system so complicated?! >>

The pain in the Rs (Renumberings, Re-uses and Reversions)
Posted by Thomas Young in category
at 00:36 on 01/02/2023
The other day I wrote about the problems of dealing with reversions (when a loco or coach is renumbered back to a number it had previously carried) and this gave me an idea for a new solution (which is currently being worked on). Today I am going to write about more general renumberings and some of the difficulties that they cause. Perhaps this will give me a fresh insight. Perhaps it will help users to see why things are done in certain ways on this website, and why some developments have taken so long to get to a working state.

Most renumberings are quite straightforward, being from one number to another, and these are relatively easy to deal with. Two database tables are involved. Besides the primary 'numbers' table, there is another table called 'renumberings'. Each record here shows one change (from an old number to a new number). So, if you are looking at the page detailing (for example) loco 47502, a query will look for this as a new number in the renumberings table and find that it was previously D1945. A reciprocal query will look for 47502 as an old number in the renumberings table and find that it later became 47715. The process can be extended to work out whole chains of renumberings. Taking another class 47 as an example, the page for 47185 will find that it became 47602. The query can repeat to find that 47602 became 47824, then again to find that 47824 became 47782. This is known as a recursive query.

This technique is one of the reasons why this website treats reverted numbers as being distinct from their originals. Take the case of loco 90026, which was renumbered to 90126 in 1991 but reverted to 90026 in 1998. If the latter renumbering linked 90126 to the original instance of 90026, the recursive query would get stuck in an infinite loop. It would find that 90026 became 90126, and 90126 became 90026, 90026 became 90126, 90126 became 90026 and so on. Hence the second renumbering actually links 90126 to a reverted instance of 90026 (which is displayed as 90026 (R)). Renumbering dates could be used to avoid this issue but unfortunately accurate date information for many renumberings is not available.

Difficulties occur when renumberings are not one-to-one, which can arise from several situations. First is when a unit or wagon set is either split-up or combined. For example, each of the class 155 DMUs was split into two separate class 153s, while the 4-CAP EMUs on the Southern region were formed by combining pairs of 2-HAPs. Various internationally-numbered intermodal and automotive wagon sets have had similar changes. A related change can occur when a wagon set is changed from one number series to another. TOPS gives each component its own number, whereas RIV standards are usually to assign a single number to each set. An example of this is the Cartic-4 PJA sets that were 'internationalised', resulting in renumberings such as MAT90300/1/2/3 all becoming 33.70.4395.043-0.

Another scenario is when plans were changed, an example being that 4-CIG EMU 7423 was originally intended to be renumbered 1801 upon refurbishment, but was later replaced by 7417. These sort of changes seem to be more common in the Internal User number series, and they could perhaps be dealt with by assigning 're-use' IDs (even though that presents issues of its own), or by covering the proposed/cancelled changes using notes instead. Then there are cases where published information conflicts. For instance, tank wagon ESSO43665 has been shown as being the source of three different new numbers (sand wagon B390113 and tanks ADB999081 and ADB999090). Finally, there are cases where the exact old-to-new number relationship is not known. For example, for most of the HRA hoppers, each new number has several potential originals, as in 41.70.6723.051-053 being converted from 310482, 310862 and 311122, order unknown.

When the recursive queries encounter one of these cases, it is as though the chain has split (or to be more accurate, bifurcated). Each query can only search for one number. If one pass of the query finds two previous (or subsequent) numbers, which one should the next pass use? So, at present, only one-to-one renumberings are shown. This has been the case since LTSV-RD was launched in 2021 and I have treated it as a low priority, partly because it only affects a small proportion of renumberings, and partly because I couldn't come up with a better solution.

I am now tackling a number of outstanding issues with LTSV-RD, and the display of renumberings is on my list. I figured that the existing method for showing renumbering chains should be retained, but adapted so that 'irregular' renumberings also show up. I have added a new subroutine to the recursive query so that, if it encounters a many-to-one or one-to-many change, it will show all the results but then go no further.

The difficulty that I am now having is getting all the information to appear in a logical way. With one-to-one renumberings, it is possible to show everything in a single line, from the earliest known number on the left to the latest on the right, complete with dates of each change. As well as now showing the 'irregular' renumberings (which may contain 2,3 or 4 items), I also want the dates on all changes to act as a link to the renumbering detail page. This will be useful as it will enable you to see the source of the information, as well as any further notes or edits. Arranging all this in a readable way that works across various screen sizes is proving challenging!

There are a couple of other issues with renumberings which I have not really got a solution for, the first of which relates to 'additional' numbers. As an example of these, I have recently added renumberings to show the relationship between 95xxxx numbers and 82.70.4703.xxx numbers for the MXA bogie box wagons, but each of these wagons actually carries both numbers, so they are not technically renumberings.

The second issue is with reformed multiple units. If a unit is reformed and given a new number, how can this renumbering be handled? To illustrate, when the 4-CEP units (7101-7211) were refurbished in the early 1980s, they got new numbers (in the 1500-1621 range), but they were also generally reformed. New unit 1520 (as an example) was formed from the trailers from unit 7135 with one driving car from each of 7130 and 7149. I could add three separate renumberings, one from each of the 7xxx numbers and all to 1520, but then I would also have to add further renumberings from each of the 7xxx numbers to whatever unit/s their other coaches ended up in. Not very elegant! I am going to ignore this problem for now, since I have plenty else to be getting on with.
No replies yet.