My first question is as the title suggests:
Restricting ourselves to well-known renderers used in standard layers, do tag values other than “highway” affect the rendering of road thickness? (If so, which tags?)
My second question is:
Not limited to well-known renderers, but looking at all the software that can render OSM data, are there any that actively use “width” or “lanes” to determine the thickness?
not in OSM Carto (default at osm.org )
OSM Carto takes into account service= value to make for example driveways and parking aisles narrower, as pointed out below.
A/B Street, lanes map style in JOSM come to my mind
trailing through lanes | Keys | OpenStreetMap Taginfo may find something
That style computes a highway class based on the OSM one from various other attributes, including surface and width.
Even OSM Carto uses service to create a sub-class of highway=service, which it shows as narrower.
OSM2World uses width and lanes (plus other keys such as turn:lanes) to determine the width and appearance of the road in the 3D rendering.
Thank you for the multiple pieces of information.
・The well-known “OSM Carto” (used in standard layers, etc.) determines thickness based solely on the highway value (and service value).
・There are several examples that reflect width and other values.
・For three-dimensional displays, there are examples that reflect the lanes value.
・For two-dimensional displays, examples reflecting the lanes value are mostly tools for editors; there are no examples for end users.
Summarizing the information provided, it seems to be like this.
One tool meant for end-users is http://osm2streets.org/ – you can quickly see an interpretation of the lane tagging. Of course there’s lots of guesses for the actual width, and the geometry gets very broken near complex junctions. One use is for QAing the data.
I would be curious whether you thought about using area:highway for the geometry and draw the given lanes into that area?
Yes, I have. For example, my presentation all the way back at FOSSGIS 2018 (in German) explains the approach I experimented with back then.
However, it seems I was a little too optimistic at the time. Implementing that robustly for actual data (with mixed quality and tons of edge cases) isn’t exactly easy. I still think I could get it done if I spent a few weeks working on it, but it’s a large task that hasn’t made it to the top of my to-do list yet.
Area highways are a great choice if they are well-mapped, as they are more realistic than line-based estimates.
However, currently, they are only mapped in very few areas, and even in areas where they are mapped, they are not maintained by other mappers, so they become increasingly out of touch with reality over time.
One of the reasons why few mappers participate in area mapping is because they think it is not worth doing since it is not reflected in the display.
(The other reason is probably because it’s a huge amount of work compared to simply drawing lines.)
Therefore, if there is an increase in software that reflects the display, it is expected that things will move in a positive direction.