JOSM/Plugins/GPSBlam

From OpenStreetMap Wiki
< JOSM‎ | Plugins
Jump to navigation Jump to search

GPSBlam is a JOSM plugin designed to exploit the availability of multiple GPS tracks over the same straight-line path, to obtain a handle on the location and direction of the path with optimal accuracy. This can be useful to nail down any offsets in existing content or imagery.

Usage

  1. Load any GPX tracks you wish to use, and make invisible any GPX layers you do not wish to use
  2. To analyse a collection of tracks made while stationary at the same location:
    1. left-click and hold at the point
    2. if needed, adjust the size of the selection circle using the scroll wheel or arrow keys
    3. release the mouse button
  3. To analyse a collection of tracks made while moving along the same straight-line path:
    1. left-click and hold near one end of the path
    2. drag to near the other end of the path
    3. if needed, adjust the width of the selection shape using the scroll wheel or arrow keys
    4. release the mouse button

A new GPSBlam marker will be added to a layer labelled GPSBlam. (Make sure it is visible.) The marker appears in green and consists of:

  • crosshairs: these meet at the centroid of all GPS points and indicate the degree of spread of the points in the directions of maximum and minimum spread
  • error ellipse: this boundary is a conservative estimate of a 95% confidence bound for the centroid of the points

Often you will need to zoom in to discern the ellipse: generally it will be less than a few metres across in its smallest dimension.

Interpreting the results

Basic theory

The "centroid", where the crosshairs meet, represents the two-dimensional mean (average) of the points.

The mean of statistically, for independent, identically distributed data (iid, which GPS data are not) would itself have a standard deviation equal to the standard deviation of the data, divided by the square root of the number of points averaged. So, it gives you a more precise estimate of position than using any point alone, or even by judging the centre of a spread of points 'by eye'.

Unfortunately, GPS errors are not iid. Some sources of error change in sign and size over time periods of less than a second, but others may persist for minutes or hours. Therefore, it is not valid to take a log of positions over a few seconds or minutes, average them, and then assume that the averaging improves accuracy according to the square root rule. This will only work if data are taken over a time period that is longer than the correlation time scale of most sources of error, which means data taken over multiple days.

As a conservative approach to estimating the standard deviation of the mean, instead of dividing by the square root of the number of points, GPSBlam divides by the square root of the number of different days from which data have been used. In essence, the means of individual days are taken to be iid. Generally, this will yield an error ellipse that is bigger than a true 95% bound, because it ignores the fact that some sources of error are effectively reduced by averaging within each day.

Using GPSBlam to determine content or imagery offset

GPSBlam can be put to use to determine any offset in existing OSM content or imagery. If you have a GPSBlam marker from multiple tracks made at a stationary point such as a street corner, this alone could be used for alignment. If your data was all taken while in motion, two GPSBlam markers made along paths running roughly at right angles will suffice.

The more markers, the merrier, but beware: having 5 markers all indicating, say, an imagery offset of 2 m to the west should not necessarily be taken as any more reliable than one marker showing this. If all 5 markers came from the same set of GPS tracks, they are not statistically independent, because of the persistence of certain sources of error for seconds or minutes. So whilst it may be tempting to break up a long, straight run of tracks into a series of markers, don't read too much in to the appearance of a consistent but marginal offset amongst such a set.

It is better, therefore, to confirm any offsets with another set of tracks taken on different days (which need not be at the same position as the first set).

Obtaining bulk quantities of GPS data

All of this is only very useful if you have, for a given location or path, data taken on dozens or hundreds of different days. And, preferably, different paths with similar data taken on still different days. That's a lot of work.

Do you know any keen runners or cyclists? Many will routinely log GPS data for their activities, and even advertise this online with services such as Garmin Connect and MapMyFitness. These sites, or running discussion forums, could be a useful source of contacts who may agree to share data with you.

Example

Here is an example session using 250 days of tracks recorded while running with a Nokia phone handset in a waistband holster. As you can see, there is great dispersion in the data, but even so the number of tracks is so great as to render as a blob of grey, making averaging 'by eye' impossible. This isn't very good quality GPS data, but with averaging we can make it useful.

Having loaded the GPX files and selected GPSBlam mode, we select a section where all tracks were recorded on a narrow, straight footpath, taking care to avoid the zone of data spread around bends at either end of this section. (An OSM way betrays the presence of a wiggle in the path, but were this not here, we could make the GPX tracks invisible and notice it on the imagery, instead.)

Gpsblam1.png

Once we release the left mouse button, a GPSBlam Layer is created and a green marker appears:

Gpsblam2.png

The increase in precision is so great that we must zoom in to see our error ellipse:

Gpsblam2zoom.png

In that part, I nearly always run on the white footpath shown. It appears the imagery may be offset by approx 3 m southwards. We can't say much about east-west from the above.

Let's try to verify this in another nearby location:

Gpsblam3.png

Well, here the error ellipse overlaps with the footpath I run along! So, let's rule out any thought of a widespread north-south offset. What about east-west? Two markers:

Gpsblam4.png

Gpsblam5.png

These two are both suggestive of an imagery offset of 5 m eastwards, and I rarely run through both these parts on the same day, so there should be no correlation between them due to persistent GPS errors. With a bit more investigation, I might consider offsetting the imagery.

On the other hand, the OSM way is very clearly offset and in need of fixing. Indeed - check out the mangled roundabout in the first image above!