Render waterway=canal thinner

[ghost]

Please render waterway=canal thinner. The current rendering looks very strange for small irrigation canals and seems to lead people to wrongly tag them as waterway=ditch, waterway=drain (which are both used for carrying superfluous water) or waterway=stream.

Example of a 1 m wide canal (location) which is rendered ca 5 m wide at zoom 18:

See: key:waterway on the wiki the this email from the tagging mailing list (full discussion).

[kocio-pl]

Maybe there's a way to show how big (wide) are they without measuring them? I would probably render these with boat/motorboat/ship=yes and name as currently, but by default show them the same as ditch, drain or stream:

https://taginfo.openstreetmap.org/tags/waterway=canal#combinations

Upsides:

• this would probably not change rendering of big, named canals (unless the name is in relation probably)
• this would encourage people to add more data when possible
• it's quite simple

Maybe we could also decide using width=* tag.

What do you think about it?

[eehpcm]

Maybe we could also decide using width=* tag.

That's one way. The other is to map an area with natural=water + water=canal in addition to the linear canal feature, as detailed here. I've tried both, neither currently have any effect.

The effect is particularly weird at lower zooms. I have a mill pond with mill race tagged as a canal using water=canal as an area. At z=19 it looks OK. Zoom out a little and the mill race balloons up until it's almost as big as the mill pond. It did the same thing before I tried water=canal, when I used width=0.5 and width=1 (the latter just in case it was rejecting non-integer values).

It would be nice if the carto handled both ways of dealing with a narrow canal, but if you're only going to implement one then please update the wiki to reflect that fact (update the wiki even before you actually implement it to reduce the number of canals added before implementation that later have to be re-tagged).

[polarbearing]

Ways can be exaggerated on a map. Highways are, and probably most canals being built as waterways for ships should continue to be shown appropriately.

I did not have the time to follow the related tagging discussion, but that should be addressed on the tagging side.

[javiersanp]

But different highways are exaggerated differently on the map. You don't consider to render highway=track with the same width as highway=primary, isn't it? What we are talking is about to refine the waterways rendering according to it's width. Some ways has been suggested: key width, boat=yes/no or maybe we need to create a new waterway value for small channels, but this is an improvement that you mustn't reject so quickly.

[ghost]

@polarbearing:

Ways can be exaggerated on a map. Highways are, and probably most canals being built as waterways for ships should continue to be shown appropriately.

In water-rich regions it is probably true that most canals are used for shipping, but I doubt that this is also the case worldwide.

I did not have the time to follow the related tagging discussion, but that should be addressed on the tagging side.

What can we do, in your opinion, other than tagging the width?

[polarbearing]

Probably use either a different value than canal, or use a second level tag to allow distinguishing by purpose. For example, highway=service has serveral subtags that classify it as minor, such as service=driveway, =parking_aisle or =alley. E.g. canal=irrigation. What was the summary from the tagging list?

[dieterdreist]

sent from a phone

On 21. Aug 2018, at 11:44, polarbearing notifications@github.com wrote:

What was the summary from the tagging list?

it is evident the tags for classifying waterways are scarce and the main classes leave definition gaps for artificial waterways which aren’t used for drainage or transportation.

[eehpcm]

it is evident the tags for classifying waterways are scarce and the main classes leave definition gaps for artificial waterways which aren’t used for drainage or transportation.

A second-level tag would work, analogous to having service roads be driveways, parking aisles, etc. but I think that way is sub-optimal for reasons explained later.

