Fixing alignment of traces from different offsets

As we all probably know, Bing imagery is usually slightly misaligned and requires offset adjustment for tracing. However, it can be difficult to determine the exact offset, and not every contributor is aware of the issue. In many areas, streets traced from different periods of imagery don’t align together properly. When trying to fix this, how should I determine the “correct” offset to use? I’m mostly looking at Bangkok, so the issue isn’t a lack of traces, but being on 50-metre-wide-roads, they don’t really help in choosing between offsets of a few metres.

I don’t think there is any better way than using lots of GPS traces to determine offsets on Bing. When enough traces are present it gets much easier to draw those streets. As for accuracy, you are not geing to get much better than 10 meters no matter what because our measuring instruments (consumer grade GPS) aren’t accurate enough.

My GPS has a feature that averages many readings over a period of several minutes. Supposedly those points are fairly close to reality. If you were to take several of those readings, like at the corner points of a big square a kilometer on a side, you could possibly align Bing that way, but YMMV.


At one time I was against aerial mapping for this reason. In some places Mapbox agrees with the GPS traces, in other provinces Bing is better. Usually Bing. Now I think we should just draw every road. This map is now being used by lots of people. Thousands of downloads on I’ve met lots of bike riders and they usually use, BC they don’t need phone conex.

This is a long term project and as GPS traces accumulate the roads will eventually get aligned.

Google Maps is not immune to this problem, lots of roads on their map are not aligned with the aerial.

On any map tile, only the center is likely correct. On the edges the angle from the airplane is steeper. You can see the sides of buildings more there. The actual location is calculated from the best guess of elevation of the surface. It is not perfect.

What we need most is a lot of GPS traces. Maybe someone knows a UPS driver who would bring a logger.


the topic of aligning ortho-photos is quite complex. The imagery needs to be correctly allign on x/y and also regarding the rotation of the image.

As Tom already pointed out there are parallax errors on the edges of a picture. Also the surface is not flat. So If you come to mountains/valleys you get more distortions.
Typically one step is to overly the image with a digital elevation model and by this trying to recover those distortions.
If the elevation model and the image do not align correctly it can get much worse instead of better.

The result of such a processing is what we typically see as the imagery.

When it comes to GPS you get another level of errors introduced. GPS can be off by meters. You can even have systematic problems (steep mountains, building, etc) where the signal is always wrong in a similar way. And then you can have problems with the GPS unit having SBAS turned on. I once forgot to turn it off. Had two loggers in parallel. And one was systematically off by 100m.

So best would be to have plenty of GPS tracks from different sources. By this you can guess where the real road typically is. And maybe hep you to spot not suitable imagery. Then then only thing you can do is switching between Mapbox and Bing to see if the one or the other is more suitable.

Mapbox does a similar thing large-scale:

This is getting quite complicated. Actually, I’m just trying to correct the offsets between elements drawn at different times, and need help deciding on the “standard” alignment to use. The differences are rather small (usually much less than 10 metres), but in dense urban areas it’s enough to make buildings overlap.

Take this area of Thonburi for example. There’re plenty of traces, and they show that the default alignment is quite good, but they don’t really help decide how to fix a 5-metre overlap (or gap) between two adjacent neighbourhoods. Should I just randomly pick a large area and align everything nearby to it? Or simply re-align everything to the current imagery?

Heh. I just realised that JOSM has the option to colour GPS traces by direction, making them much better for aligning roads.

I discovered that option quite a while ago too. It does help.

As I add more and more traces to OSM, I observed that most of my riding is at the extreme left side of the highway because I ride either a bicycle or motorcycle most of the time. That could lead to systematic unintentional errors on the wider highways I frequently use. It’s good to be able to see the colors in that scenario because I can better place the highway between the two colors for east-west, or north-south.

Ha, don’t worry Dave, I counter that by spending all my time in the fast lane & cutting the bends :laughing:

Okay, thanks Russ.

From the top of my head.
These differences would be avoided by using a DGPS. D standing for differential.
Basically a correction signal sent from a land station that measure the difference between the GPS signal received and and the known location of the land station.
These correction are applicable for about 300nm. They can be sent in different ways, and normally a paid subscription is needed.
There might be webpages listing “historical” corrections.
The correction is sent as distance and direction.
Again, from the top of my head.

I think you’re quite right about the accuracy of a dGPS signal. However, the cost of the equipment and the subscription service are pretty steep. I explored the idea of purchasing dGPS equipment from Trimble and was blown away by the prices. I don’t recall offhand the exact amount but it was way out of reach. Most OSMers probably cannot afford such expenses. I know I can’t.

Let me repeat my warning from September.
SBAS is quite similar to what you wished for. They operate a network of ground stations with a known position. The GPS signal is distorted in the ionosphere. And by applying correction factors of those ground stations the accuracy can be significantly enhanced.

Downside: The correction is not valid for Thailand, even if the signal can be received. What can happen is that the receiver then applies a wrong correction factor.

So even if your GPS logger manual suggests turning it on: don’t do. It does not help in Thailand, maybe even harm.

If someone wants to play around with differential GPS correction, you can have a look at the open source rtklib:

But as the typical use-case is precision farming I have serious doubts that it can account for the major factors of deviation in urban canyons like Bangkok. Here effects like blocked satellite visibility or multi-path/reflections are much worse.

It could help to have a multi-constellation receiver making use of GPS/Glonass or even adding Beidou/Galileo to improve positioning accuracy. Modern GPS chips support this already. Samsung S5, S6,S7 are supposed to even include support for Beidou.

Have a look at this white paper to get the idea: