NOTICE: is no longer in use from 1st March 2024. Please use the OpenStreetMap Community Forum


I'm interested in identifying the most common mapping errors you stumble upon from other OSMers (or that you make yourself).

If we could list some of the most common mistakes then we could use that information to drive improvements that may help to prevent the same mistakes being made in the future (e.g. by clarifying the wiki documentation, modifying the editor UI, writing scripts to find the mistakes etc).

This is obviously a very subjective question, but hopefully some people may find the answers useful. Please try to stick to definite actual errors, rather than simple differences of opinion.

This question is marked "community wiki".

asked 06 Oct '10, 15:01

GrahamS's gravatar image

accept rate: 28%

« previous123next »

Wrong Tagging

For example using highway=footway for ways that also allow bicycles. The correct tagging would be either highway=path or highway=footway with bicycle=yes.

The opposite is the use of highway=cycleway for ways sharing both cyclists and pedestrians, hence needing either an additional foot=yes or just highway=path (and optionally foot=designated and bicycle=designated depending on the actual purpose).

These mistakes are quite common. Also see the wiki on access restrictions on different kinds of ways. They may differ from country to country.

For mistakes like unconnected ways, there exist several quality assurance tools such as keep right which report ways that are very close to each other, but unconnected, as well as many other common mistakes.

permanent link

answered 06 Oct '10, 16:24

scai's gravatar image

scai ♦
accept rate: 23%

edited 06 Oct '10, 16:58

GrahamS's gravatar image



About the only place I can think of where highway=footway would be appropriate for something that allows bicycles is the edge case of mapping a sidewalk in one of the rare areas (in North America at least) where operating such a vehicle on the sidewalk is OK.