What we already have for rivers and (according to the waterway=canal wiki page canals are two methods: specify a width or map the actual channel using an area tagged as natural=water + water=canal. The second of those is superior for rivers because you just map an area from the aerial imagery rather than trying to estimate a width at many points along a channel (I've used it to flesh out the downstream portion of a wide river and it's easy and works well). The first method is superior for canals as they usually have a (fairly) constant width. I tried the second method for a mill race because the first method didn't work, but neither does the second.

I'm speculating that what is going wrong here is that the renderer has decided that rivers and canals, like roads, should be exaggerated at low zooms so they're still visible. It may even be the case that the renderer honours the use of width=* or water=canal but thinks that canals should be exaggerated like rivers rather than like streams: the exaggeration it chooses at low zooms is inappropriate for "narrow canals" such as mill races.

Possible solutions:

1. New tag, such as narrow_canal. I'm not happy with this as it goes against English usage (they're all just canals) and we'd end up with more new tags for different sizes of canal (how else do you deal with the Panama Canal?). Not to mention the Wee Free Men (thanks Pterry) naming conventions likely to arise like bigger_than_a_wee_canal_but_not_as_big_as_a_big_canal.

2. Second-level tags: canal=ordinary, canal=panama_size, canal=mill_race, etc. Again a proliferation, which means more code and more work for the renderer. But it's better to have a proliferation of values than a proliferation of keys. So canal=bigger_than_a_wee_canal_but_not_as_big_as_a_big_canal can be considered a slight improvement.

3. Use width=. Looks pretty good to me. Except for the Panama Canal, so you probably still need the waterway=canal area stuff. I.e., do what we do for rivers but be a little more intelligent about the exaggeration at low zooms if width= or waterway=canal are specified.

Of course, I could be wrong about all of the above. All things are simple when you don't understand them.

[polarbearing]

@eehpcm - no need to make your posts longer by repeating the examples, they are still visible above.

width=* is not considered in the code.

The waterway as a line is used for routing, and I still find it appropriate to see regular canals at lower zoom levels. For the big cases, natural=water should work fine. So you just need one tag for the minor cases, e.g. canal=minor.

[dieterdreist]

2018-08-21 13:36 GMT+02:00 eehpcm notifications@github.com:

it is evident the tags for classifying waterways are scarce and the main classes leave definition gaps for artificial waterways which aren’t used for drainage or transportation.

A second-level tag would work, analogous to having service roads be driveways, parking aisles, etc. but I think that way is sub-optimal for reasons explained later.

it only "works" if we'd redefine the meaning of the current tags to widen the scope beyond draining and transport (assuming this meaning is consistently intended for the objects with the tags, I'm rather unsure about this). Still we would remain with a tag called "drain" used to describe the opposite of the natural meaning of the word, not quite intuitive.

[eehpcm]

@polarbearing

width=* is not considered in the code.

That is useful to know. Should the wiki be amended to say that standard OSM rendering doesn't (or doesn't currently) consider width=* for canals (and rivers?). I'm happy to make such a change if that is the case. No point in people using tags that have no function.

I still find it appropriate to see regular canals at lower zoom levels.

I agree. The exaggeration is fine there.

So you just need one tag for the minor cases, e.g. canal=minor.

That would work for me. Especially if it didn't vanish at lower zooms, just rendered like a ditch or drain.

[dieterdreist]

2018-08-21 15:56 GMT+02:00 eehpcm notifications@github.com:

@polarbearing https://github.com/polarbearing

width=* is not considered in the code.

That is useful to know. Should the wiki be amended to say that standard OSM rendering doesn't (or doesn't currently) consider width=* for canals (and rivers?). I'm happy to make such a change if that is the case. No point in people using tags that have no function.

I would not discourage people from entering useful information. Everybody can use the width, if the standard style doesn't (or mapnik wouldn't have allowed it for a long time) it doesn't mean others can't do it. Rendering is not the only purpose anyway.

[eehpcm]

@dieterdreist

Still we would remain with a tag called "drain" used to describe the opposite of the natural meaning of the word, not quite intuitive.

The opposite? I wouldn't go that far. In ordinary English a drain is something water goes down, into some sort of water network. It appears that in mapping usage, a drain is a fancy ditch (has a concrete lining or something like that), since Ordnance Survey maps make that distinction.

