Mobile Phone Scanner

[EddieH]

Maybe we should all move to Portugal. No guarded controls there. They do these events all the time and I am told the only control that has ever gone missing was by a peasant woman who thought it was rubbish and put it in her bin.

Why are British youngsters so different?

[DJM]

Eddie,

They also drive 1 metre long steel stakes into cracks in the ground and cable-tie their control trestles to the stakes. Not quite so casual after all!

And all the Sprint controls were guarded at WMOC - it's just that you didn't see the guards!

And they didn't at first tape any of the Sprint sites as they assumed that the local youths would remove the tapes as soon as they were put out. After some persuasion, they did tape the sites ... and the tapes were still there a week after the races - so they needn't have worried!

[King Penguin]

Surely the tapes should have been removed when the controls were - good environmental practice and also avoids the risk of confusion at the next event on the same area.

[EddieH]

Interesting David, and I am sure VERY wise at WMOC. I am told however that normally they just put out the controls and only the one has ever vanished - mind you that probably only applies to one club's events.

[martin]

I got a cheap GPS data logger (Globalsat DG100) on friday. I tried it out at Brereton Heath on sunday, and I put my route up on top of the latest routegadget of Brereton on the MDOC website.

Does anyone know any easy ways of getting the GPS trace directly into OCAD?
(I have written a simple converter to dxf, but it is not ideal).

The GPS trace seems to be more accurate in places than the ocad map.
Ideally if I were updating the map I would like a program to morph the existing ocad
map to make it locally fit to a set of global coordinates. Anyone got any ideas?

Martin

[Wayward-O]

I've had a similar experience. I bought a cheap GPS logger (iBlue 747) from HK on eBay.

details here: http://www.transystem.com.tw/p-gps-iblue747.htm

Used it for a run and then had the fun of manipulating the data to get it onto RG. I ended up outputting the data as a .csv file, editing in Excel to create a .csv file in Universal CSV format and then converting this file to GPX XML using the GPSBabelGUI free GPS data translation program.

This file was then uploaded to RG and pulled / stretched to align as best with the course on the map using the three points provided. When uploaded, I found that it's not possible to accurately align the GPS course to the map, as the map is less accurate (when I uploaded the GPS to Google Earth, it was a very close fit to the terrain). The only way that I can see to more accurately fit the GPS to the map and course currently would be to increase the number of points that can be used to stretch the GPS route.

If a new type of e-card was produced that merges the functions of a GPS logger with that of a conventional e-card (SI or EMIT) such that a control punch could be aligned with a specific point on the GPS track, then updated upload software could be written to map the GPS track to the course through each of the controls.

[epocian]

