RoadHog: Co-Ordinates

This document describes some of the problems you will encounter with anything that deals with "real" co-ordinates and maps.

Map Projections

Before you can map GPS co-ordinates to a raster map, you will have to find out the projection used in creating that map. If you do not know what a projection is, read the excellent pages at The Geographer's Craft.

The projection, together with information about the position and extent of the raster map, gives you a rule how to convert a latitude and longitude into a map pixel position. Furthermore, you will have to make sure that the co-ordinates you are getting from your GPS and the raster map use the same map datum. If you do not know what a map datum is, again, follow the link above. GPSes normally use the WGS-84 map datum. My GPS can be set to use any other datum as well, but the downloaded output will always be WGS-84. Not having the right map datum can introduce errors of hundreds of metres.

In my case, I could safely assume that the map I got was using the "British Grid", a transverse Mercator projection with certain parameters, based on a 1936 Ordnance Survey map datum; this is commonly used in Britain. I had to find algorithms to convert the WGS-84 output of my GPS to grid values which was not too difficult.

But the maps are... wrong!

Of course they are. Has nobody ever told you, son :-)?


These pictures show Braemore Junction as depicted on the 1:50 000 Ordnance Survey maps, and on the digital Bartholomew road map (probably something like 1:250 000 in comparison) which I am using on my site.

Do not look at the absolute size - look at the relative properties. Look at the shape of the A832 as it leaves the junction to the left, or look at how wide the gap (the Corrieshalloch Gorge) between the roads is, measured in road-widths. It is probably about six road-widths on the OS map, and only two on the Bartholomew map!

What this example tells you is that map makers cheat. They have to cheat if they want to create readable maps; they have to paint roads wider or narrower or further apart. They have to smoothe some bends, change some angles. Sometimes of course they are plain wrong, as in this comparison where the Bartholomew folks have put the village of Achnasheen on the wrong side of the roundabout:


And see how the railway station is further north than the roundabout on the OS map, and further south than the roundabout on the Bartholomew version? And see how far away from the road the river is?

Since your GPS does not know about all these dirty little map maker's secrets, you will end up with points that do not fit your map exactly (unless your map is very accurate indeed - and in that case the GPS errors will trouble you).

The brute force approach to matching GPS and map

Before I concerned myself with map projections and such, I used a simple way to match a GPS track and a scanned map: I assumed that it would be possible to find an Affine Transformation that does the job. An Affine Transformation is basically any combination of rotating, stretching, shearing and translating an image or, in other words, any operation you can perform on an image that will keep parallel lines parallel. I wrote a piece of software that would allow me to stretch, rotate, and move the GPS track on the scanned map until it fits. Then I would save the parameters of the Affine Transformation - a 3x2 matrix of numbers - and that was it. These parameters would enable me to find the map pixel for any co-ordinate pair, without me having ever bothered about what the map projection, map datum, map boundaries or anything were.

This approach works for reasonably small stretches of GPS track, say, up to 20 by 20 kilometres. Anything larger, and you are likely to encounter problems - whenever you've got one end of the track right, the other won't match and vice versa.

A (slightly) subtler approach

I am now using digital maps to which I apply "correction vectors". That is, every so often I take a GPS-measured point and move it to where it "should" be according to the map; all untouched points in the vicinity will move in the same direction as their neighbours. With enough of these vectors, I can make any GPS measurement "gravitate" towards the roads (where I know they should be), and this works reasonably well.

I still have problems where two roads are so close together that GPS errors may cause a measurement taken on one road to be closer to the "wrong" road than to that where it should be; there's some manual fiddling involved in solving these. As a "last resort", I can also manually correct the computed pixel position for a photo's co-ordinates but I try to use that as little as possible.

Back to the index

  Frederik Ramm, 2001-05-24