(23 Feb '11, 22:25) Baloo Uriza

The correct tagging would be either ...

This is frustrating - why are both possible? Is one more correct than the other?

(24 May '11, 21:58) jezmck

Mappers can tag what they like - depending on your point of view it's either the great weakness or the great strength of the project.

For more on highway=path vs highway=footway/cycleway search the mailing lists (if you're suffering from insomnia)

(25 May '11, 01:19) SomeoneElse ♦

bicycle=yes on footways is the representation for an actual traffic sign in some jurisdictions (e.g. Germany) that allows bicycles on footways (legally this is neither the same as allowing pedestrians on cycleways nor is it the same as a shared footway and cycleway).

(28 Feb '17, 16:11) dieterdreist

But... there must be a standard?

First timers often think that there is one right way to do stuff, or that everyone maps everything in the same way, this is not the case. We strive to make things simpler, but there really is no way to make thousands of people map the same way, so there is always going to be more than one way to do it.

permanent link

answered 09 May '11, 12:18

emj's gravatar image

accept rate: 15%

edited 09 May '11, 12:19

Combine two highways because they have the same name, ...

but the two ways actually have different tags or are not both members of the same relation.

permanent link

answered 14 Aug '12, 18:42

cartinus's gravatar image

accept rate: 27%

Users are generally not faulty, they just trust what the common editors allow them to do without warning them.

Merging ways with distinct tags or not members of the same sets of relations should open a conflict resolution editor allowing to see the differences and accept merging tags, or reject it (notably for distinct relations, these relations need to be merged separately if needed, using the same checks on tags and sets of parent relations)

The same remak applies when splitting ways (here also the parent relations need to be all updated in their lists of members), but most often it is simple to repair if a relation is forgotten.

(24 Feb '17, 13:25) verdy_p

In JOSM, the set of parent relations is not automatically loaded for all ways when merging or splitting them: but JOSM still does not automatically download the parent relations. You have to do it just before merging/splitting ways, pressing CTRL+ALT+D.

However the data server frequently returns 5xx errors when looking for parents (this error isn't reported by dialog or notification on the screen: you see it only on the console, provided that JOSM is launched from a command line window to see it, or by enabling the console window in the Java config menu. Unfortunately, if you close that window, there's no way to reopen it. Suggest JOSM to add an panel to show what is sent to the std-output.

If the server returns an error, nothing happens in the editor, users may feel that all parents are loaded, when they are not. The work around (if you see this error), is to zoom in on a tiny area around the node of the way to split or connecting ways to merge, and then download all objects in that area: the OSM server does not fail downloading all parents of these ways, when it fails by querying only the lists of parents and loading them: this is still a bug/performance issue on OSM server!

(24 Feb '17, 13:28) verdy_p

In the ID editor, there's a separate old unsolved issue, which occurs when splitting ways that are members of relations: the newly created way is just added at an inaccurate position at end of the list of members, instead of being inserted immediately before or after (depending on the connection of the other end nodes with other members before or after that way).

This creates havoc in many relations that expect a correct ordering, and complicates a lot the reparations that could be done later when the geometry needs to be repaired (not just for closed rings in multipolygons, but as well for linear objects such as associatedStreets/rivers...).

ID should preserve the continuity of member ways as much as possible, and when splitting ways, it is evident that both parts should NEVER be separated in the list of members.

(24 Feb '17, 13:29) verdy_p

Not being explicit with topology. E.g. intersections / junctions are often not mapped in a way that makes it clear which way is the one discharged into the other (they seem equally important from the mapping, the form of the junction is not mapped). Topology is also a matter when it comes to the limitations of GPS accuracy: some users tend to believe the GPS unit more than their eyes: they map a feature on the other side of a road if the stored coordinates of the waypoint indicate this. Or they draw zigzig-lines where the road is perfectly straight.

permanent link

answered 27 Feb '11, 11:30

dieterdreist's gravatar image

accept rate: 3%

edited 27 Feb '11, 15:10


Getting the topology to match what's on the ground is important to routers too - it makes the difference between "take the second exit from the roundabout" and "take the first exit".

(07 Mar '11, 12:49) SomeoneElse ♦

What's the correct way to tag which way is discharged into the other?

(24 Nov '12, 04:14) nicolas17

you do it geometrically, if it is not clear maybe it really isn't clear in the particular situation.

If you are after names or reference numbers you could see these as well, but in some special cases the name (maybe even the ref) don't follow the "main flow". (e.g. could imagine a road intersection, where continuing leads to a higher road and the current ref turns into "another" road).

(24 Nov '12, 16:30) dieterdreist

In Africa highway mapping, track only goes to farmland.

So ruled in Highway_Tag_Africa.

"The road conditions in African countries do not always correspond to their economic and social role. A road typology should be based on the road importance and not on the surface or the visual appearance of a road."

This means, it may look like a track but, if it goes from a major road to a hamlet, it's an unclassified highway, except a 4x4 can't drive it because it wiggles too much (then it's a path). Ditto from hamlet to hamlet.

People new to Africa mapping always get this wrong.

permanent link

answered 13 Dec '14, 14:51

rwst's gravatar image

accept rate: 0%


That's not so different from other countries. The highway tag should be used to tag the road classification, not the road's look.

(13 Dec '14, 17:13) scai ♦

JOSM Boundaries

In JOSM I once made the mistake of downloading an area then subsequently editing outside that area, without realising it was outside the extents of my downloaded region. So I ended up adding objects that were already there, but I didn't see them as I hadn't downloaded that area. I quickly found "Draw boundaries of download data" under the Preferences>Display>OSM Data and turned it on. No more of such problems. I think that from a usability point of view, it should be enabled by default.

permanent link

answered 07 Oct '10, 09:33

aharvey's gravatar image

accept rate: 21%

edited 07 Oct '10, 09:48

GrahamS's gravatar image



Fortunately, this is enabled by default.

(23 Feb '11, 22:24) Baloo Uriza

Oh, that's right, it is. My mistake. I must have forgotten that early on I disabled it so I could see the pretty slippy map background clearly.

(05 Mar '11, 22:45) aharvey

Thinking that ways that are part of $longdistanceroute are actually called $longdistanceroute

In the UK at least, this usually isn't the case. I suspect that new mappers do it to get the name to appear on the main OSM Mapnik map, or because they haven't yet figured out how relations work.

permanent link

answered 05 Sep '11, 11:07

SomeoneElse's gravatar image

SomeoneElse ♦
accept rate: 16%

Long distance routes (notably motorways or national/interstate/state/regional highways) have a common descriptive name, but the actual identification is their ref number. That ref may be placed on member ways, but individual ways of course keep their local name (notably streets in cities/towns/villages), as defined by the local administrative authority. Even if this is the same administrative authority that manages the whole route, it still has distinctive local names for sections, e.g. for circular highways around towns/cities.

(24 Feb '17, 13:34) verdy_p

Using search-and-replace to do small 'mass edits'

New users tend to use the search-and-replace function of editors to do 'corrections' to a massive amount of nodes or ways in their area when they believe they found an 'error' of some kind.

Not mentioning here if the 'error' really is one or not (new users might have trouble understanding all the tagging schemes used in OSM), the mere application of such changes in an automated manner often destroys more valuable data than it fixes. This is also regularly used to fill in perceived "blanks", even if those blanks are left intentionally or are coverde by some kind of default.

Examples are

  • attaching addr:postcode or addr:city to all buildings in a region (overwriting manually set fringe cases where postal address doesn't match real location)
  • adding oneway=no to all highways which don't have oneway=yes
  • standardizing names of shops/food chains, even if there really are some that carry another name on their sign

This is often combined with the "leave no changeset comment" problem already mentioned.

permanent link

answered 19 Aug '13, 16:02

Chaos99's gravatar image

accept rate: 14%

Confusion between "Common Name" and "Operator" of a POI

For example, take a Citibank ATM.

  1. Is "Citibank" a 'common name' or 'operator'?
  2. Should "ATM" be a part of the Common name?

Another example: A Dominos pizza joint. Legally, "Dominos" is the brand, operated by a local franchisee (a separate business entity). So how to fill these attributes?

As a result, I have seen inconsistent entries in POIs.

Suggested solution: The mapping tools (iD/Potlatch) should have more explicit tooltips.

permanent link

answered 13 Mar '15, 07:03

NarayanAras's gravatar image

accept rate: 0%

For standalone ATMs (not part of some other feature) "amenity=atm". If the operating bank is indicated, then also tag with, eg, "operator=Citibank". I've never seen a standalone ATM with a name (eg "Jimmy's Cashhole"?), but the world is full of wonders.

It's tempting to name them after the operating bank, so the bank name will render on the map. But of course that's a no-no, "tagging for the renderer."

To indicate the presence of ATMs as part of another feature, tag with "atm=yes". If that feature is a bank, that bank would be presumed to be the operator. If that feature is not a bank, very often the ATM is no-name and doesn't need an operator.

But of course there's always an exception. For instance, in New York the Duane Reade pharmacies usually contain ATMs operated by Chase Bank, and it would be great to be able to tag them as such. We might consider something like "atm:operator=Chase" after the "atm=yes", or just skip the "atm=yes" and create a separate "amenity=atm" node with "operator=Chase".

As far as Domino's pizza goes, "name=Domino's" or "name=Domino's Pizza" (whatever the sign says) and leave the operator off unless you observe specific operator data.

(06 Jan '18, 17:56) jmapb

To draw a building shape, the mapper traces its terrace, but does not move it to its base

This "parallax error" is an extremely common mistake in drawing shapes for highrises.

The mapper uses the Bing satellite image, and traces out the top of the building.

But he forgets that the satellite image is not exactly "top-down", about 15 degrees angle to the vertical. Thus the base of the building does not lie exactly under its top. In fact, the taller the building, the more this offset!

On the other hand, all map features having low heights are traced without such parallax errors. For example, roads, boundary walls, low-rise buildings.

As a result, many tall buildings appear to be shifted from their actual positions. Some even touch (or "crash into"!) the adjoining areas.

permanent link

answered 13 Mar '15, 07:20

NarayanAras's gravatar image

accept rate: 0%

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 06 Oct '10, 15:01

question was seen: 70,623 times

last updated: 20 Sep '20, 21:15

NOTICE: is no longer in use from 1st March 2024. Please use the OpenStreetMap Community Forum