Ignore consecutive controls with the same code in IOF XML files

[LukeWoodward]

Event 8312 on splitsbrowser.org.uk presently fails to load in SplitsBrowser, with SplitsBrowser grumbling about a competitor having the wrong number of controls.

This event uses IOF XML v3. Two of the ten competitors in the 'Challenger Dames' class have 28 <SplitTime> elements listed against them, whereas the remaining eight have the expected 27. 27 is also the number of controls specified in the <Course> for this class.

The two problematic competitors both mispunched and both have consecutive controls with the same code but different times. Commenting out one of the duplicate <SplitTime> entries for each competitor allows the event data to be read.

I don't know how the file got generated with consecutive <SplitTime> elements for the same control. None of the <SplitTime> elements have the attribute status="Additional", which SplitsBrowser recognises as a control not on the course and so ignores.

In orienteering it doesn't make sense to have a leg from a control to the same control. So, for this situation I would propose deleting one of a pair of consecutive controls if the competitor has more than the expected number of controls. I would also prefer to restrict this to competitors who have not completed the course successfully, as that way we're not letting the data from mispunchers, DNFs and the like prevent the data from successful competitors from being loaded.

[Maprunner]

It looks like there are two issues here, and your proposed solution may not work as expected.

Punching the same control twice is fairly common (normally just so you are sure you really punched), and an SI card can record this as separate punches depending on exactly how long apart the two punches are. (I think Emit just keeps the last punch at a given control.) It then depends on the results software as to whether you see the two punches or just one, and then whether or not they both make it into the XML file. But punching twice is perfectly acceptable and leaves you with a valid result. So if you do filter then you need to do it for all runners, not just those who have not completed the course.

This assumes the rules used to generate the XML file are the same for valid and invalid results. It may be that some tidying up isn't done for invalid results so this sort of things gets left in.

[LukeWoodward]

@Maprunner : thanks for your comments. I've taken a closer look at the offending file, and there's more going on than I first thought.

My strategy of removing duplicate controls if the competitor has more controls than there are on the course doesn't work. The two competitors with 28 controls have two repeated controls. Furthermore, all other competitors have one repeated control. Furthermore, some valid competitors punch control 127 before 128 and some punch 128 after 127. There are other control ordering inconsistencies in this file, particularly on the Challenger classes.

It turns out that this file isn't for an ordinary orienteering event but for an adventure race. The total times taken are somewhat non-standard for an orienteering event: the winner of the 'Pro Heren' class took just over 8 hours.

In summary, I don't think that SplitsBrowser can really handle this file. I don't think it makes sense to compare on the same graph competitors who haven't run the same course. And even if I did let through courses where the controls weren't in the same order, I don't see how I can reliably detect and remove the extra controls. Instead, I'll add some validation to make sure that the controls within a course are consistent.