Technical usage is often different from ordinary English. Which is at odds with OSM trying to use words in their natural meaning. I think that's one we just have to live with. And drifting far off-topic for this forum.

[eehpcm]

@polarbearing

I would not discourage people from entering useful information.

Me neither. A lot of stuff gets mapped that isn't rendered on the standard map. It may get rendered elsewhere (the heritage stuff gets used on the historic place map), or may get rendered at some future date if vector mapping allows higher zooms. So I wouldn't say don't use it.

Everybody can use the width, if the standard style doesn't (or mapnik wouldn't have allowed it for a long time) it doesn't mean others can't do it.

I was thinking more along the lines of a note saying it may not be rendered on by all carto styles/renderers. Otherwise people wonder why it's not doing anything and start asking questions.

[dieterdreist]

sent from a phone

On 21. Aug 2018, at 16:01, eehpcm notifications@github.com wrote:

The opposite? I wouldn't go that far.

draining means getting the water out, irrigation means bringing water in. We should discuss this on [tagging]

[ghost]

@polarbearing wrote:

Probably use either a different value than canal, or use a second level tag to allow distinguishing by purpose. For example, highway=service has serveral subtags that classify it as minor, such as service=driveway, =parking_aisle or =alley. E.g. canal=irrigation.

There's already usage=* for this, e.g. usage=irrigation or usage=headrace. However the width of irrigation canals differs a lot, so this key doesn't help much for rendering.

What was the summary from the tagging list?

The summary is that – according to the definitions on the wiki – waterway=canal is the right tag for irrigation canals of any size, but that due to the thick rendering on openstreetmap-carto some mappers use waterway=ditch or waterway=drain for smaller (irrigation) canals, although waterway=ditch and waterway=drain are defined as artificial waterways 'used for carrying superfluous water'.

Besides, i had the impression that a new tag for narrow canals won't find a majority because the distinction to waterway=canal would be arbitrary.

Therefore, i think that a rendering based on width=* would make most sense. Or, if this technically isn't feasible or if it would slow down rendering too much, i suggest to reduce the width and to map large canals as natural=water + water=canal areas (which might already be the case for many of the wider canals).

[javiersanp]

I would vote for any schema that solve this question including using width. But note that altohugh most of this small irrigation canals have a regular width, it could not always be determined easily. Also I think it needs more work to be implemented.

As well as the distinction between waterway=river and waterway=stream is "that can be jumped across by a fit adult", I would like a distinction between wide and thin canals, either in form of a new key or a new value for the key canal. For me canal=levada could be fine.

[kocio-pl]

Is there anybody ready to make and test PR for resolving this?

[jragusa]

For the record, there is a discussion dealing about the difference between drain and ditch. It seems there is no consensus about their respective definition.

[Adamant36]

If canals are going to be rendered thinner, it shouldn't be by much. As it is the definition of a stream is something someone can jump over and canal's are wider then that. If they are rendered much thinner they will be the same width as streams. Which doesn't work. It should be so people can tell apart IMHO.

As an off-topic aside, I'd like to see canals start rendering at z11 instead of z12. Some of them are major landscape features that are comparable in width to rivers.

[eehpcm]

@Adamant36

If canals are going to be rendered thinner, it shouldn't be by much.

If the canal is unqualified by a width or a bank, I'd perhaps agree with you. The wiki says that either of those can be used to define how the canal renders. Another case where the documentation anticipated a change to carto.

As it is the definition of a stream is something someone can jump over and canal's are wider then that.

That assertion is incorrect. There are many types of canal. Navigation canals (with longboats). Irrigation canals. And mill races. I've mapped a mill race. It looks sort of OK at z=19. It looks stupidly large at z=18. And at z=17 it's ridiculously over-sized, almost as large as the mill pond that feeds it. As per the wiki, I tried specifying a width, which didn't help. As per the wiki I tried giving it a bank, which didn't help.

