Missing bridges above (which I also up-voted), provided the answer to one of my questions: how to mark two intersecting one-way highways that do not permit turning from one to the other. In the acute angle case, than 135 degree and very difficult at 35mph (55km/hr). In the obtuse angle case, it would result in collisions at that speed or higher.

The answer: put a node at the intersection. I already had placed no turns permitted restrictions on the approaches to the intersection.

Sharing highway nodes with landuse

Not identifying the different segments of a road properly

Often different segments of a given road are given different names. (Typically, the name of the road changes after a major junction or roundabout.)

But often the mapper does not break the road into segments, or provide the correct names to these segments.

This is a common mistake of a mapper who is tracing an uncharted area just using the Bing satellite image, but without much local knowledge.

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.

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.

Some of the varied mistakes I've seen that I remember:

• Stuffing ad copy in places where it isn't appropriate: note=* tag, changeset comments, or notes. I have nothing against marketing/PR/SEO people (in fact I've been one for a while) but there's a time and a place for everything.
• Taking over a road segment or other object to add a business listing. As bad as ad copy may be, this is much worse and much harder to clean up.
• Vandalism of the road layout, such as dragging a bunch of points together that clearly don't belong.
• Putting any old garbage in opening_hours=*.
• Putting incorrectly formatted phone numbers (not international format) in phone=*.
• Abbreviating street names, whether mapping the actual road or in an address.
• Various other address bloopers, like trying to stuff the whole street address in addr:housenumber=*.

Of course, I'm sure I'll see some completely new, weird, and not-so-wonderful mistake right after adding this.

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.

Sometimes users forget to mark that location which is most important for the people during travel like signs of hospitals, fire brigade and shopping complex. Hope you can understand the fact behind mapping.

Deleting nodes whose tag's don't show up in Potlatch 2. I have seen situation where new users will "clean up" nodes whose tags are "Not recognised".

Hopefully this will be going away with the greater prominence of iD.

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.