Todays’ case is a problem reported by OSM Inspector. As I know the location, I decided to investigate.

Inner touching outer

At first sight, the situation appears to be straightforward. A plaza in front of a train station has been mapped as multipolygon with highway=pedestrian. A patch of grass and a building, both tagged as inner areas, touch the multipolygon outer border along a line, which is not permitted.

The solution is usually simple, just remove the inner areas from the multipolygon relation and redraw the outer border so that it excludes the inner areas. In this example, this works fine for the patch of grass to the left. Looking more closely at the building, however, reveals another problem.

Walking on the roof

The “building” has in fact been tagged as building=roof , layer=1, and correctly so, as the image below shows. The roof, however, is at a different level than the pedestrian area which extends under it. In other words, the building should not have been part of the multipolygon in the first place (there’s no point in excluding the roof from the area below), and no redrawing is required.

And the name goes where?

It is customary to tag the name of the plaza on the pedestrian polygon. Once we start excluding areas from that polygon (e.g. a kiosk, fountain or greenery), things get tricky. The name of the plaza describes the whole area, while the pedestrian area is only the part we can walk on. In the above example, the plaza - being identical with the pedestrian area - does not include the grass.

A number of solutions come to mind:

1. Tag the name of the plaza and associated information separately with a node and place=square
2. Move the plaza name from the multipolygon relation to the outer border way of the multipolygon
3. Draw a separate (multi)polygon and tag it with place=square and the name

(1) Works, but we lose the spatial information about the plaza.

(2) The trick here is to exploit the fact that the outer border is evaluated separately from, and in addition to the multipolygon relation. This approacch works only if the outer border of the multipolygon completely encloses the plaza (not in the example) and consists of a single way only.

(3) Works, but requires additional drawing/elements.

Happy mapping, and remember, quality matters!

I’ve participated in OpenStreetMap since 2009, and apart from mapping my neighbourhood in Austria, I’m active fixing mapping problems. In particular, I’m interested in areas, from the pure geometry point of view as well as how they are used to describe the real world. My objective is simple: to make the map a bit better.

So, I’ll post some of my observations here, in the hope that you may benefit. I’ll do my best to abstain from discussions about style, and I realize that modifying what others have mapped is frowned upon by some. Well, you may be the judge.

The riverbank and the bridge

I’ll start with a situation I encountered this morning:

The river area has been mapped with polygons (waterway = riverbank or natural=water, water=river), but look what happens at the bridge… Since the bridge is spanning the river (as opposed to blocking it, like a dam or hydro power station would), the riverbank exists also under the bridge, and the two polygons should touch.

This, by the way, also applies in similar situations, e.g. a bridge crossing a railway corridor (landuse=railway) .

The riverbank and the forest

Another - not so obvious, but much more common - problem can be seen on the left. The river is flanked by trees (landuse=forest). When the river area was drawn, there were essentially three possibilities:

1. Draw the river polygon on top of the forest
2. Combine the river and forest polygons in a multipolygon (as done in the example)
3. Split the forest (to the left and right of the river)

(1) is easiest, but incorrect (Mapnik will now render tree symbols on the water area). The forest polygon should just surround the area (mostly) covered by trees, and the river - when mapped as an area - is not.

(2) In the example, the forest multipolygon contains the river as an inner area. For this to work, the forest must enclose the river, which either creates an invalid multipolygon (inner touches/intersects outer) or lets trees grow across the river.

(3) is usually the way to go. It may be more work (draw one forest polygon on either side) or more complex (use multipolygons to reuse the border lines between river and forest), but again, it’s closest to the real world. Note: when the waterway is mapped as a line feature, there is of course no need to split the forest, drawing on top is fine.

Happy mapping and remember, quality matters!