Make drain line wider

[zdila]

Make drain line little bit wider because now it is almost invisible. Also ditch could be wider than it is now, but let it is narrower than drain line.

EDIT: Streams are now rendered wider than drains or ditches even that in reality drains can be wide as a river and drain not narrower than regular streams.

Please see http://www.openstreetmap.org/#map=16/48.6993/21.6858&layers=N (and compare it real width with Bing).

[przemas75]

Im not sure if this region will look good with wider line:
http://www.openstreetmap.org/#map=14/54.2881/18.6750&layers=N

[zdila]

@przemas75 still, at least drains should be wider. Ditches can stay as they are.

Streams are now rendered wider than drains or ditches even that in reality drains can be wide as a river and drain not narrower than regular streams.

[zdila]

@przemas75 + for higher zoom the area you referred to would be OK also with wider ditches :-)

[matkoniecz]

drains can be wide as a river

It is not a good reason to render all drains so wide, most are really small. In cases like this mapping water as area would be a good idea. Or providing width data (width tag is in the database - see https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.style ).

So maybe rendering of linear waterways should use width data. Is it doable without a giant switch for every zoom level?

[mboeringa]

So maybe rendering of linear waterways should use width data. Is it doable without a giant switch for every zoom level?

Rather than going the very uncertain road of trying to use width data (what units is the data stored??, who says all data is metric/meters, it could be any value, mm, inches, feet..., it isn't even in any numeric form by default in OSM...), and trying to use this to change line widths, I think a better option would be if CartoCSS implemented a _reference scale_ for some of the line features, and then automatically scaled the width of the features when you zoom in or out.

Most GISs, like QGIS or ArcGIS, have such an option.

This means that if for instance you set the line width to 1 mm and a reference scale of 1:10000, than zooming in to 1:5000 would mean the line was displayed 2 mm thick. Correspondingly, zooming out to 1:50000, would give a line width of only 0,2 mm.

Such a feature would at least prevent lines from becoming apparently infinitely thin on zooming in at very high zoom levels (Z17-19), where one would expect the feature to become thicker / be wider.

Of course, such a feature is not desirable for all things. Roads, that need labeling within them on the main OSM site, shouldn't be scaling depending on reference scale... but I do think that objects like drains could scale.

[HolgerJeromin]

Not using width because it could be wrong is not a good idea. It is defined as meters. Period. Using this would be useful to detect wrong units.

[mboeringa]

Not using width because it could be wrong is not a good idea. It is defined as meters. Period. Using this would be useful to detect wrong units.

It is not just because it could be wrong. I think most line objects that would need width, just don't have it. So apart from probably some substantial implementation difficulties for using width, the value of using width will be limited to only the best tagged areas in the world.

Using a reference scale is generic for the globe, and would answer at least part of the desire to see more intuitive scaling of line object widths.

I also think that using the rendering output for detecting errors, may lead to further uncertainties. To most people, the rendering engines are just one black box / magic... with no guarantees or knowledge of what is going on inside, the question of whether something represents reality in any measurable way, remains unanswered (although comparing with proper high resolution orthophoto imagery may be an option).

[mboeringa]

By the way, reference scale and width don't exclude each other, it is (technically), possible to use both, but it won't be easy nor make maintaining style definition any less complicated than it already is.

And of course, using real world measured width, only really makes sense if set against a reference scale and scaling the objects appropriately at each zoom level...

[pnorman]

We've made the decision to not use width for rendering roads and steps. I think the same logic applies to water features.

Given that the line is so narrow anti-aliasing almost makes it disappear, I think it clearly needs to be wider.

[mboeringa]

We've made the decision to not use width for rendering roads and steps. I think the same logic applies to water features.

A wider line is an option, but won't solve the apparent thinning of the line on very high zoom. How about a "reference scale" and scaling of symbols, as I suggested, is that possible with CartoCSS?? It is a pretty basic function in most GISs, and should answer the desire to see certain lines not go into oblivion on high zoom, instead, become wider.

In my ArcGIS renderer, I currently use reference based scaling on a number of line features (but not all!!). E.g., runways of airports are being scaled, as well as walls and hedges, but not roads/highways. The base reference scale I designed my style for, is 1:10000.

[dieterdreist]

2014-09-22 0:16 GMT+02:00 Paul Norman [email protected]:

We've made the decision to not use width for rendering roads and steps. I
think the same logic applies to water features.

traditionally maps do oversize roads but display waterway widths in scale,
so there is not necessarily the "same logic" behind different kind of
features. This said I also agree that pure width in scale is not desirable,
the should be a limit on the lower end to ensure a minimum width for
readability. For waterways which have their area tagged as well it would be
desirable to not respect width (AFAIK not doable at the moment), so in the
end, also on the upper end, respecting width is not what we want IMHO.