Openstreetmap-carto: Render residential & service ways slightly wider at z19

[IgorEliezer]

I know there were some talks about making ways consider key:width or hypothetically implementing z20, but here I'd like to suggest an intermediate step: rendering residential e service ways slightly wider at z19, or keeping their widths when zooming in from z18 to z19.

Residential ways seem to have a width around 4.5 m at z19 and look quite narrow, almost half width, compared to tertiary roads.

If you map parks and other areas according to their actual boundaries, instead of "gluing" or attaching to the surrounding ways (example), you can see a significant gap between the casing of the way and the polygon as wide as or wider than the half width of the way (see on map, streets here are 6~7 m wide).

Having a gap is not the issue, I think it's desirable. But if the gap were less wide, not only these ways will reflect a bit their actually width (maybe 6.0 m) but also would it make people feel less compelled to glue/attach polygons to the ways.

[jeisenbe]

This varies depending on latitude, due to the mercator projection that is used by this style and most other web maps. A rendered line that appears to be 4.5 m wide at 60 degrees will appear to be 9 m wide at the equator.

So we could probably make highway=residential a bit wider, but if you live at 45 degrees there will still need to be a gap so that features at low latitudes do not look excessively wide.

We could also consider narrowing tertiary roads if the color scheme of roads is changed to make tertiary yellow; this would make a smaller jump in width from tertiary to residential/unclassified, but this was supposed to depend on picking a new administrative boundary color.

[Adamant36]

< also would it make people feel less compelled to glue/attach polygons to the ways.

Its not wrong to attach polygons to ways is it?

[IgorEliezer]

@Adamant36:

Its not wrong to attach polygons to ways is it?

I don't know. I've never read on the wiki specifically about it.

However I personally avoid doing it for I consider it a bad mapping practice since the polygon doesn't represent the actual grounds of an amenity, land use, park etc and makes it harder to add entrances and barriers in a more detailed mapping -- apart from requiring a lot of work to fix it. But since I've found it so many times, often old edits, I though it was somewhat tolerated.

[imagico]

See https://github.com/gravitystorm/openstreetmap-carto/pull/3763#issuecomment-486291095 for more elaborate comments on roads drawing width at high zoom levels.

When you make assumptions of real world road widths keep in mind that highway=residential also applies to narrow roads in dense urban centers like

https://www.openstreetmap.org/#map=19/38.71216/-9.14494
https://www.openstreetmap.org/#map=19/41.00653/28.96849

[IgorEliezer]

See #3763 (comment)

Seeing imagico's comment and that there is already a PR in the works, I think this issue is somewhat unnecessary. I'm fine with closing it.

[jeisenbe]

Here's the table for current road widths at z19, based on the table in https://github.com/gravitystorm/openstreetmap-carto/pull/3763#issuecomment-486291095 - to get the values for z19 from z20, you double the size in meters per pixel. So:

z19 means 0.3m per pixel at the equator which based on current values means:

class | width (pixel) | ground width z19 @ 0° in m
-------|-----------------|--------------------
motorway to tertiary | 27 | 8.1
motorway link to tertiary link | 16 | 4.8
residential | 17 | 5.1
living-street | 17 | 5.1
pedestrian | 17 | 5.1
road | 11 | 3.3
service | 11 | 3.3
minor-service | 5.5 | 1.65
track | 1.5 | 0.45
footway/path/bridleway | 1.6 | 0.5
cycleway | 1.3 | 0.4

5.1 meters is not too wide for most residential streets, but this tag is also used for one-lane residential roads, very common in Indonesia, Malaysia, Brazil and other Equatorial countries. We call them a "gang" here, from Dutch, and they are often only 3 or 4 meters wide.

I've actually considered discussing the use of highway=service + service=alley for such "gang" streets, based on how service=alley is used for narrow streets in old European towns, but I'm not sure that this is correct.

So unless we start rendering narrow residential streets differently, by looking at the width=* or lanes=* tags, the current rendering width is not too narrow at the equator. And not very many narrow residential streets in Indonesia have a width=* or lanes=*tag, unfortunately.

It would be possible to render minor-service wider and service slightly wider, since even driveways and alleys must be more than 1.65 meters width for 4-wheeled motor vehicles to pass.

Footways and paths are almost always wider than 1/2 meter, so it might be possible to increase their width at z19 and slightly at z18, where they are also narrow than 1 meter, however, this might require more significant changes to the current path style.

Track roads are also rendered much thinner than actual size at z18 and z19, and even at z17 they are a little narrow. Changing this would probably require completely reworking the high-zoom track rendering (perhaps showing it as 2 parallel lines from z18, representing the 2 wheel tracks?)

Tertiary roads are still rendered wider than actual size at the equator at z19, based on this table (An 8 meter wide road is usually a higher class around here). It would be nice to adjust them to be slightly narrower, if possible, though this might require switching the colors for clarity.

[jeisenbe]

Per the comments above (https://github.com/gravitystorm/openstreetmap-carto/issues/3818#issuecomment-515687036 and https://github.com/gravitystorm/openstreetmap-carto/issues/3818#issuecomment-509024457 and https://github.com/gravitystorm/openstreetmap-carto/issues/3818#issuecomment-524526689) it does not seem like residential can be rendered wider at z19 due to the risk of the rendering being significantly wider than the actual road at the equator. I also now realize that rendering service and minor_service wider would make it harder to distinguish them from residential/unclassified highways (which are only distinguished by width, not color), so I believe this issue can be closed.

However, the comments about possibly rendering paths and tracks wider at z18 and z19 are still relevant, if someone is interested in opening another issue or a PR about that.