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%

« previous123


They forget the source

Additionnaly to other mentioned common error, another one is data without source mentionned. When I see strange data without source, I cannot evaluate the error of the autor (error of the GPS, obsolete imagery, approximate survey, …) and the final solution is to ask to the author. An other consequence is that we cannot evaluate easily the quality of the data, depending of the known lack of precision of a source.

permanent link

answered 24 Feb '11, 12:04

NicolasDumoulin's gravatar image

accept rate: 13%

I don't know exactly what kind of strange data you are referring to, but if there is a way (tagged highway) in OSM which is not there in reality you should correct it regardless of the source. Source is useful for stuff like "population" where you can see how old the data is.

(27 Feb '11, 11:21) dieterdreist

I wish Potlatch2 gave better tools for adding source easily. For example: similarly to how R replicates all tags from the last touched object of the same class (which is awesome), so S or Ctrl-R or some hotkey should replicate just the last entered source.

I know this is not the place for Potlatch wishlist (although now that I typed this up I might just create a Trac ticket :), but I'm just trying to explain why I, for one, am being bad about stating the source. Too much work, too little to show for it (literally).

I suppose we could at least add the source to the changeset, if that helps.

(14 Apr '11, 23:52) ponzu

Ponzu, I found out quite recently, the key "B" shortcut for Potlatch2. Just press it in same manner as "R" replicates, and "B" puts in the current background as the Source - great for when u are tracing from Bing or the like.

(17 Apr '11, 19:58) Russ McD

Please don't use source=* on single objects. Instead, use it on the changeset. On a node with several tags, nobody knows which tag (or maybe its position?) the source tag refers to. If you feel that you use multiple sources for your changeset, either make your changeset smaller, state all sources or further elaborate your changes in the changeset comment.

(19 Aug '13, 15:41) Chaos99

@Chaos99 That works if every item in a changeset has the same source, but not if they don't. As for sourcing individual tags (if it's necessary, which it usually isn't!) Taginfo shows that "source:blah" is well-used and accepted.

Basically - use whatever's needed to communicate with future mappers, whether that's changeset source tags, item source tags or even something more granular.

(19 Aug '13, 15:59) SomeoneElse ♦

@SomeoneElse I've already mentioned splitting the changeset, giving multiple sources and using the changeset comment. source:bla indeed solves the reference issue, but still pollutes the database. We should at least use the method most suited to the specific task. 10000x "source=BING arial imagery" on building outlines doesn't give us any more info than once on the changeset.

(19 Aug '13, 17:05) Chaos99
showing 5 of 6 show 1 more comments

Using non-descriptive changeset comments

It's helpful to know (especially on "big" changesets) exactly what was being changed. Comments such as "Fix Tags" and "Fixed Stuff" don't really help; always try to put something in there (even if it's just referring to where the changes were made).

(and in the interests of full disclosure - I can be as guilty as the next person of this "common mapping mistake")

permanent link

answered 07 Mar '11, 15:05

SomeoneElse's gravatar image

SomeoneElse ♦
accept rate: 16%


Yes, and it is also helpful to try to avoid "big" changesets, and make them small enough that the description is precisely referring to the actual changes made.

(07 Mar '11, 15:20) dieterdreist

sometimes with potlatch2 I start editing and save and give a description of the edit, then go on editing and the program doesn't ask me for a new description... so my second save inherits a description that isn't necessarily correct.

(05 Sep '11, 14:41) mariotomo

You can ask Potlatch 2 to close a changeset by pressing "c". Then the next time that you save, it'll ask you for a new changeset comment.

(05 Sep '11, 14:48) SomeoneElse ♦

In general I'd say this is not so much a "common mapping mistake" but more of a thing we'd like new users to "graduate" onto doing, once they're getting the hang of editing. I don't think it should be regarded as essential, or rude not to. I do always try to add a good comment. Techy people are very fastidious about this kind of thing, but it might take some new users a while to pick up the habit, and that's fine.

@miriotomo yes. I make the same mistake quite a lot when dipping into Potlatch editing. I know about the 'c' button, but tend to save by mistake expecting to be asked (like in JOSM)

(12 Jun '12, 16:20) Harry Wood

Thanks, C is new for me, but pressing it, costs time to save it. I usually feel lucky if the question is nt displayed. Ill improve myself.

(14 Aug '12, 23:17) Hendrikklaas

@SomeoneElse You might want to add "and creating changesets than span continents". It's exactly the same problem, as the following mappers can't see what has happened. It also completely breaks the history page of

(19 Aug '13, 16:06) Chaos99
showing 5 of 6 show 1 more comments

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%


Thinking that everything has to have a "name"

I'm guessing that this is is partially because the Potlatch 2 "simple" interface has field called "name" for most features, and it's tempting to fill it in with something like e.g. "Public Footpath".

Similarly, there are lots of ways with oneway=no set. In some cases this might be necessary, but in many I suspect it's a case of "filling in all the fields".

permanent link

answered 09 Jan '13, 22:28

SomeoneElse's gravatar image

SomeoneElse ♦
accept rate: 16%

From potlatch (users) I often have to fix self intersecting ways. Mostly this is a way going back again or making a small loop on itself before it ends or goes on. Not sure if this is a bug in Potlatch or if the users don't use it correctly.

At 348 km ways with 39.8 k nodes I had to clear ~90 of this errors.

permanent link

answered 24 Nov '12, 15:35

malenki's gravatar image

accept rate: 6%

This is perhaps part of the same problem as the "unjoined ways" problem. If people see the standard map tiles on as the "output" of their mapping rather than the data itself, then they won't think that self-intersecting ways are wrong.

As with unjoined ways, it's an education thing - once people have been told what's correct, they're more likely to do it right!

(09 Jan '13, 22:16) SomeoneElse ♦

Aerial imagery offset

In my area almost all new users don’t know about aerial imagery (Bing) offset. So they start drawing new objects without offset imagery at all. Sometimes even worst, they start moving old objects. Then I have to communicate them and revert or fix their edits. And True_Offset will not really helpful, because it change to frequently in hill area. From my point of view we have to keep remind new users of any editors necessity to adjust imagery. Maybe we can keep mark in database for users who confirm that he knows about offset.

permanent link

answered 07 May '11, 23:20

Dmitry%20Terentiev's gravatar image

Dmitry Teren...
accept rate: 0%

edited 07 May '11, 23:22

Bing offsets are frequent in its satellite imagery (correct medium resolution but imagery is not rectified) : Africa, Russia, Canada, Latin America, most of Asia.

But in US and most of Europe, where high-resolution orthophotography is available, this is no longer a problem as most areas are covered (but there remains a few spots in Europe only covered by satellite, e.g. Corsica, Sardinia and Sicilia, most of Switzerland and Austria, a North-West sector in Germany near the Netherlands, and about one half of UK).

(27 Nov '12, 10:25) Verdy_p

I'd disagree that "this is no longer a problem" in Europe where aerial photography is available. Maybe 100m offsets are a thing of the past there, but imagery still needs aligning.

(27 Nov '12, 10:40) SomeoneElse ♦

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

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


Highway Classification

A common error from newbies is the highway classification.
For instance, a highway=secondary is downgraded to a residential road (highway=residential) just because it's crossing a village and/or is temporarily narrower. The highway classification primary/secondary/tertiary/unclassified/residential is indicating the importance of a road within the transportation network. This may or may not affect the physical attributes (in fact, they are: a primary road is usually wider than a residential road). But physical attributes have to be documented with other tags (like width, surface, lanes, etc).
Another mistake is to use highway=unclassified when the highway class is unknown (e.g. traced from aerial imagery) where the correct tag is highway=road.
But it's also true that for some roads, setting the right highway class is not easy, especially in countries where the OSM highway classes don't have a 1:1 equivalence with the local administrative classifications.

permanent link

answered 06 Oct '10, 17:31

Pieren's gravatar image

accept rate: 15%

edited 07 Oct '10, 09:47

GrahamS's gravatar image



I know this subject has been pounded into the dirt, however, the primary/secondary/tertiary and footway/cycleway/pedestrian/path distinctions seem to cause the most troubles.

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

In Portugal and Cyprus I have entered roads with highway=road because it is impossible to rate them on a survey. However all these have been edited to highway=unclassified.

In Cyprus, even some dense residential areas do not have street names but block names (eg Sea View Gardens on one side of the road and Sunset Villas on the other) and I still have not figured out how to name the highway=residentials.

I have sometimes used landuse=residential name=Sunset Villas but what about the addresses when one side of road belongs to Sunset Villas and the other to Sea View Gardens?

(24 Feb '11, 06:47) dcp

This is not a forum. You should convert your comment to a new question ;-)

(24 Feb '11, 08:44) Pieren

You can see this quite often in Italy: highest highway class in urban centres (sometimes quite big ones with place=city) is tertiary or unclassified. All primaries stop before the city and restart after it. Up to some time ago even Milan had only tertiary streets inside the city, but fortunately this is slightly improving now.

(27 Feb '11, 11:06) dieterdreist

That's a good one! I only recently started converting some of the streets that I (and others) had tagged as tertiary to unclassified. I had completely misread originally what unclassified meant. And I do live in one of those countries, for which this classification means little. I don't know if this is cheating, but when in doubt I peek at Google Maps. They only have two colors: white and yellow. I have decided that Google's yellow covers our primary, secondary and tertiary. If a road is not yellow in Google, I tend not to tag it higher than unclassified. Or is that another mistake? ;)

(15 Apr '11, 00:01) ponzu

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

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,617 times

last updated: 20 Sep '20, 21:15

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