Pedestrian ways should render below streets are they can create gaps in the road

[dieterdreist]

Expected behavior

render the road network without gaps in the rendering where there aren't in reality

Actual behavior

pedestrian highways are overlapping other roads thereby creating visual gaps.

Screenshots with links illustrating the problem

see here:
https://www.openstreetmap.org/#map=19/41.89362/12.47281

[imagico]

The observed rendering is due to a non-standard use of highway=service for roads that provide connectivity in the general road network to and from other roads of higher classification - probably chosen by mappers to 'draw' narrow oneway roads in dense urban centers, often just wide enough for a single car, with a more narrow line signature than the standard minor unclassified/residential/pedestrian/living_street roads. But this is not consensus mapping. If a road is narrow, yet has a function in accessing other parts of the road network, it is not widely considered to qualify as highway=service.

We define the drawing order (z_order) of roads through the position in the road hierarchy - which puts highway=unclassified/residential/pedestrian/living_street above highway=service.

The proper way to deal with situations like the one shown is for mappers to tag the roads with highway=unclassified/residential/pedestrian/living_street according to their function and tag width=* to indicate their narrow nature and for us to use ground unit rendering of roads when tagged with width=* at the high zoom levels (see #1290).

[dieterdreist]

How many uses have there to be in order you consider it "standard"? https://taginfo.openstreetmap.org/tags/service=alley#overview
The use of service=alley is consistent in Italy (and likely elsewhere) for alleys. I agree that it differs from some other uses of highway=service, but this fact is documented.

Of course you can choose to ignore it, and keep the ugly errors in the map. Definitely tagging all these as residential roads, loosing the distinction of an alley and a wider residential road, would be far worse.

[imagico]

Non-standard here is short for not consensus mapping and most mappers consider such use of highway=service incorrect.

Keep in mind that that we currently render highway=service in a distinct fashion but not service=alley. If you want to suggest a distinct interpretation of service=alley that would be a different matter. But you would need to provide evidence that this is used in a consistent fashion with a well defined meaning. The wiki currently documents two completely different use cases and also indicates that this is disputed. In light of the quite clear consensus on the semantic limits of highway=service some might consider use for a physical characterization as narrow a trolltag.

My impression of service=alley is that it is used quite variably but widely within the consensus meaning of highway=service. The use in Rome you linked to seems exotic and not representative - neither world wide nor within dense urban centers in Europe.

The consensus tagging for unusually narrow roads is width=* - >500k uses in combination with highway=residential.

Independent of all of that - if we'd reverse the z_order of highway=service and highway=pedestrian to fix the problem you show the result would be that we'd get the exact opposite 'error' where a highway=service branches from a highway=pedestrian - which is a much more widespread case in the map - like here:

https://www.openstreetmap.org/way/137309354
https://www.openstreetmap.org/way/50773576

The only real fix for the issue would be to analyze each junction of roads and locally adjust the drawing order based on which road types connect through the junction and which end there. That, however, would be quite expensive to implement.

[dieterdreist]

sent from a phone

On 18 Mar 2024, at 15:30, Christoph Hormann ***@***.***> wrote: The only real fix for the issue would be to analyze each junction of roads and locally adjust the drawing order based on which road types connect through the junction and which end there. That, however, would be quite expensive to implement.

I agree, it seems the only possibility to do it right in both cases is this. Well, mappers could hack the situation with layer tags, but that’s not really a serious option, at least not according to the current status quo.

[dieterdreist]

another place where it is an issue are these bus tracks https://www.openstreetmap.org/way/107292718#map=19/41.89722/12.47064