50
22

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.3k214353
accept rate: 28%


123next »

-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, 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 ♦
28.1k17246394
accept rate: 24%

edited 06 Oct '10, 16:58

GrahamS's gravatar image

GrahamS
3.3k214353

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) Paul Johnson
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, 16:11) dieterdreist
16

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.5k103264
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, 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, 16:07) dieterdreist

Sharing highway nodes with landuse

permanent link

answered 24 Feb, 12:43

Martin%20Borsje's gravatar image

Martin Borsje
10114
accept rate: 0%

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

(24 Feb, 15:21) scai ♦
-24

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
55124
accept rate: 0%

edited 09 Oct '10, 12:46

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
8

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
2

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) Paul Johnson

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, 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, 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, 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 ♦
27.0k59285624
accept rate: 15%

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, 13:34) verdy_p

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

cartinus
6.9k763104
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, 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, 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, 13:29) verdy_p

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.

permanent link

answered 13 Mar '15, 07:29

NarayanAras's gravatar image

NarayanAras
1915513
accept rate: 0%

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

NarayanAras
1915513
accept rate: 0%

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:

×260
×125
×34
×1

question asked: 06 Oct '10, 15:01

question was seen: 38,780 times

last updated: 16 Mar, 01:37

powered by OSQA