It is generally admitted that a map is not an imagery, so that all widths are not proportional. But this is highly related to the current zoom level: - if we know the effective width of a path, and this width is already larger than the minimum display width to render it on the map, this width would override the default disaply width, so that it could be traced more exactly. - if there's no width specified, use a width assigned by default by the renderer for the type of path. - if the renderer minimum display width is larger than the specified width (or the default width for the type of path), then ignore the specified width or default width, just use the minimum display width to render the path (this will hide tiny details along the path, but it will create a usable map, where paths are consistantly visible all along). This logic can be applied to roads, railways, rivers, and even to boundary limits (that don't have a specified width, but only a default width according to the boundary type, or may be according to the boundary effective surface (in square meters). But for relaly large ways, whose width is not consistant along their way (notably rivers whose width are growing in a nearly monotonic way), specifying only widths would create inconsistant results. Gernally roads and railways have a very standard metric (which only varies when parallel lanes are added/removed along the way), but this is not the case of rivers that have much more variations (this would mean splitting the river into many more sections, each one with its own local width, plus a linear interpolation between points for this width). For this reason it just seems simpler, for large enough rivers, to draw rivers not just with a single central path, but with its limiting banks, that are easier to geolocalize exactly on the map. In this case, choosing a representation of rivers by their boundaries (banks) is more consistant than using widths, at least for large rivers. A mapper can then autodetect these cases, and compute the widths itself, to determine if details of banks are accurate to represent the river, substituting the bounding banks by an auto-computed "skeleton" path that will be rendered by a minimum display width (larger than the effective width represented by the banks. For now, such approach is not supported by renderers, so rivers have to be drawn twice, when their banks are detailed: you draw the bounding banks, as well as a virtual central path, which should be tagged correctly with a consistant width (or whose default width will be derived from the type of path). Which one of these two specifications of the same object should be chosen by the renderer, but I think that their task will be easier if both representations are grouped in a relation representing the whole river as a single object. Note: nothing forbids using the same approach for streets, especially narrow streets in old cities, but these streets (generally not open to automotive traffic, but I won't bet it's always the case, there are certainly lots of exceptions, and such condition is then not determinant) could be assigned distinct types, without requiring to specify their effective widths (when they are consistantly narrower than the default widths of other streets of the same type). This is in fact the same kind of distinction between normal gauge railways, and narrow gauge railways.

It is generally admitted that a map is not an imagery, so that all widths are not proportional. But this is highly related to the current zoom level: - if we know the effective width of a path, and this width is already larger than the minimum display width to render it on the map, this width would override the default disaply width, so that it could be traced more exactly. - if there's no width specified, use a width assigned by default by the renderer for the type of path. - if the renderer minimum display width is larger than the specified width (or the default width for the type of path), then ignore the specified width or default width, just use the minimum display width to render the path (this will hide tiny details along the path, but it will create a usable map, where paths are consistantly visible all along). This logic can be applied to roads, railways, rivers, and even to boundary limits (that don't have a specified width, but only a default width according to the boundary type, or may be according to the boundary effective surface (in square meters). But for relaly large ways, whose width is not consistant along their way (notably rivers whose width are growing in a nearly monotonic way), specifying only widths would create inconsistant results. Gernally roads and railways have a very standard metric (which only varies when parallel lanes are added/removed along the way), but this is not the case of rivers that have much more variations (this would mean splitting the river into many more sections, each one with its own local width, plus a linear interpolation between points for this width). For this reason it just seems simpler, for large enough rivers, to draw rivers not just with a single central path, but with its limiting banks, that are easier to geolocalize exactly on the map. In this case, choosing a representation of rivers by their boundaries (banks) is more consistant than using widths, at least for large rivers. A mapper can then autodetect these cases, and compute the widths itself, to determine if details of banks are accurate to represent the river, substituting the bounding banks by an auto-computed "skeleton" path that will be rendered by a minimum display width (larger than the effective width represented by the banks. For now, such approach is not supported by renderers, so rivers have to be drawn twice, when their banks are detailed: you draw the bounding banks, as well as a virtual central path, which should be tagged correctly with a consistant width (or whose default width will be derived from the type of path). Which one of these two specifications of the same object should be chosen by the renderer, but I think that their task will be easier if both representations are grouped in a relation representing the whole river as a single object.