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

64
28

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

GrahamS
3.6k214554
accept rate: 28%


123next »

25

Missing Bridges

Quite often in OSM, we find two roads (or road/railway or road/waterway) crossing in OSM without any information about the intersection. Thus we don't know if it is really an intersection (simply put a node) or if it is crossing at different levels (don't put a node but split the way to extract a small segment and tag it with 'bridge=yes' and 'layer=1') (or 'tunnel=yes' if it is a tunnel).
Even if you don't know exactly where the bridge/tunnel is starting/finishing, it's better to have approximate length than leaving a question mark on the map (because it's reported by almost all quality assurance tools and cannot be fixed without a second survey). And please, don't put a node if both ways are at different layers even if you tag them correctly, otherwise some routing application might think that the link exists (e.g. steps) and might create routes through some connections that do not exist in reality.

permanent link

answered 08 Oct '10, 15:12

Pieren's gravatar image

Pieren
9.8k2083157
accept rate: 15%

edited 08 Oct '10, 15:40

6

because it's reported by almost all quality assurance tools and cannot be fixed without a second survey

I've more then once found where people who look at the quality assurance tools think they can fix this without a second survey. They draw a bridge where there is no bridge in the real world. This is really irritating, because it replaces a very visible error with an error that is hard to find.

(24 Nov '12, 16:29) cartinus
3

For truck routing it would be also extremely useful if you could as well specify, if there are any height restrictions underneath bridges!

Please check the OSM Wiki for Maxheight tag. There's also a QA tool around to help you find potential missing maxheight tags in your area (-> search wiki for "Maxheight Map").

(03 Jul '14, 20:41) mmd

Note that segments are gone in the latest version of the API.

(06 Jun '18, 03:46) Arlo James B...
1

@Arlo James Barnes : I think this is a misunderstanding, Pierzen used segment in its ordinary not special OSM sense as a type of element.. Like me (and this help forum) he started editing OSM long after segments as OSM elements disappeared.

(06 Jun '18, 11:03) SK53 ♦
24

Copying from non-free sources like Google Maps

This is a huge no-no. Because OpenStreetMap is an open-source project, it can only use data that are published as open-source. This means that OpenStreetMap can use:

Your own data

  • from GPS traces
  • from seeing places in real life
  • etc.

Data from freely available sources

  • certain local governments (always check)
  • other open-source projects
  • tracing freely available satellite imagery (Bing Maps is ok, Google Maps is not)
  • etc.

These data have licenses on their copyright that let anyone use and distribute it freely (sometimes with restrictions, for example, that any project that uses the data must also be open-source). Other data may have stricter licenses on their copyright that disallow anyone from using it, or force you to pay. Some may have licenses that allow free use, but not free redistribution, which is unusable for open-source projects like OpenStreetMap because we are redistributing the data. Freely available or open-source means that the data must be freely redistributable.

permanent link

answered 11 Aug '13, 22:40

Clorox's gravatar image

Clorox
379347
accept rate: 0%

edited 11 Aug '13, 22:44

I often find myself going to Google Earth to get better angles on hidden objects, looking at it for reference because of the higher quality at max zoom, or using Streetview. Is that considered "copying"? Its practically required considering how much I do detailed edits, that my edits are more detailed than even traditional micro-mapping.

(06 Jan '18, 22:42) Mxdanger
1

@Mxdanger yes, unfortunately we can't use Google Earth even for "reference".

(06 Jan '18, 22:44) SomeoneElse ♦

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

NarayanAras
3115818
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
-1

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.

permanent link

answered 16 Mar '17, 01:37

OverThere's gravatar image

OverThere
251
accept rate: 0%

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 ♦
33.3k21309459
accept rate: 23%

edited 06 Oct '10, 16:58

GrahamS's gravatar image

GrahamS
3.6k214554

2

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
2

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
17

Not adapting the quantity of nodes for highways to the situation. Often mappers use always the same (regular) distance between 2 nodes of a way, more or less regardless if it is straight or curved. Instead you should put more nodes in straight curves and only 1 node on each end of a non-curved part of a way (unless there are junctions or changing attributes like maxspeed in between).

permanent link

answered 27 Feb '11, 11:34

dieterdreist's gravatar image

dieterdreist
3.7k113567
accept rate: 3%

All those unneeded nodes make the database a lot bigger without even adding a single bit of detail (sometimes, making it even harder to align the road better, or introducing curves where there are none).

So I agree with this one, straight ends don't need nodes, and those nodes should be deleted when editing a way.

(14 Aug '12, 17:41) Sanderd17
2

Note however that straight highway are not really straight above some distance (almost never for streets in cities at distances higher than 50 meters: you need additional nodes for changes of lanes, parking lots, turning lanes, and trafic calming reduction of widths; even for motorways in rural areas, the line is not straight above about 200 meters. Placing nodes correctly at reasonnable distance improves the precision and avoids making deviation angles visible when there's effectively a very clight curve. As a rule place the nodes as exactly as possible in the middle of the road on the visible painted signals between the two directions, and avoid this line to cross more than a single lane or getting out of the road (through side drains or though kerbs separating side walkways or through security barriers.)

(28 Feb '17, 15:49) verdy_p

yes, you will need more nodes for detailed mapped features even if they consist of straight lines, because of changing properties and intersecting ways. As a rule of thumb, when mapping highways in "significantly incomplete" areas, you can put a node on each intersection, even if you don't add the crossing highways at that time.

(28 Feb '17, 16:07) dieterdreist

Sharing highway nodes with landuse

permanent link

answered 24 Feb '17, 12:43

Martin%20Borsje's gravatar image

Martin Borsje
40236
accept rate: 0%

That's not a "mistake" since there is no consensus. Although many mapper discourage from joining ways with landuses.

(24 Feb '17, 15:21) scai ♦
-26

Roadways and Railways should not use a connecting node where they cross. If it is a grade level crossing, you should tag a point on the roadway, but that point shouldn't be shared with the rail line. The grade level crossing is a feature of the road, not the rail. Another way to look at this is to tag the thing that changes -- the rail line is two continuous ribbons of steel, the road is broken as it crossed lines.

This also goes for power lines, pipe lines and administrative ways. If you want to have 'fun', look at the duplicate node map.

permanent link

answered 09 Oct '10, 12:42

gadget's gravatar image

gadget
53124
accept rate: 0%

edited 09 Oct '10, 12:46

1

Hmm, you are mixing things. You can plot the level crossing before and after the real intersectin between the road and the railway if you like (although most of the contributors tag this once on the intersection itself). But you still have to put a common node between the two lines if they physically at the same level.

(09 Oct '10, 13:30) Pieren
10

Existing established practice in OpenStreetMap is to tag a node shared between the road and the rail ways. See http://wiki.openstreetmap.org/wiki/Tag:railway=level_crossing or use TagInfo (http://taginfo.openstreetmap.de/) to see what other mappers are already doing.

(09 Oct '10, 13:38) Jonathan Ben...
1

I agree that this answer in incorrect. Perhaps the confusion stems from looking at the U.S. data. There the situation is that the TIGER import brought in lots of road and rails which (probably) cross over/under eachother as bridge somehow, likewise lots of power cables which cross over the roads. Now the import brought in the geometries and annoyingly arranged it in OSM with two nodes sat on top of eachother. So not actually incorrectly connecting the two things, but creating a "duplicate node" (minor mistake). And then some people have been incorrectly "fixing" that by merging (major mistake)

(23 Feb '11, 13:23) Harry Wood
4

Actually, crossing nodes should be shared with the roadway, and it's a feature of both the road and the rail. Plus, there are some modes that can successfully navigate a turn from a highway to a railway. Track trucks come immediately to mind. And there's the hiker-lost-in-the-woods scenario where routing along a railway (legality issues aside) to the nearest highway or town would be quite beneficial.

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

I vote down for this very bad suggestion. We need to identify eactly those intersections (if they intersect), or need to use distinct layers on ways (there's a missing bridge/tunnel section on the highway or railway).

So yes, create those nodes for level crossings (which are dangerous, and must be signaled as such).

This is the same case when there's a footway crossing a highway: we add crossing nodes as well, or when a highway crosses a river: we need a bridge or tunnel (different layers) or a ford node (actual crossing on the same layer)

(24 Feb '17, 13:51) verdy_p
-1

By looking at the maps, very often for example residental areas are limited to go along the roads, even when area continues on the other side of road. Because areas have border lines, this adds unnecessary clutter to maps. Maps are easier to read when there is as little as possible unnecessary information.

So I suggest to combine multiple areas to one when they are side by side.

permanent link

answered 12 Aug '11, 21:54

PetriT's gravatar image

PetriT
0
accept rate: 0%

This is a difficult one. Yes, you can combine areas if they are side by side and tagged identical. But having a road in between them means they are not side by side anymore. You may still combine landuse=residential, as the road is part of the residential area. You may not combine a lancover=grass, as a road clearly is not covered by grass.

(19 Aug '13, 15:47) Chaos99

One difficulty is when one side of the road is residential and the other side is commercial or industrial. There's no general rule bout if the road itself is residential or commercial/industrial, when it is both, so that road will be used directly to separate both.

Note also that parking amenities NEED to be connected to roads. When a parking is only connected on the side of the road (without necessarily hacing an internal service highway for a parking aisle), it is common to extend the parking up to the line of the highway.

(24 Feb '17, 13:48) verdy_p

Node sharing will then happen (it clutters less the map with too many nodes nearby when in fact any change on the topology of the road will also impact the topology of the parking. However, if there's a physical border separation between both (kerb, plantation) it's best to keep them separated using parallel lines, and joining only where the pavement connects the parking.

A remaining problem in ID is that you annot easily select alternate ways passing through the same nodes (there's still no CTRL+Click or Alt-Click to cycle the last selection, and still no way to select all objects using that segment or node, and no selection list where you can deselect the undesired objects, and still allow viewing what is in each object in the selection.

Such demixing is much easier to do in JOSM.

(24 Feb '17, 13:49) verdy_p

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 ♦
36.9k71370866
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
Your answer
toggle preview

Follow this question

By Email:

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

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "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:

×352
×193
×45
×1

question asked: 06 Oct '10, 15:01

question was seen: 69,265 times

last updated: 20 Sep '20, 21:15

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