So far I've resisted the very strong urge to tag for the renderer and tag it as a ditch or drain because this thread offered the hope that carto would eventually do the right thing. But, as so often seems to be the case, there is reluctance to make a change that would avoid the need to tag for the renderer to avoid the map looking very silly.

Carto has every right to stick to some notion of essential purity of mapping whereby canals are all the same width. Some mappers will respond by mistagging in order to get sensible rendering. Either carto can render what people want to map or some people will map whatever renders sensibly, however mistagged that will be. Or perhaps carto can arrange for every canal in the world, whatever the type, to be widened to match what they insist on rendering.

[Adamant36]

"If the canal is unqualified by a width or a bank, I'd perhaps agree with you."

In general id say in abesense of rendering based on width you would render them on 1. a sort of mean of the general size of the three types of canals you listed. 2. in relation to how other waterways are rendered. In this case streams are rendered extreamly thin and rivers are rendered extreamly wide. So canals would be rendered somewhere between that. Or you can't tell them apart otherwise.

Looking at pictures of mill races they are still wider then streams. Although not as wide as boat canals. But just because your example doesn't look right next a mill doesn't really matter per say, because the style isn't suppose to be a 1/1 recreation of real life and a lot of things aren't rendered based on reality. For instance roads. Ways in particular have that problem.

If rendering of canals was changed based on the size of mill races, which would then make the other two types of canals that are wider look less "realistic," that wouldn't be any better then tagging for the renderer. Your essentially doing the same thing that makes it a problem, except through a backdoor of modifying the cartostyle to do it. There's always water areas as option instead. Personally, I'm not against canals being thinner, but it just has to not come at the price of being able to tell them from streams (although where I map in America canals are usually major features, that are extremely wide, and that people drown in all the time. So my prefrence would be to render them on the thicker side).

