Computing Results for a GeBE Printer E-Punch Event
If a SportIdent "GeBE" printer was used to provide e-punch service at a B or C event held by BAOC, and if that event was set up in BAOC's Event Management system, then results for the event can be computed automatically, with some degree of manual correction. This is accomplished by uploading files to the Event Management system to create and adjust the results for the event, then downloading the result product files that the system generates accordingly. Whenever a file of raw e-punch data or manual corrections is uploaded, the system creates or modifies all these result products and notifies you of the outcome of this operation. Any of the result product files may be downloaded at any stage during the creation and refinement of an event's results.
The following instructions describe how to use the runner splits data downloaded from a GeBE printer, along with any additional runner information that may be needed, to compute the results for an event in which the printer was used to furnish tags to the runners showing their splits. This makes it possible to generate all the traditional BAOC result products for a B or C event, including (1) two text files of runner names and course times, (2) the corresponding file for WinSplits Online, and (3) a "rectified" GeBE data file and companion "entries" file that can both be plugged into Sport Software's e-punch event utility OE2003 to produce additional results for the event in other formats.
IMPORTANT: At this time, the Event Management system can only process results for events in which all of the courses use "classic" format. This is defined as a course in which a fixed series of controls is visited in a prescribed order. The same control may be visited more than once along the course, so this could include a relay format in which the same e-stick is handed from one runner to another like a baton. But the course cannot be a Score-O' type of course and it cannot use forked controls, butterfly configurations, motala loops whose order varies from runner to runner, etc. HOWEVER . . . the Event Management system is designed so that it can be easily extended to handle all these other course formats as time and effort permit.
In A Nutshell . . .
In order to use the Event Managemnt system to create and edit the results of an event, that event must be set up in advance as an event on the system. This can be done at any time up to and including the first day (or only day) of the event. Click the Event Setup Instructions link in the Online Event Management menu on the left side of the webpage you're now reading for instructions on how to set up an event.
To use the splits data from a GeBE printer to create and edit the results of an event that's been set up on the Event Management system, perform the following steps in the order listed:
1. Use Sport Software's SI Manager utility to download the splits data from the GeBE printer's memory to a "GeBE backup" file (whose name will end with .sid or .smd) on your PC. (Eventually the Event Management system will provide its own software that does this.)
2. Click the Compute GeBE Printer Results link in the Online Event Management section of the menu on the left side of this webpage to bring up the Event Results Processing page. From the drop-down list of past events on this page, select the event whose results are to be created. This is the "currently selected event".
3. Type your event management administrative password in the blank at the bottom of the Event Results Processing page and hit ENTER to go to the BAOC Event Results Administrative Tools page.
4. If you have the exported XML version of the CONDES course data file associated with the event, use the Upload CONDES Event File button and its associated Browse button on the administrative page to upload this file to the Event Management system.
5. Use the Upload SI Printer Data button and its associated Browse button to upload the GeBE backup file. This upload will cause the Event Management system to generate a variety of result product files for the currently selected event.
6. Press the Download Bulletin Results button or the Download Website Results button to download one of two text files that lists runner names and course times for the currently selected event. If there are no runner names like Unknown Runner 12345 or Rental Runner 67890 in any of the lists, then you're done with the preliminary results! In this case, you can go directly to step 9.
7. For each Unknown Runner XXXXX or Rental Runner YYYYY in the text results lists, use the splits tags from the event results line, or possibly registration forms from the event, to identify the runners or teams who used e-sticks with the corresponding numbers XXXXX or YYYYY.
8. Type a text file consisting of commands that associate names of the Unknown Runners and Rental Runners with their corresponding e-stick numbers. (This is described in great detail below.) Use the Upload Result Corrections button and its associated Browse button to upload this file of name correction commands to the Event Management system. Return to step 6.
9. If there are any special corrections that need to be made to the preliminary results, such as crediting one or more runners for a missing or misplaced or malfunctioning control, then type a text file of result correction commands designed for this purpose. (These commands are described in great detail below.) Use the Upload Result Corrections button and its associated Browse button to upload this file of special correction commands to the Event Management system.
10. Use any or all of the Download WinSplits Input, Download Entries File, or Download SI Printer Tags buttons to download any other types of result product files you may need.
When handed a GeBE backup file for the currently selected event, the Event Management system generates five different types of result product files for that event: (1) a text listing of runner/team names and course times in BAOC Bulletin format, (2) the same information in BAOC website format, (3) a text input file for WinSplits Online in Sport Software "CSV" format, (4) a "rectified" GeBE backup file, and (5) a companion "rectified" CSV file suitable for use as an entries file in the Sport Software utility OE2003.
The two types of text listing files both consist of runner/team names and their corresponding times or qualifiers (DNF, MSP, etc.), listed by course. One file lays out this information in the format used in the BAOC Bulletin (with dots connecting each name and its result). The second type of text listing file recasts this same information in the format used to post results on the BAOC website. Both formats show second course, third course, etc. results as separate lists.
The "rectified" GeBE backup file and its matching "rectified" OE2003 entries file consist of entries that match one-for-one between the two files. The rectified GeBE file contains no duplicate splits tag data, even if one or more runners at the event downloaded their e-sticks on the printer more than once. The rectified entries file contains no duplicate runner names or e-stick numbers. If Orlo Hoadly ran a second course using the same e-stick he used on his first course, the entry for his second course would contain the name Orlo Hoadly:2 and would show a dummy e-stick number guaranteed unique among all e-stick numbers in the file. The dummy e-stick number is also encoded in his corresponding entry in the rectified GeBE backup file. All of this makes it possible to feed the two rectified files as input to OE2003 without errors from that program concerning multiple runs on the same e-stick or the same runner using two or more different e-sticks.
The original GeBE backup file downloaded directly from a GeBE printer by the Sport Software utility SI Manager essentially contains no information about runner names associated with the splits data. It simply associates an e-stick number with a set of splits. When the Event Management system receives a GeBE backup file for the currently selected event, it attempts to resolve each e-stick number XXXXX to a runner/team name by first looking in the file of pre-registered entries for that event. If it can't find a match for XXXXX there, it then looks for a match in its resident archive of e-stick owner information. If it still can't find a match, it will record that runner or team name in the results as Unknown Runner XXXXX or as Rental Runner XXXXX if the e-stick is a BAOC rental e-stick. To turn these names into real names, as mentioned above, the results administrator must submit one or more files of result correction commands to the Event Management system.
Overview of Event Results Administrative Tools
Once an event that was set up for online management has taken place, it can be selected from a drop-down list of past events on the Event Results Processing webpage. The event you select becomes the "currently selected event". If you then type your event management administrative password at the bottom of this page to go to the BAOC Event Results Administrative Tools webpage, all the tools you'll find there that apply to a specific event refer to this event.
The BAOC Event Results Administrative Tools webpage provides three classes of tools for setting up an event and processing its results online. These tools are divided into three corresponding sections entitled Downloads and Uploads, Edit Registration Data By Hand, and Server Commands.
In the Downloads and Uploads section, you'll find a variety of buttons that enable you to download and upload files that are specifically involved in the setup and results processing for the currently selected event. You'll also find buttons for downloading, uploading, and modifying the Event Management system's archive of e-stick owner information. Almost all of these files are in formats used by Sport Software's OE2003 e-punch event utility, so they can all be used interchangeably with that utility and the Event Management system.
The Edit Registration Data By Hand section contains the Event Summary and Courses Offered forms that allow you to input general information or course statistics for the currently selected event. This section is an exact duplicate of the Edit Registration Data By Hand section of the BAOC Event Registration Administrative Tools webpage and is provided here in this second location for results administrator convenience. Click the Event Setup Instructions link in the Online Event Management menu on the left side of the webpage you're now reading for instructions on how to use the two forms in this section.
In the Server Commands section is a blank into which you can type a command directly to the Event Management system on its server. Like the Edit Registration Data By Hand section, this section is also an exact duplicate of its counterpart on the BAOC Event Registration Administrative Tools webpage. Click the Event Setup Instructions link in the Online Event Management menu on the left side of the page you're now reading for instructions on all the available server commands and their functions.
Whenever you apply any of the tools on this page by pressing a button or typing a command, the entire page will be redisplayed with a green or red box just above the Downloads and Uploads section. If it's a green box, your action was successful and a message inside the box will tell you what the Event Management system did. If the box is red, your action failed and the message inside the box will tell you what went wrong.
Downloads and Uploads
The 11 buttons you'll find here do the following:
The Download Entries File, Download Archive , Replace Entries File, Replace Archive, and Merge With Archive buttons perform exactly the same functions as the 5 buttons with the same labels on the BAOC Event Registration Administrative Tools webpage and are provided here in this second location for results administrator convenience. Click the Event Setup Instructions link in the Online Event Management menu on the left side of the page you're now reading for instructions on these buttons and their functions.
The Upload CONDES Event File button can be used to upload a CONDES course data file for the currently selected event at some time before the event's results are processed. This will provide the Event Management system with definitions of the event's courses, which it will need to compute the results. The CONDES file must be in the exportable XML format that the CONDES course-setting utility can output. It must also conform to the IOF Version 2.0 XML standard (which is the default format used by CONDES for its exported XML files).
NOTE: If the CONDES course data file for the currently selected event is not available or if the event's course setters did not use CONDES, the Event Management system can still process the results. In this case, the system will attempt to deduce the course definitions from the GeBE backup file data and the course statistics. This "educated guess" should be correct in all but the most obscure situations. In order for this to work, however, complete information must be provided in the course statistics when the Courses Offered form on the BAOC Event Registration Administrative Tools webpage is used to input those statistics during event setup.
The Upload SI Printer Data button is used to upload the GeBE "backup file" to the Event Management system. This file is created by Sport Software's SI Manager utility when it is used to download splits data for the currently selected event from the GeBE printer's memory. Uploading the GeBE backup file triggers the computation of all five types of result product files that the Event Management system currently makes. See the In A Nutshell section above for a description of these result product files.
NOTE: More than one GeBE backup file of splits data for the currently selected event can be uploaded. The Event Management system assumes that each successive file is identical to its predecessor, except that more splits data for the same event has been accumulated at the end of the file. (The system will actually verify that the sequence of files indeed satisfies this requirement.) In this way, it is possible to produce several progressive sets of results for the same event while the event is taking place.
The Upload Result Corrections button can be used to upload a text file of simple commands that the Event Management system will carry out to manually correct or modify individual results for the currently selected event. These commands perform the types of adjustments commonly used when preparing event results, such as changing runner names to corrected runner names or crediting one or more runners with punching a control that was missing, misplaced, or malfunctioning. The Result Correction Commands section below provides detailed descriptions of the functions and formats of the result correction commands available.
The Download Bulletin Results button is used to download a text file that lists runner/team names and their corresponding times or qualifiers (DNF, MSP, etc.) by course in BAOC Bulletin format. The companion Download Website Results button is used to download a similar file that lays out this same information in the format used to post results on the BAOC website and the Bay-O-Net. These files are two of the five types of result product files generated for the currently selected event whenever the Event Management system receives an uploaded GeBE backup file or result correction command file for that event. See the In A Nutshell section above for a fuller description of these two result listing files.
The Download WinSplits Input button can be used to download a text file of splits data for the currently selected event that is suitable for use as input to WinSplits Online. When WinSplits uses this data to display splits for the currently selected event, it will create only as many courses as there were in the event. It will not show the second runs, third runs, etc. of a given course as separate courses. If someone ran for a second time on Course X, the designator "2nd course" will appear in parentheses next to his name in the WinSplits display board for Course X. Likewise for 3rd course, 4th course, etc. The WinSplits splits input file is one of the five types of result product files generated for the currently selected event whenever the Event Management system receives an uploaded GeBE backup file or result correction command file for that event.
The Download SI Printer Tags button can be used to download the "rectified" GeBE backup file for the currently selected event. This is not the original GeBE backup file of splits data for the currently selected event that was downloaded from the GeBE printer via SI Manager. The companion "rectified" OE2003 entries file can be downloaded with the Download Entries File button. The rectified GeBE backup file and rectified entries file are two of the five types of result product files generated for the currently selected event whenever the Event Management system receives an uploaded GeBE backup file or result correction command file for that event. See the In A Nutshell section above for an explanation of the rectified file pair.
Result Correction Commands
Result correction commands are executed by the Event Management system to explictly adjust individual results for the currently selected event. These are text commands placed in a simple text file, with one command per line in the file. Blank lines are ignored. Lines that begin with // are also ignored, so they can be used as "comment" lines in the file. If you're on a Windows PC, you can use an accessory like Notepad or Wordpad to type a file of correction commands. If you're on a Linux PC (good for you!), you can use a common text editor like vi, emacs, or nedit. Please don't use a word processing application to type result correction command files.
The Event Management system recomputes all result products for the currently selected event whenever it receives an uploaded file of correction commands for that event. Any number of result correction command files may be submitted for a single event as the event results are gradually refined.
There are no result correction commands to fix the splits of a runner who forgot to clear and check. This is unnecessary. The Event Management system detects and corrects such a set of splits automatically.
There are currently 4 result correction commands available:
name: Change a runner's name to a different name
The name command changes one or all instances of a runner/team name in the event results to a new name. This command has the general form:
name currentname = newname
Here currentname represents the runner/team name to be changed and newname represents the name that will replace it. Do not enclose either name in any kind of quote marks. If a runner named Ima Runner ran more than one course at the currently selected event, then Ima Runner:1 is the currentname value that refers specifically to her name in her first course results only, Ima Runner:2 refers to her name in her second course results, etc. If Ima Runner is used as the currentname, then all instances of Ima Runner in all course results will be changed to the newname.
You need not type the currentname in its entirety, but rather just enough words of it to uniquely distinguish it from all other names in the results. Darla, for instance, may be used as the currentname rather than Darla Stempelheimer if there are no other runners in the event with the first or last name Darla. A currentname of 47028 could be used instead of the longer Rental Runner 47028, since 47028 is almost certainly not a part of any runner's or team's real name.
When using the name command, do not worry about "overlapping changes". If you change Ima Runner to Yura Runner in one name command and then change Yura Runner to Shiza Runner in another name command that's farther down in the same result correction command file, the change made by the first command will not be affected by the second command.
nameiflisted: Change a runner's name to a different name if listed in the results
The nameiflisted command is identical in format and function to the name command, except that it will not generate an error if the name to be changed is not found in the results. It has the same form as the name command:
nameiflisted currentname = newname
If the currentname in an ordinary name command is not found in the results, the results administrator will receive an error message, all further processing of his result correction command file will stop, and no changes whatsoever will be made to the results. This is done to alert the administrator to the possible misspelling of a runner/team name in one of his commands, which could cause a failure to correct one or more results without his knowledge if no error were generated. The nameiflisted command allows result correction command processing to continue if the currentname is not found. This makes it possible for the results administrator, for instance, to submit stick-to-name translations for a whole list of people who may or may not have attended the currently selected event. Such a list would be playing a role similar to that of the Event Management system's e-stick owner information archive.
timestamp: Credit a runner for a missed punch
The timestamp command is used to change a punch time time for a runner/team at a specific control on a specific course, or to change a punch time for all runners at a specific control on a specific course. If there's already a punch time for that control in the event results, it will be replaced. If not, a punch time will be added. Use this command to credit a runner for a (1) forgotten Start punch, (2) a forgotten Finish punch, (3) a control he forgot to punch but which is a control he can otherwise prove that he visited, or (4) a control that was malfunctioning during the event. This command has the general form:
timestamp controlname runnername = timestamp
Here controlname can be the word Start, the word Finish, or #controlordinal. The controlordinal is the ordinal number of the credited control on the course that was run by the credited runner. The runnername is identical in format to the currentname in a name command, except that Ima Runner implicitly refers to Ima Runner's first course run, not all of her course runs. The runnername can also be of the form all coursename runners, in which case coursename is the name of a course on which all runners who failed to punch the control designated by controlname will be given credit for that control. The timestamp can either be an explicit punch time expressed in the form hh:mm:ss or the word average. If timestamp is average, a punch time for the credited control will be estimated, based on the runner's average speed on the course. In this case, the controlname must not be Start or Finish (see next paragraph).
If a runner forgets to punch the Start or Finish control, the Event Management system will estimate a Start or Finish punch time, based on that runner's average speed on the course where the punch was skipped. The notation (no Start punch) or (no Finish punch) will also appear next to his entry for that course in the text results listing file. The results administrator then has the option of using a timestamp command to replace this runner's "place holder" Start or Finish punch time on that course with a more accurate punch time determined by other means.
NOTE: No course name is needed in a timestamp command. The runnername can be suffixed with :1, :2, :3, etc. to specify the runner's first run, second run, third run, etc. and thus indicates the relevant course implicitly.
unfaircontrol: Adjust course leg times to compensate for an unfair control
If a control is missing or badly misplaced, it typically becomes a "bingo" control. The time expended by each runner to find the control, if he/she finds it at all, depends primarily on luck and not navigational skill. A single unfair control such as this accordingly makes any course that uses it unfair and renders the results on that course worthless for competitive purposes. The unfaircontrol command can be used to compensate for the unfairness of such a control on a course by making every runner's two times on the two legs that include this control absolutely equal. This essentially eliminates the two affected legs from the competition while preserving the rest of the course as a valid competition. This command has the form:
unfaircontrol #controlordinal coursename
The controlordinal is the ordinal number (#1, #2, etc.) of the unfair control on a course named coursename that includes it. Every runner's time on that course for the leg that goes from control controlordinal-1 to control controlordinal will be set to the time it takes for a runner moving at a speed of 15 minutes per kilometer to run the bee-line distance between those two controls. Runner times for the leg between control controlordinal and control controlordinal+1 are treated similarly. (If the unfair control is #1, the first of the two legs is the one between the Start and #1. If the unfair control is the GO control, the second of the two legs is the one between that control and the Finish.) Note that this will change each runner's recorded punch timestamps for all controls that follow the unfair control and will change the runner's recorded total time spent on the course. A runner's recomputed results will not match the results on his GeBE printer splits tag.
WHAT'S THE DIFFERENCE? The command unfaircontrol #7 Green appears to have the same effect as timestamp #7 all Green runners. What's the difference between these two and when should one be used instead of the other?
A timestamp command of the type shown above should only be used when the failure to punch a control has nothing to do with navigational luck. This occurs, for instance, when an otherwise perfectly valid control (1) is not functioning when the runner punches the unit; or (2) is the wrong control unit; or (3) is placed at such a dangerous location that some runners don't event attempt to punch it. The timestamp command above merely credits each runner with a single timestamp for control #7 (if that runner didn't already have a timestamp for #7) and makes no changes to any of his/her other timestamps or total time spent on the course.
The unfaircontrol command shown above, on the other hand, will indeed change each runner's timestamps (after control #7) and his/her total time spent on the course. A measure this drastic should only be taken when the control was missing or significantly misplaced at a time when some or all runners on that course attempted (perhaps successfully, perhaps not) to find it. Clearly this is the classic "bingo" type of situation in which a runner's success or failure in finding the control depends more on luck than anything else. The unfaircontrol command effectively removes the unfair control from the course so that the course need not be thrown out of the event competition.
switchunit: Indicate replacement of a faulty control unit
The switchunit command can be used to specify the number of a control unit that was substituted at the last minute for another faulty control unit. This command has the form:
switchunit originalunit = replacementunit
If a faulty control unit in the field is discovered and replaced with a working unit at a time when it's too late to upload a corrected version of the CONDES course data file that contains the definitions of courses in the currently selected event, the Event Management system will know nothing of this change and will accordingly produce erroneous, highly alarming results. But if a switchunit command that indicates the substitution is then submitted in a subsequent result correction command file, all results will take this into account when they are recalculated. Here originalunit is the number of the faulty control unit (just the number, with no # appended) and replacementunit is the number of the replacement unit.
HINT: If at all possible, save yourself the trouble of generating bad results in the first place when there's a last-minute control unit substitution by uploading a corrected CONDES course data file for the currently selected event before the results are processed.
addrawresult: Add a splits data record to the GeBE printer splits data
The addrawresult command can be used to add the splits data for a single run to the GeBE printer splits data for the currently selected event. This splits data record is associated with a specific e-stick number and will show up in the recomputed results as a run credited to the known or unknown runner using that e-stick. The addrawresult command is useful if a runner forgot to download his e-stick on the GeBE printer at the event, particularly if his split times are known by other means. There are two forms of this command:
addrawresult chipnumber = code1 time1 code2 time2 . . . codeN timeN
addrawresult chipnumber coursename = START starttime FINISH finishtime
In the first form, each code is either the word START or the word FINISH or the numerical code of a control on the runner's course. Each time is a timestamp of the form hh:mm:ss which represents the clock time when the runner punched the corresponding control unit. (Of the 5 columns of numbers on a typical GeBE printer splits tag, the control codes and timestamps correspond to the second and third columns.) All the times must be in chronological order.
In the second form of the command, coursename is the name of a course in the event. The starttime and finishtime are timestamps in the same hh:mm:ss format mentioned above. The Event Management system will create a splits data record for a successful run on the indicated course in which all leg times will be proportional to the average leg times of all runners who successfully completed that course. If only a few other runners completed the course, or if none did, leg times in the new splits data record will be proportional to corresponding bee-line leg lengths.
Use the first form of the addrawresult command if a runner forgot to download his e-stick on the GeBE printer but his split times are known because (1) he downloaded on a different GeBE printer and saved the tag, or (2) he registered split times on a splits-capable watch, or (3) he in fact downloaded on the appropriate GeBE printer and received a perfectly valid splits tag but the printer failed to record his splits in its memory (which currently happens when a SI Card-9 is downloaded, due to a SportIdent malfunction). Use the second addrawresult form when only a runner's start and finish times are known. There's usually some record of a runner's start time and sometimes finish times are also recorded in some other way. Start and finish times for all runners who punched the Start and Finish control units can be read from those units if software like Sport Software's OE2003 is available. Of course, when a command of this sort is used to create data for a new successful run in the event results using just the runner's start and finish times, it is assumed that the runner is being honest when he claims that he in fact punched all controls on his course.
After one or more addrawresult commands are submitted in one round of corrections, each new result will appear in the recomputed result products exactly as though the corresponding e-stick had been downloaded in the first place. All the other correction commands above, such as name commands and timestamp commands, can then be applied as usual in subsequent rounds of corrections to make any further adjustments to the added results.
DON'T BE CONFUSED! When a new result is added for e-stick XXXXX, it may not show up in the recomputed results as a run by "Unknown Runner XXXXX" or "Rental Runner XXXXX". If e-stick XXXXX was used for another run by Ima Runner in the same event and if the splits for that run were downloaded normally on the GeBE printer, then the newly added result will appear in the recomputed results as an additional run by Ima Runner. This can be particularly confusing, for instance, if two or more runners share the same rental e-stick. Less confusing is the case in which the Event Management system's archive of e-stick owner information associates e-stick XXXXX with Yura Runner. The newly added result would then automatically appear as a run by Yura Runner.
If there's any doubt as to where a newly added result for e-stick XXXXX showed up in the results, use the Download WinSplits Input button to download the WinSplits result file, then search that file to find all instances of XXXXX. Information in the matching entries will enable you to determine which run by whom on which course is the run just added.
Result Correction Command Examples: Common Situations
To turn names like "Unknown Runner 12345" and "Rental Runner 67890" into real runner/team names in the results listing, find out who used e-sticks 12345 or 67890 in the currently selected event. To do this, you can examine (1) the splits tags from the results line (if there was one) or (2) the event registration forms or (3) the "Course Coupons" from a COOL event. Then add a name command to your result correction command file for each name to be changed:
name Unknown Runner 12345 = Clyde Simkins
name 12345 = Clyde Simkins
name Rental Runner 67890 = The Wandering Fools
name 67890 = The Wandering Fools
The first two of these commands switch all instances of Unknown Runner 12345 to Clyde Simkins in the results. The second command is just a shorthand form of the first which capitalizes on the fact that no other runner/team name in the uncorrected results contains the word 12345, so Unknown Runner 12345 is still uniquely identified without having to type the whole name. The third and fourth commands are analogous to the first and second, demonstrating the substitution of a team name.
HINT: If event pre-registration is used, runners and teams are pre-assigned rental e-sticks when they pre-register. So if a high proportion of the runners and teams who ultimately attend the event do in fact pre-register, there will be very few "Rental Runner" and "Unknown Runner" entries whose names must be tracked down when the results are processed. Since it is completely harmless if a runner/team pre-registers and then does not show up at the event, it is not necessary to initmidate event participants into canceling their registrations if they cannot attend.
If one runner borrows the e-stick of a different runner, he will be recorded in the results under the second runner's name. If the first runner spots this in the preliminary posted results and reports it to the results administrator, a simple name command like the following can be used to substitute the first runner's name:
name Groucho Marx = Chico Marx
This will change all instances of Groucho Marx to Chico Marx in the results.
If two runners share the same e-stick at the event, then all their runs will be listed as multiple runs by the same runner in the results. If the runners involved explain to the results administrator which runs belong to whom, one or more name commands like the following can be submitted to sort out the situation:
name Sonja Lundquist:2 = Ingrid Lundquist
name Sonja Lundquist:3 = Ingrid Lundquist
In this example we imagine that Sonja Lundquist, after running a course herself, handed her e-stick to her sister Ingrid, who then used it to run two courses. After Ingrid ran her second course, she returned the e-stick to the well-rested Sonja, who used it to run another course herself. In the uncorrected results, all four runs by the two sisters would be recorded as Sonja's runs. After applying the two name commands above, (1) Sonja's apparent second run will be listed in the corrected results as Ingrid's first run, (2) Sonja's apparent third run will be listed as Ingrid's second run, and (3) Sonja's apparent fourth run will be listed as her own second run. This is the desired result.
If a group of orienteers from an outside organization ran in your event and they have a master list that shows who owns which e-sticks in that organization, this information can be used to construct a series of nameiflisted commands to replace "Unknown Runner XXXXX" entries for members of that group with appropriate runner names in the results:
nameiflisted Unknown Runner 1234567 = Ima Visiting Runner
This command does exactly what the equivalent name command would do, except that the Event Management system does not stop processing the result correction command file that contains the nameiflisted command if an entry for e-stick 1234567 is not found in the results. So the file of nameiflisted commands acts as a temporary archive of e-stick owner information for the outside organization, just like BAOC's permanent archive of e-stick owner information for the members of BAOC (and other e-stick owners who have been added) in the Event Management system.
NOTE: If you want to update the Event Management system's archive of e-stick owner information with information for members of the outside organization who ran in your event that day, press the Download Entries File button to download the "rectified" file of registered event entries, then use the Merge With Archive button and its associated Browse button to upload this entries file. The Event Management system will add information from this file to its archive for any e-stick owners whose information is not already in the archive. It's a good idea to do this at the end of every event anyway when you're done processing the results.
If a runner forgot to punch the Start or Finish, the Event Management system will estimate a Start or Finish time for that runner, so the run will show up in the results as a normal, valid run (unless the runner made some other blunder), except that the notation (no Start punch) or (no Finish punch) will appear next to that result. If the results administrator learns the runner's true (or allegedly true) Start or Finish time by other means (examining Start sheets or Finish sheets, asking the runner, etc.), then a timestamp command can be used to replace the estimated Start or Finish time with its true value:
timestamp Start Marletta Skiff = 10:48:00
timestamp START Plasket:2 = 11:07:20
timestamp finish 7654321 = 13:17:41
When the Event Management system recalculates all the results in response to the uploading of the result correction command file that contains these commands, the result for Marletta Skiff's run will be recalculated using her true Start time of 10:48:00 instead of the former estimated Start time. Likewise for the result of Ossie Plasket's second run, whose true Start time was 11:07:20. (It is assumed that no one else in the event had the surname Plasket, so the first name Ossie did not have to be typed in the command to uniquely identify the result.) A Finish time of 13:17:41 will also be assumed for the unidentified runner who used e-stick 7654321 when the results are recomputed. (Note that the word "Start" or "Finish" can consist of any combination of upper and lower case letters.)
If a control was temporarily malfunctioning for some period of time during the event, the results administrator can credit the affected runners with a punch of that control by submitting a timestamp command for each of those runners:
timestamp #7 Freeman Moorsby = average
timestamp #7 Sonja Lundquist:1 = average
timestamp #11 Merwyn Dube = 10:06:41
In this tale of woe, we are told that the battery in control unit #47 was dead and remained in the field until the course setter scrambled out to replace it with unit #72 before too many runners were affected by the dead unit. This particular control was the 7th control on the Green course run by Freeman Moorsby and Sonja Lundquist in her first of two runs. Their entries in the uncorrected results each include the notation (skipped #7). This control was also the 11th control on the Blue course run by Merwyn Dube, who ran very early that day. His uncorrected result includes the notation (skipped #11).
The first command causes the Event Management system to compute a reasonable punch time at Green course control #7 for Freeman Moorsby, based on (1) his average running speed over the entire Green course, (2) the bee-line distance from #6 to #7 and from #7 to #8 on the Green course, and (3) the time it took other runners unaffected by the dead unit, if any, to run those two legs on the Green course. The second command does the same for Sonja Lundquist's first run, which was her run on the Green course. The third command sets Merwyn Dube's punch time at Blue course control #11 to a specific time that Dube, being of the old school, registered as a split on his old Ironman splits watch that he still wears on the course "in case the little electronic boxes don't work". (Of course he'll crow about this incident to no end.) The corrected results will be calculated using the three estimated or specific punch times for the three runners and will no longer show that they skipped the problematic control.
If everyone on a course who was unable to punch a malfunctioning control unit is to be given credit for punching that control, this can be accomplished with a single timestamp command:
timestamp #3 all Orange runners = average
This command will cause the Event Management system to compute a reasonable punch time at Orange course control #3 for everyone on that course who failed to punch that control, using the method of average running speeds explained in the previous example. No runner's corrected result will show that he skipped or mispunched this control. When a timestamp command applies to all runners on a course, the timestamp value cannot be a specific time. That wouldn't make any sense.
If a badly misplaced control is to be removed from a course in the event results to make the remaining controls a valid contest, a single unfaircontrol command will do the job:
unfaircontrol #3 Orange
This command will make all Orange course runners' third leg (#2 to #3) times absolutely equal and will do the same thing with all those runners' fourth leg (#3 to #4) times. In effect, this will eliminate the unfair control #3 from the Orange course competition. This not only makes the Orange course runner times a valid comparison, it also enables those results to be meaningfully submitted to WinSplits Online and RouteGadget, since no punch timestamps are actually omitted from any runner's result.
Compare this example to the example just above. The circumstances are similar but not identical: the control in the example above is a fair control, but one that was physically impossible to punch.
If a faulty control unit was replaced with a working unit but a corrected CONDES file could not be uploaded to reflect this change, then everyone who ran a course that included this control will be listed in the first version of the results with a mispunch for that control. This situation can be rectified with a switchunit command:
switchunit 47 = 72
When the result correction command file containing this command is uploaded to the Event Management system, all results will be recomputed with the assumption that control unit 72 should be substituted for unit 47 in all course definitions.
HINT: Save yourself the trouble of generating incorrect results in the first place by uploading a corrected CONDES course data file with appropriate control unit substitutions before you process the results. If your event was a low-tech operation in which no CONDES file was used, you don't even need to do this.
If there's a splits tag left over that didn't show up in the first round of results and if the e-stick number on that tag has 7 or 8 digits, then the e-stick is an SI Card-9 whose splits data was not saved in the GeBE printer's memory when the e-stick was downloaded, due to a current bug in the GeBE master unit. Since all the splits data is in your hands, you can add it to the results with an addrawresult command:
addrawresult 1302708 = Start 11:18:06 47 11:23:54 48 11:31:19 65 11:35:37 52 11:48:40 36 11:58:25 Finish 12:02:14
The Event Management system will add this 5-control run to the result products just as though the indicated splits had been successfully stored in the GeBE printer's memory in the first place. No course name need be specified in the command; the system will deduce which course was run, as it normally does with any set of splits from the GeBE printer.
If a runner forgot to download on the GeBE printer but the course she ran is known and her start and finish times on that course are known, then the simpler form of the addrawresult command can be used to add a result for a successfully completed run in which all the leg times are proportional to average leg times for the runner's course:
addrawresult 47016 Brown = Start 10:52:00 Finish 11:48:33
In this scenario, we imagine that (1) the runner's start time was read from the Start sheets, (2) her finish time was revealed when the Finish control unit was uploaded on a laptop to make a "missing runners" report, and (3) the runner herself told the event organizers that she ran the Brown course. The event organizers knew this runner as a person of high moral integrity, so they accepted her claim that she in fact punched all controls on her course in the proper order.