[water] Use width tag for rendering rivers and possibly streets at higher zoom levels

[openstreetmap-trac]

Reporter: LM_1
[Submitted to the original trac issue database at 9.29pm, Friday, 26th August 2011]

Correct rendering of wider rivers is supported by area features like riverbank, which is important for precision within urbanized area. Long rivers in nature (without riverbanks) are rendered unnaturally thin.
If riverbanks are not there (way part of river lies within area riverbank) and the width tag is present render the river (canal/stream...) in appropriate size (width).

The same can apply for all highway types (even if this is less important because streets' widths are more consistent), but it would possibly save all the problems such as:
http://trac.openstreetmap.org/ticket/3132,
http://trac.openstreetmap.org/ticket/3053,
http://trac.openstreetmap.org/ticket/2862,
http://trac.openstreetmap.org/ticket/1492

This ticket is close to
http://trac.openstreetmap.org/ticket/1721 and
http://trac.openstreetmap.org/ticket/3076

[openstreetmap-trac]

Author: Ldp
[Added to the original trac issue at 1.06pm, Thursday, 15th September 2011]

The width tag is visually hard to implement. What should render at the transition from sections with width tag and those without, or with different values?

All that could conceivably be done now is to make a sudden change in the width of the rendered line, which is aesthetically displeasing.

A major technical hurdle is the fact that the source data can be in different geographical projections, some in projected values, some in latlong values. Line widths are done in pixels. Somehow the geographical value would need to be translated to a pixel value.

In short, I don't see support for width=* tags in the foreseeable future.

[openstreetmap-trac]

Author: LM_1
[Added to the original trac issue at 11.54pm, Sunday, 4th December 2011]

Firstly, I believe that if it gets to be rendered, much more people would contribute the width (is there any feature that is rendered and not commonly mapped?). In the transition time, there could be "aesthetically displeasing" artefacts.

Sudden change is not the only option, it is imaginable, that the transition is rendered as a triangle going smoothly from the given width to zero between two nodes.
Also if the width is changing, the different width could be tagged on two consecutive nodes and it would linearly change from one value to the other.

If you know where to render anything on the map, you must have a way to translate geographical (lat/long) value to pixels. And while transforming meters to pixels could be more complicated it is not impossible. After all, any routing software should be able to that. (There are much harder things done in the rendering)

If it is not a priority, I understand. It just seems to me that it is a feature that is currently missing the most...

[openstreetmap-trac]

Author: math1985
[Added to the original trac issue at 10.53pm, Monday, 26th May 2014]

This is difficult to accomplish. For example, what should we do where the width changes? Explicitly mapping the outline would be the best solution. I will close this as wontfix.