Is there a canal type tag? If so another option might be to render the width based on that. Then mill races could be rendered thinner then the other types without the need for width rendering (which I don't think is a good metric to render on).

[dieterdreist]

sent from a phone

On 5. Feb 2019, at 16:51, Adamant36 notifications@github.com wrote:

Or you can't tell them apart otherwise

I would not render canals smaller than rivers, big rivers will have the riverbank mapped and small rivers will usually meander more than canals. You could even try rendering them thicker than rivers.

[kocio-pl]

Some data to look at ( https://taginfo.openstreetmap.org/tags/waterway=canal#combinations ):

• 24 826 7.33% boat=*
• 14 439 4.27% width=*
• 13 843 4.09% boat=yes
• 11 425 3.38% motorboat=*

We could also go with medium canal line width, because when the canal is big, it should have some something similar to waterway=riverbank maybe?

[eehpcm]

@Adamant36

If rendering of canals was changed based on the size of mill races, which would then make the other two types of canals that are wider look less "realistic," that wouldn't be any better then tagging for the renderer.

Indeed. Here's the problem. They're all canals. One size doesn't fit all.

With the benefit of hindsight we might have come up with a better tagging scheme. We didn't. So the options are:

1. Force everything into a standard size. No matter how it looks on the map. No matter how misleading the impression it gives to a data consumer. It's a canal.

2. Come up with lots of different tags like mini-canal, big-canal, etc., so that they can be rendered at different sizes. Then force everyone to change all existing usage other than those that happen to match whatever we decide is the default.

3. Allow people to specify a width and render accordingly, using a default width if none is specified.

the style isn't suppose to be a 1/1 recreation of real life and a lot of things aren't rendered based on reality.

I'm not asking for 1:1. I'm asking for "not embarrassingly stupid." If I'm talking to somebody about OSM and show them some of the stuff I've mapped, I never show them that mill race because it looks stupidly wrong at any zoom and really, embarrassingly stupidly wrong at lower zooms. This is the sort of detail that, if shown to somebody as an example of what OSM can do, would convince them that OSM is absolutely useless.

Then mill races could be rendered thinner then the other types without the need for width rendering (which I don't think is a good metric to render on).

I think anything other than width is a bad way of doing it. Because then it's a judgement call along the lines of stream or river, which comes down to how far you can jump (another really bad metric). Canals, being artificial channels, have a width that is usually constant (they're made no wider than they have to be and no thinner than they must be). Using banks to specify a curved canal of constant width is twice as much work as mapping the centreline and specifying a width. A width is more generic than a type. It adapts to types of canal we haven't considered, or have created a tag for but it isn't handled by the carto. All you achieve with new tags for different widths of canal is encourage yet more tagging for the renderer whenever somebody has a canal type that hasn't been covered.

Forcing every canal to a single size doesn't work. It's like having a single width of highway for everything from minor roads to motorways/freeways/autobahns. Except roads are classified according to national standards and canals are sized to purpose.

[imagico]

Based on the current meaning of waterway=canal rendering it wider than stream/ditch/drain and less wide than river is a fairly reasonable idea. Indicating the difference between artificial and natural waterways in rendering would also be a good idea.

Rendering line features based on tagged width was in general rejected some time ago here (#1853) due to the code complexity this requires.

The established tagging for canal 'riverbank' polygons is natural=water + water=canal (14k uses) - though unfortunately of course plain natural=water is also common.

[eehpcm]

@imagico

Based on the current meaning of waterway=canal rendering it wider than stream/ditch/drain and less wide than river is a fairly reasonable idea.

For some values of "canal." The ones that are wider than a stream and less wide than a river (both flexible limits in themselves).

The established tagging for canal 'riverbank' polygons is natural=water + water=canal (14k uses)

Tried that. It didn't work. Possibly it works for canals wider than the rendering that would apply without the polygon but it doesn't work for ones that are narrower. At least not for z=18 and lower.

[ghost]

If rendering based on width=* is too complex, i suggest to display waterway=canal thinner if usage≠transportation|transmission.

While it is possible to map a canal wider than waterway=canal by mapping a natural=water + water=canal area, there is no possibility to render it narrower.

[imagico]

usage=transportation/transmission have only negligible use numbers in combination with waterway=canal. The sad truth is that so far there is no well established supplemental tagging for more precise characterization of artificial waterways.

Note boat=* would also not be suited to derive the size of a canal since large irrigation or water supply canals are not typically open to boats despite their size.

[Adamant36]

With the benefit of hindsight we might have come up with a better tagging scheme.

We don't have to have the benefit of hindsight. We can create better tags now. It happens all the time. It might take a few years to be adopted, but everyone has to deal with that if they want to see tagging improve.

I have a similar problem to this with parks. I'm extremely annoyed that national and state parks are tagged as just leisure=park and have the same obnoxious green color. There's already a park:type tag in use that could act as a way to render them differently, but its not widely accepted and the definition of what leisure=park should be tagged on isn't clear anyway. Awhile back I attempted to get the tag better defined and the park:type tag more widely adopted. It didn't go anywhere though and I don't have the time or will to push it further. The only other option would be render them differently based on way pixel size or whatever. Since national parks are usually much larger then local community ones. But that's not a perfect solution and it over complicates things unnecessarily. So I've just lived with it. I'm pretty annoyed with it on a daily basis though.

Then force everyone to change all existing usage other than those that happen to match whatever we decide is the default.

It wouldn't be forcing everyone to change the existing usage. It would create a sub-type tag that could be phased in over time. Some people might add it and some might not. Again, that's the current process. By adapting width your still forcing everyone to add it anyway. Since only 4.27% of the canals currently use it. Its an extremely small percent.

Allow people to specify a width and render accordingly, using a default width if none is specified.

Width is dead in the water. The only other option is a type tag. As it is though, your only looking at a two or three pixel range for canal's to be rendered within to not look like either streams or rivers. So it would essentially be something like two categories of width that would be to broad to be useful. Canal type is based on quality or category of canal anyway. The current rendering is based on how canals are different then other waterways. Whereas width rendering doesn't tell the map viewer anything about the relationship between canals and shrouding waterways or themselves even. Since there's no way for the map viewer to know that's the rendering variable being used. There was the same issue with rendering monuments and other things based on height. It doesn't actually tell the map viewer anything useful.

I never show them that mill race because it looks stupidly wrong at any zoom and really, embarrassingly stupidly wrong at lower zooms.

If we rendered canals the same width as streams id have the same problem showing farmers around here the map. I'm sure there's some smaller canals running along streams and it would be impossible to tell them apart. That doesn't work either. Its more important to know its canal and not a stream then to know its a "large" or "small" canal. Like you say, its relative anyway. Which means rendering has to be broad enough. Width is to specific and doesn't actually tell anything. If this was a mainly waterway style and you could other rendering rules like color along side it width would be useful, but its not.

[dieterdreist]

sent from a phone

On 6. Feb 2019, at 01:15, Adamant36 notifications@github.com wrote:

I'm extremely annoyed that national and state parks are tagged as just leisure=park

I thought the “simple” tag for those is leisure=nature_reserve

[Adamant36]

Yeah, but know one seems to use it in America for some reason. They always go with leisure=park. Epecially now with Pokemon Go, but there's national park imports from years ago that used it also. People get really pissed about retagging them to. A while back someone threatened a Jihad on me because I changed a national park to nature reserve and I had to report him to the DWG. People seem to prefer a fill color compared to a border. I think that's a lot to do with it.

I don't think nature reserve is really an American term anyway. I hardly hear it used outside of OSM if at all. Unless its for a protected wetland or something similar (in those cases its usually a toss up between being a preserve or a reserve). There's a lot of protected areas though. A lot of times people use both boundary=protected_area with leisure=park for national and state parks. Then sometimes a protection class. Although Telenav editors removed a bunch of the class tags recently for some reason I'm not to clear on.

[dieterdreist]

sent from a phone

On 6. Feb 2019, at 12:06, Adamant36 notifications@github.com wrote:

People seem to prefer a fill color compared to a border. I think that's a lot to do with it.

the term that was coined for this is “tagging for the renderer”, and it is seen as something bad

I don't think nature reserve is really an American term anyway. I hardly hear it used outside of OSM if at all.

surely it isn’t German. I think it is pretty self explanatory for people who speak English, although it isn’t the only way to tag these, it is commonly used as a fallback, due to the very broad scope. Try to convince the people that misuse leisure=park, and start retagging ;-)

[kocio-pl]

I've seen such protected areas with park tagging (IIRC on the north California and up to the Canada) and was not sure what to do with it, since I was not sure what is the definition.

Anyway, that's a problem for Tagging list, please stick to the canal things.

[eehpcm]

@Adamant36

It wouldn't be forcing everyone to change the existing usage. It would create a sub-type tag that could be phased in over time. Some people might add it and some might not. Again, that's the current process. By adapting width your still forcing everyone to add it anyway.

So it appears you're happy, in principle, with two or three sub-tags defining some aspect of the canal that affects how they're rendered. It might be specifying functionality (mill race, irrigation, navigation) or something else. Functionality isn't perfect because the width of a mill race will depend on the size of the mill wheel it drives, the size of an irrigation canal will depend on how large an area its irrigating.

Width is dead in the water.

As I understand it, this is a computational load thing. Being able to specify a continuously-variable range such as width and then rendering it as precisely as possible at each zoom is a non-starter. But consider this...

You seem happy with subtypes such as mill_race, irrigation, navigation to give three different renderings with slightly different sizes at some of the zoom levels. I'm happy with approximations of that kind. But the problem with such a scheme is that when somebody needs to map some type of canal that's not covered, they're likely to abuse one of the existing types to tag for the renderer. Experience here shows that it can take a lot of argument to get even trivial things like having canal=new_type render like canal=mill_race (or whatever tagging is decided upon), so even those mappers who know of this forum may avoid the hassle and tag for the renderer.

The thing is that with type tags you need a look-up table to decide that canal=mill_race is rendered one way and canal=navigation a different way. But you can do that with a width tag. Width less than n is a narrow canal, width more than n but less than m is a medium canal and width more than m is a wide canal. No need to aim for 1:1 representation, just use the width to decide which of three renderings to use. Quantized widths should be no worse, computationally, than having different types.

And it gets better. If vector tiles result in some of the promised improvements, instead of dividing the width range into three types it could then be divided into four or five, if that is desirable.

In the meantime, I made a change to the mill race that is embarrassingly bad. In my previous attempts to get it to look good, I'd surrounded a waterway=canal with a water=canal_bank. So I changed waterway=canal to waterway=ditch just to see what happens. Yes, it's tagging for the renderer so I'll have to revert it, but it now looks as it should. Not my preferred solution even if we get new canal types because adding a bank to a curved canal is a pain. But, damn, it looks good. I'm proud of how it looks. Ashamed of the tags, but proud of the appearance.

I'll leave it that way for a few days so people here can take a look. Try it at all zooms. Check it against the aerial imagery in Bing with your editor of choice. And then I'll revert it and invite you to check it again. As I said, mapping the bank is more effort than it deserves. I don't need 1:1 accuracy, but I really do want to avoid 1:ugly mapping.

[kocio-pl]

Width is dead in the water.

...Or maybe it's just being born?

If we make people aware of it, they might start adding this property more often. Width makes more sense for canals (man made structures) than for rivers (their width can vary a lot) for example.

[bhousel]

Please render waterway=canal thinner. The current rendering looks very strange for small irrigation canals and seems to lead people to wrongly tag them as waterway=ditch, waterway=drain (which are both used for carrying superfluous water) or waterway=stream.

Can we just invent waterway=sluice for these tiny canal-like things (mill races etc) that are too narrow for boats. https://en.wikipedia.org/wiki/Sluice

[eehpcm]

@eehpcm

I'll leave it that way for a few days so people here can take a look. Try it at all zooms.

Not very sensible. Relies on people's memory. If they can be bothered to look. Better to capture comparison images and post them here. Which is what I'll do.

Z19:

Z18:

Z17:

Z16:

Z15:

[ghost]

Can we just invent waterway=sluice for these tiny canal-like things (mill races etc) that are too narrow for boats.

Or maybe waterway=mill_race?

[bhousel]

Can we just invent waterway=sluice for these tiny canal-like things (mill races etc) that are too narrow for boats.

Or maybe waterway=mill_race?

"sluice" is a bit more generic... (all millraces are sluices, but not all sluices are millraces).

[ghost]

"sluice" is a bit more generic... (all millraces are sluices, but not all sluices are millraces).

I have to admit that i didn't know this word before. It's just that after reading the Wikipedia article i had the impression that sluice might be too generic (and too technical). If the term is also used for larger canals controlled by gates, like at hydroelectric power stations, waterway=sluice wouldn't help for differentiating their approximate size on the map.

[jeisenbe]

@imagico, there's been quite a bit of discussion above. What is your thought on the easy way to fix this?

Is it reasonable to try using a width=* cut-off (say less than 3 meters) to define narrow canals which should be rendered later and thinner?

Can we also use the presence of boat= or ship= for wide navigational canals which could be rendered a zoom level or two sooner?

[Adamant36]

Hopefully canals without a width tag are still going to be rendered the same. I've been mapping a lot agricultural canals in northern California and it really helps to have them rendered thicker then streams and at a different zoom level. Some of them are kind of important landmarks and major parts of the landscape. Even if they don't have boats passing through them.

[jeisenbe]

My thought was to render them a little thinner only if ‘width<3’ meters

I think that is the usual difference between waterway=stream and waterway=river?

[imagico]

The good first issue task coming from this would be simply to choose an overall smaller line width for canals. Anything else would not be a good beginner task any more.

Independent from that using any supplemental tag as a makeshift importance tag would be a big no-no for me - especially since none of these tags is in particularly widespread use. Using width tagging in a sensible way would require ground unit rendering which we have decided in the past not to use (but we could revisit that decision of course). That would be technically highly advanced of course.

In general the line width styling for waterways in this style could use re-evaluation. I did this in the ac-style before but this goes in a very different direction now than here (i for example start streams at z12 while here they now start at z14).

[Adamant36]

Using width tagging in a sensible way would require ground unit rendering

What's ground unit rendering? It sounds complex.

[imagico]

Ground unit rendering means rendering features in a numerically specified size (either via tag like width=* or calculated in some way) that actually represents a certain size on the ground (and not in Mercator meters as it would be if you just normalize a size value with !pixel_width!). Since CartoCSS and Mapnik have no native support for this, it requires relatively elaborate SQL code.

[jeisenbe]

I wasn't thinking of trying to match the rendering of waterways to their actual width at any particular zoom level or latitude. The idea is that the only difference between a waterway=river and a waterway=stream is that "a stream can be jumped across by an active, able-bodied person".

Translating this to <3 m, we could use the existing width tag to categorize waterway=canal into stream=size canals (width < 3m) and river-size canals (width > 3m), and render the thin ones with a similar width to streams, and perhaps similar to waterway=ditch.

I also think it's useful for the rendering to show if a waterway=canal is small enough that it can be jumped. If not, it's a hard barrier to travel by foot, unless you want to swim across. And a canal of this size isn't navigable by boat.

While in my dialect of American English it's perfectly acceptable to have an "irrigation ditch" (we had one right behind our house, which was actually about 3 meters wide), most OSM mappers do not think that waterway=ditch should be used for irrigation waterways, so the narrow ones need to be mapped as waterway=canal but distinguished from the wider canals used for navigation or transporting large amounts of water long distances, and width=* is fairly effective for this purpose.

[jeisenbe]

Re: Ground unit rendering - I don't think this is necessary for this style at the current zoom levels.

I do think it could be reasonable to adjust some of the features at z18 and z19 that are currently rendered thinner than they should, even at the equator. While the code for ground unit rendering is complex, it's easy enough to adjust the pixel width of features to match their mercator meters at the equator. I think @sommerluk was recently working on this for z20 highways, but z19 and z18 need work.

( If someone wanted to propose a "real-size" rendering at z20 or z21, that might be reasonable, since at such high zoom levels many features would be taking up a large portion of the screen, but this might not be the right style to try it first)

[imagico]

Ok, lets leave ground unit rendering out of the discussion here - there are good reasons for using this but there are also specific problems with that for waterways and none of these things has anything to do specifically with canals.

The line width in which waterways are rendered right now in this style has nothing to do with their physical width. It is an abstract line width indicating a certain class of waterways. As i see it using the width tag to determine the line width but not as a physical width but as a secondary classification would communicate to mappers that the width tag is not a tag indicating the physical width of the waterway but an importance tag. It would not provide useful feedback on correct use of the tag and it could lead to the use of width=* on waterways degrading to the same kind of arbitrary choice based on subjective preference of the mapper like the distinction between river and stream. In most parts of the world mappers draw the line between river and stream in a way that is very different from the nominal definition of these tags.

Anyway - i think the idea of re-casting the classification of artificial waterways in rendering from the current

• Class A: waterway=canal
• Class B: waterway=ditch or waterway=drain

to

• Class A: waterway=canal + width>3
• Class B: waterway=canal + width<3 or waterway=ditch or waterway=drain

or to a system of more than two classes (you have not said how you want to treat canals without a width tag) should probably be a separate question. Depending on the system of classification you might or might not solve the problem of this issue but in any case the implications of this go far beyond the scope of the problems discussed here.

Regarding the data - there are about 16k of 350k waterway=canal with a width tag of which about 6000 would probably parse as <=3m. 2m and 3m are the most common values and in the distribution the only clear feature is a minimum between 5 and 10m.