Suggestion: Punch tolerance set by control

[Mark3]

MDOC just held an event which had half the controls on an orienteering map and the other half on an OS map. This worked fine, except for the punch tolerance to be acceptable for the OS map, the orienteering controls were trivially easy.

It would be great if controls could be set to have individual tolerances, or grouped such that controls 1-20 have tolerance A, controls 21-40 have tolerance B, etc.

That would also allow greater tolerance to be set in known dodgy GPS signal areas but keep it at a lower level when signal is good.

[Peter Effeney]

Mark,

Thanks for the suggestion. This has come up a few times before, but it would require quite significant change across quite a few parts of MapRun. In the past, we haven't thought this feature would be used often enough to warrant the investment.

So, just to check on a couple of things:
- The matter of the desire to place controls in locations that are less "GPS-friendly" is understood. (eg bottom of deep gully, under heavy vegetation, near large buildings). The desire to compensate for the location by increasing the punching tolerance is a logical option. However, this does increase the variability of outcome across runners which could impact fairness. So the recommendation is generally to try to minimise the use of this type of control (if possible).

- On the matter of different "overlay" map types. The general recommendation is to avoid setting control locations by simply placing them using the OS Map or Orienteering Map. Moving a control on a 1:10000 Orienteering map by just a line-thickness (say 1mm), moves the control by 10m. This is sufficient to make the GPS-punching unreliable. It is recommended to, at least check and finalise, control placements using the MapRun Console (KML Create function), where the actual location can be observed on Google Satellite imagery. (Or use Google Earth or a similar tool to check the KML file).
In summary, we consider that no matter how accurate Orienteering Maps/OS Maps are, they just don't allow the level of zooming to accurately place a control at the precise Lat/Lng for reliable GPS-based punching. Some clubs do this and do get OK results, but it's better to use high zoom on satellite imagery or Lidar or a fix from high quality GPS equipment for control locations.

- A tool that can be insightful in quickly identifying problematic controls (only after the event(!)) is the "Results Validation" tool. See: http://www.p.fne.com.au/rg/cgi-bin/ResultValidation.cgi If a particular control is a near-miss for multiple runners it may well be mis-placed.  Otherwise, this report can help the organiser to use Admin HITMO to adjust results, to correct for missed-punches (without having to open each result for checking individually).

I'm happy to hear details of specific circumstances or counter arguments, as setting the punching tolerance by control is obviously technically feasible (just onerous to implement, and potentially not commonly used).

Peter

[Mark3]

Hi Peter

Thanks, I appreciate your first point re dodgy locations - better just to avoid them.

My second point was more around events which have a mixed map format. When navigating on an OS map for example, I think it's reasonable to have a (say) 15m tolerance because it's very difficult to navigate with precision at 1:25k scale.
But if the other half of the event is based on an O map at 1:5k scale, suddenly a 15m tolerance is way too large because I could easily be 10m away from a control and not actually have found it yet.

So it's less around placing the controls, and more about the in-race experience of finding them.  

[Peter Effeney]

Mark,

Yes, I agree with your point about the focus on in-race experience.

I would suggest that the combination of the Map and any control description, needs to provide an unambiguous definition of the point on the earth that the participant needs to visit. This is vital in the case where there are no flags (marking control sites) in the field.

In "traditional" orienteering, if the map/control-description shows the control as being at a road junction, when the participant arrives they would see a flag say on the NE side and go there to punch. Without a flag, the participant doesn't have all the info they need. This leads me to suggest that "flag-less" controls need to be on "obvious" point features. When a participant "arrives", it needs to be obvious, exactly where a flag would have otherwise been hung.

In traditional orienteering, controls shouldn't be on features that are not shown as symbols on the map.

Maybe with an OS Map it is necessary to bend this rule(?), but maybe a control description can compensate to provide a nominated point feature.

So with the participant heading for an unambiguous point on the earth, the GPS punching tolerance remains being an issue of: what tolerance is required to allow for error in the Lat/Lng of the control and error in the GPS fix of the device. (I haven't thought of punching tolerance as being allowing for participants to visit a general zone/area on the ground, although that would be possible. The goal in my mind has been to emulate punching at a flagged location.)

Sorry if I have missed the point.... or are coming at this from a different perspective. Please let me know if you would like to respond/elaborate on the challenges you face.

On the matter of allowing the setting of punching tolerance by individual control, I'm still thinking this would not be a commonly used feature. But I am open to hear from others on this matter.

Peter

[Peter Effeney]

Mark,

Sorry, upon re-reading my previous reply, it looks like a lecture. Sorry it wan't intended to be.

I was trying to explore how to get a better experience with MapRun in its current form, but I ended up telling you things I'm sure you are already very familiar with.

Peter

[Mark3]

Hi Peter, don't worry, I didn't take any offence!

I totally understand what you are saying - it shouldn't matter the type of map you're using because a single point is being specified either way.
But intuitively, maybe it's just me - I feel like because it's impossible to navigate precisely on an OS map, then I shouldn't need to, whereas because I can navigate precisely on an O map, then I should have to.

So on an OS map I would expect to only have to run vaguely in the vicinity of the path/wall junction (or whatever), whereas on an O map I would expect to be pretty much standing in the centre of the small depression.

Maybe it's just me!

[Peter Effeney]

Mark,

Yes - I understand your thought process.

I'll keep the issue of having a setting for tolerance by control on the list of possible enhancements.... but I won't promise anything at this stage.

One other thought... If you are going "off-piste" with some events, there is the option of using either Satellite Imagery or "standard" Google Map as the background map. That is, you can now publish events without needing a KMZ file (or you could run off the edge of a KMZ). This may need some experimentation, as it relies upon Internet access during the run to download background image tiles from the mapping service.

Peter