Monkton Heathfield Street Series - Thursday 14th December

Monkton Heathfield is an area of Taunton not used before. There is an interesting mix of traditional streets and new development interspersed with paths and recreation areas. As the last event before Christmas the club has booked a room at the village hall from 6-8pm. There is ample parking and post run analysis can be fuelled by mince pies and mulled wine.

I think I’ve managed to extract a working set of scores from the GPS tracks!
One little thing on the rules to clarify - white is OOB, and green lines (hedges) are uncrossable. I had to do a few corrections for people who approached or left #41 SE (even if there was a path, it wasn’t mapped and most people correctly took the long way round as a result). Also one for someone going through a hedge between #12 and #51.


My first bit of orienteering for ages. Just coming back after a bruised shinbone, this was my second run since October. Despite the pain every left foot impact, it felt good to be out. Things came up faster than I was expecting, probably having used a 1:7500 map in my last few outings, and with hindsight I could have picked up the remaining three controls by taking a few more detours earlier (and being a bit more confident of my remaining energy once I’d discovered the hand-drawn line by #13 was an uncrossable boundary).

Was interested to see how the map would come out- much better than I had imagined as it happens, as fences were not shown. It can make a lot of difference to legibility and these features typically add very little of value to the user

with no walls or fences…
…with walls…
…and with default settings - fences shown …urggghhhh!

1 Like

The new setting on OpenOrienteeringMap allowing switching off certain symbols is really helpful. Its making a big difference to my map for the Wellington event next month.

Planner comments:

My apologies for problems in the technology involved. Between Purple Pen, Google earth, kmls, kmzs, OCAD, OOMap, Open Street Map, tiling and coloured circles errors ensued. Additionally I know the numbering was correct at one stage and then that wasn’t used. There is nothing hugely hi tech but going through the process after a two year gap makes it hard to master confidently.

Steve’s input below I think is most helpful for me and others for future event production.

Won’t dwell on it and hope the good area, course challenges and social aspect made for an enjoyable evening. I know Alasdair will hopefully be able to produce some acceptable results - thank you.

Back to baking rock cakes for me now.

Steve’s investigations:

When I got back, I couldn’t resist trying to shed a bit more light the proceedings.

I took my GPS track and:

  1. Loaded into Google Earth – all seemed spot on, even which side of the street I ran on
  2. Loaded into Open Street map with a Bing Satellite map as a background and again everything seemed to match.
  3. I used MapRun on my Garmin watch and when I compared the hard copy map with the MapRun map downloaded on my phone there was a difference. The control circles were in different places when comparing the hard copy and the MapRun download (on phones and watches).

On the hard copy map the circles appear to match all the descriptions but, on the phone, electronic version and, presumably where the GPS would recognise the control to be, many of the circles are displaced from the description and the hard copy map control site, some over 20m. However, some are the same on both the hard copy and the electronic versions. Most strange.
4. Also, as we spotted earlier, the control numbers are different on the hard copy and electronic versions.

There are several different routes to generate the KMZ and KML files that are used by MapRun, and I think the features in OOM and MapRun have improved over time. Did you use ‘MapRun Create KML Course’ ? I think you can now create everything using OOM and the Create KML Course tool that includes a satellite image and do not need to use PurplePen and Google Earth. For me, it seems less complicated and reduces the risk of error by only using two sets of software. (Although, I don’t think they can handle different coloured circles!!)

Trying to work out where it went wrong, I’ve loaded the kml used to generate the MapRun courses into GoogleEarth.

3 = #12 streetlamp
5 = #15 SW outside corner of stone wall

As the controller of Street Series events I really should have spotted both the issues when I checked before loading. So a large chunk of the blame falls on me.

In terms of process for planners, I will investigate the improved online tools in the hope they make it eve easier but for now, the safest is to place controls on Google Earth using the actual aerial photos not an orienteering map overlay that could be skewed or stretched. Choosing control features that are easily identified makes this easier - hence streetlamps where the pin can be placed at the base of the shadow of the lampost.

Thanks all who have contributed to the post-event investigations. You have all done much better than me - I couldn’t get the tech to work at all! My thanks to Alasdair for crediting me with a score.
I had a really enjoyable run, and thought it was an excellent race.
Thanks to all involved in the event, it seemed to be well received by those who took part, but particular well done to Rosie for planning and Alasdair for coordinating.

1 Like

Sue and I did the event on a different evening as we had prior commitments on the Thursday. Although we both were pleased with our outing (thank you Rosie for all of your hard work) we had similar IT problems to others. In the subsequent discussions one aspect of the planning process that doesn’t seem to have been mentioned is Testing which I think should be given a little more prominence in event planning guidance.
My experience is that testing (visiting each control site) at the Checksite stage (the Checksite is created with a default Punch Tolerance of 15m but ideally this Setting should be changed to 5m) and then again when the final event has been published (this will have a Punch Tolerance of 8m) will give confidence that the event should work fine on the night. Doing the testing well ahead of time provides the opportunity for making adjustments, re-publishing and re-testing as appropriate. This was particularly relevant for me as I had to re-vamp some of my Langport controls (and the hard copy map) to take account of the floods that rendered some of the original controls sub-aqua!

Thanks to all for helpful comments. Yes Ray, my Checksites visit worked so far from the features that I was obviously somewhat naive in assuming that was sufficient for things to work equally well on the night. Alasdair’s intention to fine tune some of the guidance welcome.

I also found the checksite function very useful for one I planned some time ago and set the tolerance to 5m for fine tuning. Then for the actual event the tolerance was set to 15m to err on the safe side, so phones were beeping a bit early but would rather have it that way round.

It may help those with low end phones to get a beep. We ran some tests on Graham’s phone which only has access to the GPS system and the accuracy was much lower than mine which also has Glonass Galileo etc