As a complete ingoramus on GPS s I would like to know how accurate they are?
If you check on the WMOC Routegadget for the Sprint final in Portugal (M60 A final Henry Marston has put on his route using GPS and it would appear he's gone through several solid buildings and not followed streets at all on several legs.

[Wayward-O]

These GPS units are usually quite accurate; mine is quoted as within 2.5m, but in practice is better than this. As a trial when I first got mine, I went for a couple of mile walk, loading the track to Google Earth on my return. The track was very accurate, showing me walking on the correct side of the road, etc. This was with a clear view of the sky, so the max number of satellites in view.

As in my previous post, I used it for an orienteering event. When I viewed the track on Google Earth, the track followed very close to where I believed that I'd run. The problem comes when a GPS track is uploaded to RG, as it tends to show up any problems in the accuracy of the mapping. My track uploaded onto RG showed me running parallel to paths when I'd run along them, turning corners earlier or later than on the map, and missing some controls by a fair distance, all of which I put down to inaccuracies in the O map, as none of these were evident when the track was uploaded into Google Earth.

[Spookster]

Different GPS receivers have different levels of accuracy (so basically you pay more for one that has a better aerial), but all should be capable of +/- 5m, and some will get +/- 1m, in the right conditions.

The number of satellites in view affects accuracy - the more the better. Accuracy is reduced under heavy tree cover, but generally good receivers will still get 5-10m accuracy in a forest. Buildings have a different effect, in that as well as blocking line of sight to satellites, you can also get reflections of the signal, both of which reduce accuracy. Even so, accuracy should still have been good in Portugal as they weren't very big buildings.

The process of putting your GPS route onto RouteGadget involves "fitting" the GPS track trace to the map image. You can spend a little or a lot of time doing this, and how much effort you put in affects the accuracy of the result. And of course O maps aren't necessarily "right", even though they are perfectly acceptable as maps.

I was surprised at how poor the GPS TracTrac traces were at WOC last week, with some runners occasionally reported as being up to 100m away from where they really were. I guess the GPS receivers are quite small, with fairly low power, to make them easy for the runners to wear, but the result is significantly reduced accuracy.

[geomorph]

These GPS units are usually quite accurate; mine is quoted as within 2.5m, but in practice is better than this. As a trial when I first got mine, I went for a couple of mile walk, loading the track to Google Earth on my return. The track was very accurate, showing me walking on the correct side of the road, etc. This was with a clear view of the sky, so the max number of satellites in view.

As in my previous post, I used it for an orienteering event. When I viewed the track on Google Earth, the track followed very close to where I believed that I'd run. The problem comes when a GPS track is uploaded to RG, as it tends to show up any problems in the accuracy of the mapping. My track uploaded onto RG showed me running parallel to paths when I'd run along them, turning corners earlier or later than on the map, and missing some controls by a fair distance, all of which I put down to inaccuracies in the O map, as none of these were evident when the track was uploaded into Google Earth.

Here's some geeky stuff about GPS accuracy relative to O-map accuracy, with a lot of the heavily technical removed:

Differences will be due to at least two factors:
1) In order to represent a round earth on flat paper cartographers use Projections. These are mathematical ways of portraying the elipsoidal earth on a flat surface in a consistent manner. ALL projections introduce distortion of the truth in a consistent manner varying with distance from either a point or a line/lines of zero distortion, but they do it in different ways, depending on the mathematics used to control the projection.

Google Earth and GPS use the same type of Projection and therefore are consistent with one another. You will find differences, but these tend to be the result of errors in the satellite data relative to the photographic data superimposed by Google - its a really complex area and there is reams of software/mathematics to minimise this.

Ordnance Survey uses another way and this distorts in a different manner. The degree of separation from the Google way will depend on where you are with repect to the OS zero distortion point. It is also a function of terrain steepness.

As regards absolute truth OS claims that it's projection is closer to the truth than Google's for the UK. If GPS were to use the same projection system as OS then you would find less errors in the UK with OS-GPS than Google-GPS.

2) There may still be inaccuracies in some of the OS mapping with respect to the true position, resultant from a number of historical factors, but more likely to be manifest in remoter areas.

So please don't refer to O-maps being inaccurate; just inconsistent wrt GPS/Google.

[orunner]

Here's an interesting solution to the Urban orienteering marker issue which I've used a few times.
Use lamp posts as markers. Mostly they have a unique local authority code on them, are well fixed to the ground to make them vandal proof, conveniently situated on road junctions and paths in the urban setting - and even have a light on top for night-O !
Competitors' equipment consists of a pencil and a card to mark the last/first character of the post's code.
I can hear the techno-freaks wailing already that it's cumbersome and doesn't give the splt times etc. etc. For introducing newcomers and organising fun training events, does it matter ?
It's easy to lose sight of the objective and allow the method of achieving it to take more importance.

[redkite]

I used lamp posts for an event the other week in Cardiff. However, as the lamp post numbers are sequential, and you can work out the number from a long way away, it was still necessary to stick a random letter onto each control post. Seem to work ok though.

[SJ]

Lamp post codes are one of the popular "control sites" used in Street-Os put on by SLOW, Saxons etc.

Sometimes they would have more than one code on them so it was helpful when the organiser gave the competitor the first few digits so that they knew which code to look at and only had to write a couple of digits.

It's certainly more time-consuming for the competitor than electronic punching, but everyone is handicapped by roughly the same amount of time. The time-saving for the organiser means that these types of events are much easier to hold and therefore it makes event organisation more accessible and probably results in more events.