Building hidden by an area - Mapnik bug?

Emilien · 2010-05-18T12:05:40.000Z

I have mapped the Hassan II mosque in Casablanca - Morocco (“building: yes”). The building and the mosque icon displayed just fine, so I later added an area for the public place around it (“area: yes” and “highway: pedestrian”). The icon for the mosque is displayed, but the building is now hidden.

This behavior is happening in Mapnik but not in Osmarender.

In order to have it displayed, I tried addind a “layer: 1” to the building, but this has no influence. And anyway, tagging should not be done for rendering, so this would not be a solution.

Question: Is this a Mapnik bug (since Osmarender renders fine), or is there a trick that I don’t know to send the area “behind” the building? Or maybe we just need to wait for a redrawing (the area was added 13 days ago…)

++
Emilien.

E-Malte · 2010-05-18T12:09:09.000Z

It’s depending on the rendering order.
To solve this issue you can add a multipolygon to the place, with role=inner on the mosque.

I fixed this. As I didn’t move a node, it probably won’t be rendered new. And I’m not sure, whether the relations are imported directly. So it could be the mosque is visible in a few days…

Emilien · 2010-05-18T12:13:49.000Z

I suppose it’s due to the rendering order because I created the area after the building, however I don’t have any idea how I could change that myself. Not familiar at all with the whole multipolygon thing (tried to draw one once, but just finished drawing various buildings instead…)

Thanks for fixing it.

E-Malte · 2010-05-18T12:16:39.000Z

Well, the drawing order does not affect this. Mapnik simply draws highway-tagged ways at last (well, symbols are rendered afterwards). This leads to the building drawn before, and then the highway is drawn. As it is fully over the building you didn’t see it anymore.
When you export it as an SVG you can see this (when deleting the highway then…).

Emilien · 2010-05-18T12:19:08.000Z

So the multipolygon wouldn’t help? Should I then remove the “highway: pedestrian” tag of the area? What would then be the “correct” tag for a public place where only pedestrians can walk?

E-Malte · 2010-05-18T12:36:21.000Z

It will help. You probably have to wait a bit longer.
I had the same problem here with a church:
http://www.openstreetmap.org/?lat=51.228068&lon=6.771374&zoom=18&layers=B000FTFT

Pieren · 2010-05-18T14:32:40.000Z

Emilien:

What would then be the “correct” tag for a public place where only pedestrians can walk?

Your tagging is correct. It’s a rendering issue:
http://trac.openstreetmap.org/ticket/1971
http://trac.openstreetmap.org/ticket/1873

multipolygon is a workaround.

Btw, you can force Mapnik re-rendering with :
/dirty
added at the end of the URL of the tile.

Emilien · 2010-05-21T15:22:37.000Z

The building is displayed correctly now, so multipolygon is a valid temporary workaround. I also commented on the issue.

Thanks for the trick about re-rendering Mapnik tiles! Didn’t know about it, and I’m sure it will help me in the future.

Ldp · 2010-05-21T20:55:01.000Z

It’s not even a temporary workaround. It is a long term solution. There is no pedestrian area at that spot. There’s a building there.

And while it may seem simple to fix in mapnik, for some technical reasons it really is not. You do want buildings to overlap areas, but not regular roads. But you also want areas to render before regular roads. Still seems simple? Well, add in the need to draw consistent and connecting road casings, and it becomes really hard to fix.

NE2 · 2010-05-21T20:58:03.000Z

You do want buildings to render above regular roads. Then you want tunnels to be drawn above everything, so you can see where the road passes through the building.

Ldp · 2010-05-21T21:48:25.000Z

NE2:

You do want buildings to render above regular roads.

No, you don’t. Think about it.

NE2:

Then you want tunnels to be drawn above everything, so you can see where the road passes through the building.

That’s another issue entirely. I also argue that a tunneled road does not pass through a building, but under it. Notably different from a road through a building (part of the building could be layer=1), or under a covering (cover=yes, as in gas stations or car ports, for instance).

NE2 · 2010-05-21T22:05:43.000Z

Now we’re getting into the difference between bridges, tunnels, and coverings (for example, which one is Lower Wacker?). Maybe the best way is to render covered roadways the same as tunnels.

Pieren · 2010-05-25T08:35:22.000Z

Ldp:

It’s not even a temporary workaround. It is a long term solution. There is no pedestrian area at that spot. There’s a building there.

Ldp, you are supposed to be an ‘experimented’ contributor. So why are you telling that ? Why do you make a difference between a pedestrian area with a leisure=park or a landuse=forest ? because the key is ‘highway’ and not leisure or landuse ? Or you mean that finally all buildings should be excluded from all surounding areas because for sure, there is no park or forest or grassland under the building. Don’t make the life of mappers unnecessarily harder because it requires some work in the rendering config. A tag is not only a key but a key/value pair. There is not reason other than technical to not handler highway=pedestrian + area=yes differently than leisure=park or landuse=residential. Unless it is not specified by layer, a building has to be always rendered on the top.

Ldp · 2010-05-25T18:00:25.000Z

Pieren, you are partly right. Why do I say that highway areas should not be handled the same as landuse areas? Well, it’s because you can route through highway=pedestrian areas. Highway areas play a part (or at least should; which routing software currently uses them?) in routing, and landuse areas do not. Having a hole punched in your pedestrian area for a building, might just tell your routing software that you cannot go there. There is no such concern for landuse areas.

However, the part you are right about, is that it makes the life of mappers unnecessarily harder.

I still disagree with the part (first by NE2, now by you) that buildings always have to be rendered on top. They should not be rendered over regular linear roads. Roads as they are on the map are a symbolic representation of the actual road. They should not be cut into because a building that is near the road overpaints part of the road. Roads on the map are necessarily almost always represented wider than the actual width, and the situation I describe happens almost anywhere there are buildings in OSM. Only at the highest zooms do we show roads thinner than actual width.

Emilien · 2010-05-27T15:32:34.000Z

It’s true that you can route through highway=pedestrian areas. However, if there is a building in this area (as is the case here, and a pretty big too as it’s the world’s third largest mosque…) you can not route through it. So that would exactly be an argument to draw the building on top of the area, no?

You also say that buildings should not be rendered over regular linear roads, because of a building that is near the road overpaints part of the road. So what about buildings that completely cover parts of a road? Let me give you 2 examples, located just next to my office building, so I can assure you that the building is covering the road in it’s entirety. There is the parking on the ground level, and the building covering that parking with it’s first floor. I can send you a picture if needed.
The cover tag would not work, as it’s not a cover but an actual building that is on top of the road.

[openstreetmap.org/?lat=51.676823&lon=5.334613&zoom=18&layers=B000FTF Second building in the lower right]
[openstreetmap.org/?lat=51.678081&lon=5.329665&zoom=18&layers=B000FTF Below the Provinciehuis]

Once again, the representation of those 2 areas made by Osmarender is more correct, as the road is not appearing to be on top of the building.

So if you let me voice my concern, this definitely seems like a bug in Mapnik as we need to add a multipolygon for the rendering to be done as expected. This contradicts the idea of not tagging for renderers (or renderer in this case, as Osmarender has got it right)