Correcting Milepost Errors During Imports

Errors recording mileposts during track testing can cause serious problems when importing geometry and rail profile data. Rangecam allows viewing of mileposts from most types of import source files, and provides the ability to correct common errors.

The Post Correction interface is controlled by the Edit Mileposts option in most geometry import dialogs and the Laserail profile import dialog.

If On Error is selected, then the Post Correction dialog is displayed only if there is a critical error that would prevent the source file from being imported. An example of a critical error is mileposts out of order. If Warning is selected, then the dialog is displayed if there are non-critical errors such as skipped posts, or extremely long or short distances between posts. Select Always if you want to review mileposts before importing every file.

This is an example of the Post Correction dialog. The Valid column for the run #2  shows red, indicating an error.

The scrolling lower window in this dialog shows all milepost changes in the run. Red comments are used for critical errors, amber for warnings. The first problem that appears in this run is the transition from milepost 257 to 558, which is flagged by the comment "Skipped multiple posts". After milepost 559 a jump in the opposite direction, back to 260, is flagged as a critical error.

This situation was probably caused by operator error in the field. The operator mistakenly entered 558 at milepost 258. When he reached milepost 260 he noticed the error and corrected it - but by then two miles of data had been stamped with a location that was 300 miles out.

This problem can be corrected by changing values in the Post column manually. Click on 558 and change it to 258. After corrections, the dialog looks like this:

Although the messages are gone, the Valid indicator is still red. Scrolling down reveals additional problems in the file:

Mileposts 269 and 270 have been entered twice. The field operator may have hit the button to record milepost 270 too soon, then corrected it back to 269, then recorded 270 again at the actual milepost. There is some evidence for this in the fact that milepost 270 was first recorded only 4859 feet from milepost 269  although that could be accurate, since short distances between mileposts are not uncommon.

Another problem is that milepost 0 mysteriously appears in the middle of data stamped with milepost 276. This could be caused by a programming glitch in the onboard system. Both these problems consist in extra milepost changes being recorded in the data at locations where there are no mileposts in fact. They can be corrected using the Post Correction dialog by checking the Delete column beside the extra mileposts, like this:

Four milepost changes have been deleted, and the Valid indicator has turned green, indicating that no errors or warnings remain.

When a post is ‘deleted’, it is redisplayed in blue. The distance of that post from the previous post is added to the following post, where it is redisplayed in red to indicate that it has changed. When posts 270 and 269 were deleted as shown, the new distance of the remaining post 270 from post 269 = 4859 + 1427 + 422 = 6708 feet.

The distance between milepost 269 and 270 is showing as 6708 feet, which is significantly longer than a true mile. That may be accurate or it may be an error; but in either case your file will import. Any alignment issues can be dealt with later.

The second set of changes removes the mysterious 0 milepost from the file. The distance between mileposts 276 and 277 now shows as 5532 feet, which is quite believable.

Multiple Runs

If the source file being imported contains changes of track, Rangecam imports it as more than one logical run. In this case more than one row will be displayed in the Run Information window. In this example, the first run is currently selected, and is valid. It contains a single milepost change, milepost 31. The second run, however, has a problem.

The indicator for the second run, on track 1, is red. When the second run is selected by clicking on it in the upper window, the lower window displays the mileposts in the second run, and corrections may be made.

Run Direction

The dialog also shows the Facing Direction and Traveling Direction for the currently selected run. Facing Direction indicates whether the test vehicle is facing the direction of ascending or descending mileage. Traveling Direction indicates whether the vehicle is traveling forward or in reverse. Together, these determine whether the test direction is ascending or descending.

The facing and traveling direction are usually derived from one or more headers in the source file. If one of them is wrong, then the test direction will disagree with the sequence of mileposts encountered in the file, with the result that all posts are flagged as “out of order”. If this occurs, you may try to correct the problem by changing the Facing or Traveling direction. As this is a radical thing to do, you will be warned; and unless the detailed location information in the file supports the change, you will just be trading one problem for another.

The Post Correction Dialog is a powerful tool that allows you to fix most location problems in import source files, if you have the right information to make the corrections. Information can sometimes be obtained from previous runs over the same territory, or sometimes from track charts. However, using tools like this to patch the data after the fact is a poor substitute for getting it right in the first place. The repeated occurrence of data problems in track test data files is a strong indicator that changes should be made to field data collection software and/or procedures.