Longer Events

[MichaelRaz]

A while ago I posted an excel spreadsheet that demonstrated how to pull the (public) results directly from a MapRunF page.  I was implementing this into a more complex merge of an Adventure Race (running, biking and canoeing) that I was helping with.  Many people (well ... one) asked me to update on the use of MapRunF for a longer event such as this.  I’ll keep it short but open to questions and willing to provide some more lessons learned if anyone is thinking of doing something similar.
The event included both a 3hr and 8hr category.  Format was basically a Score-O (N type) without a mass start.  A back up system was in place (marking the code down at each control).  Registrations instructions included links to setting up MapRunF as well as encouraging testing.  A back up battery for phones was also a race requirement.  MapRunF App Names needed to be provided during the registration period.
Big difference between the 3 and 8 hr group (separate start times).  Out of the 20 or so 3hr teams, over half ended up going out without the app working or the app failing during the run (likely due to the phone going to sleep).  I worked with one team that was hitting the “NO” to the phone request to allow the app to use GPS!!
In contrast, out of the 68 8hr teams, I think only two teams ended up without a MapRunF result at the end (one had forgotten to plug their phone in and it died).  Despite one bug in my spreadsheet code, this allowed the very quick computations of results.  As the teams uploaded at the end, the refresh button in the spreadsheets updated from MapRunF results, these being matched to each team name, processed based on some unique needs for the race and ready to be confirmed by the event team.  As entries were marked “final” they became available for being published on the race results.
So, if used again next year, a more definitive document will be put together to direct runners on how to test the installs better.  Hopefully by then we can also use a mass start so there ends up being a self-inflicted penalty if still screwing around at the ‘GO” time.
In general, the issues noted are not related directly to MapRunF and, especially for the 8hr event, it worked really well!

[Scott Simpson]

Total Nube to all this.
Got a question that you might be able to help with. Is there a limit to the size of area your event can cover ie 50km x 50 km ?

Thanks

[Peter Effeney]

Scott,

I think that should be achievable.

The issue is not so much the area, but the size (MBytes) of the map file. The older MapRun (not MapRunF) App had problems on iOS with map files > about 1.5-2MB. There is no specific limit for MapRunF, and the file size can be managed by reducing the dpi of the image... but of course the image on the phone will become lower resolution and more grainy as you reduce the dpi. This is probably not an issue, as most commonly people run with a printed map anyway. (and the map plays no real part in the functioning of the App). (Provided all runners user MapRunF/MapRunG). We recommend tiled KMZ files (rather than one large image file) so that the devices have the opportunity to manage memory more efficiently.

The other issue is the number of controls - Which with MapRunF doesn't have a specific limit. Although lower-end phones with less memory could have issue with a very large number of controls (I mean hundreds), or very large map files. MapRunG on watches with small memory (eg 64kB) can be an issue as well.

It's easy to try it out with CheckSites. If you are pushing the limits, checking it on a range of lower-end devices is a good thing to do.

Regards
Peter

[Scott Simpson]

Thanks that all makes sense, I think!