highway=pedestrian should not be opaque when used as a polygon

[tbertels]

When used as a polygon, highway=pedestrian is opaque and thus hides anything else.
This is why a multipolygon relation has to be used to show fountains, buildings and other features inside it.
However, using a multipolygon seems like a workaround to a bug, as evidenced by the fact that highway=pedestrian also hides underground roads.
You can see below an example of this, the fountain has the inner role in the multipolygon highway=pedestrian relation. And it creates the impression of a hole:

http://www.openstreetmap.org/relation/7184233

I think that highway=pedestrian, when used as a (multi)polygon, should be like leisure=park by example:
http://www.openstreetmap.org/way/403672617

So features below it and polygons in it should be visible.

[dieterdreist]

sent from a phone

On 10. May 2017, at 14:20, Thomas Bertels ***@***.***> wrote: When used as a polygon, highway=pedestrian is opaque and thus hides anything else. This is why a multipolygon relation has to be used to show fountains, buildings and other features inside it.

it is correct to cut those things out that aren't highway areas. Use place=square for the whole square including fountains and buildings.

[tbertels]

According to highway=pedestrian and taginfo (113 586
uses vs 3 155), highway=pedestrian + area=yes seems to be the way to tag a plaza.
#2203 was closed to not render place=square because of its low usage.
Indeed, I think highway=pedestrian should be fixed instead, at least when used with area=yes.

[dieterdreist]

sent from a phone

On 10. May 2017, at 19:56, Thomas Bertels ***@***.***> wrote: According to highway=pedestrian and taginfo (113 586 uses vs 3 155), highway=pedestrian + area=yes seems to be the way to tag a plaza.

while I agree that pedestrian + area was the preferred way to map squares for a long time, the paragraph for squares in the wiki is very new and this taginfo query is for all pedestrian areas, not just squares. Adding a building or a fountain as pedestrian area was never correct though.

#2203 was closed to not render place=square because of its low usage.

which is increasing rapidly, and which is a very new tag, so it might be reconsidered in a while

[matthijsmelissen]

This issue is duplicate with #529.

#529 (comment) (second comment) explains why this issue cannot be fixed without breaking rendering in other ways.

[matthijsmelissen]

As you seem to have a clear solution in mind, I'd be curious to know which of the properties in #529 (comment) (second comment) you'd propose to drop.

[eliotb]

It is unexpected that highway=pedestrian, area=yes covers up smaller objects within the area. This doesn't seem to be the case for e.g. areas with landuse category etc. It seems to be overkill to have to convert to multipolygon in order to see all the small items within a pedestrian area.
E.g https://www.openstreetmap.org/way/30365799
Some items (nodes and labels) render on top of the pedestrian area, But other polygons don't.
(Please discount the cathedral in my example. Note monuments, chess game area, toilets etc)

Contrast this with nearby golf course https://www.openstreetmap.org/way/358719405 No need here for crazy relations to have sand inside fairway inside golf course inside park render OK.

So, I'm not asking for pedestrian area to be rendered transparent, but rather "lower" in the stack so other things appear on top of it. This is what I expected would happen.

[dieterdreist]

sent from a phone

On 23. Jul 2017, at 03:31, Eliot Blennerhassett ***@***.***> wrote: Some items (nodes and labels) render on top of the pedestrian area, But other polygons don't. (Please discount the cathedral in my example. Note monuments, chess game area, toilets etc) Contrast this with nearby golf course https://www.openstreetmap.org/way/358719405 No need here for crazy relations to have sand inside fairway inside golf course inside park render OK.

IMHO mapping error, clearly a golf course is an area with other stuff inside, but a highway=pedestrian and area=yes is a surface that pedestrians can walk on, and doesn't include an equestrian statue or a cathedral. If there are buildings or sculptures or flower beds or anything else that is not pedestrian step on, you should exclude it from the area. Use place=square with name where it is a square (and this area will typically comprise everything on it)

[eliotb]

Maybe my golf example wasn't clear enough. The fairway is a simple area (golf=fairway, landuse=grass), the bunker inside the fairway is a simple area (golf=bunker, natural=sand). There is no grass underneath the sand, yet it is not necessary to convert the fairway into a relation with the sand as a hole in it.

[eliotb]

How about this one. http://www.openstreetmap.org/way/83423441 Pedestrians can walk across it, but it is also a "chess pitch". Currently showing because I have done the whole painful relation business.

Another problem. This fence http://www.openstreetmap.org/way/180656505 is not visible where it is crossing the pedestrian area.

To illustrate how naïve users don't map pedestrian area with holey relation:
http://www.openstreetmap.org/way/101372101#map=18/-43.53287/172.63504 added about 2 months ago, obscures almost all existing items within the area. The highway=pedestrian is being applied like a landuse. @dieterdreist I disagree with your interpretation that containment should require holes to be cut in the containing polygon.

[dieterdreist]

sent from a phone

On 23. Jul 2017, at 10:25, Eliot Blennerhassett ***@***.***> wrote: The fairway is a simple area (golf=fairway, landuse=grass), the bunker inside the fairway is a simple area (golf=bunker, natural=sand). There is no grass underneath the sand, yet it is not necessary to convert the fairway into a relation with the sand as a hole in it.

IMHO you are mistaken, you do have to cut a hole, because sand is not landcover=grass (I'm not familiar enough with golf to know whether the bunker is part of the fairway or not, which will determine how you structure the objects and tags). You are right that the incorrect mapping in this case still would result in correct rendering in osm-carto.