Render waterway=canal thinner #3354
Comments
|
Maybe there's a way to show how big (wide) are they without measuring them? I would probably render these with https://taginfo.openstreetmap.org/tags/waterway=canal#combinations Upsides:
Maybe we could also decide using What do you think about it? |
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). |
|
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. |
|
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. |
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.
What can we do, in your opinion, other than tagging the width? |
|
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. |
|
sent from a phone
On 21. Aug 2018, at 11:44, polarbearing ***@***.***> 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.
|
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:
Of course, I could be wrong about all of the above. All things are simple when you don't understand them. |
|
@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. |
|
2018-08-21 13:36 GMT+02:00 eehpcm <[email protected]>:
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.
|
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 agree. The exaggeration is fine there.
That would work for me. Especially if it didn't vanish at lower zooms, just rendered like a ditch or drain. |
|
2018-08-21 15:56 GMT+02:00 eehpcm <[email protected]>:
@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.
|
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. |
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.
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. |
|
sent from a phone
On 21. Aug 2018, at 16:01, eehpcm ***@***.***> 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]
|
|
@polarbearing wrote:
There's already
The summary is that – according to the definitions on the wiki – Besides, i had the impression that a new tag for narrow canals won't find a majority because the distinction to Therefore, i think that a rendering based on |
|
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. |
|
Is there anybody ready to make and test PR for resolving this? |
|
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. |
|
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. |
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.
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. |
|
"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). |
|
sent from a phone
On 5. Feb 2019, at 16:51, Adamant36 ***@***.***> 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.
|
|
Some data to look at ( https://taginfo.openstreetmap.org/tags/waterway=canal#combinations ):
We could also go with medium canal line width, because when the canal is big, it should have some something similar to |
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
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.
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. |
|
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. |
For some values of "canal." The ones that are wider than a stream and less wide than a river (both flexible limits in themselves).
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. |
|
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. |
...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. |
Can we just invent |
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:
|
Or maybe |
"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, |
|
@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 Can we also use the presence of |
|
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. |
|
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?
|
|
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). |
What's ground unit rendering? It sounds complex. |
|
Ground unit rendering means rendering features in a numerically specified size (either via tag like |
|
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 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 |
|
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) |
|
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 Anyway - i think the idea of re-casting the classification of artificial waterways in rendering from the current
to
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. |
|
Just created #3795 - consider "width" when rendering waterways. |
|
I know I'm personally guilty of using waterway=ditch, but it's only because of the big fat river-like rendering of canals. It's horrible. So how about this very simple solution: render it thinner if it's specifically tagged with usage=irrigation or canal=irrigation. Then the narrower rendering wouldn't affect the big navigable canals. |
|
Should this lose "good first issue", given how it's not clear what should be done here? |
|
"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." #3354 (comment) Rendering canal lines about 1/2 or 2/3rd the width of rivers would be worth trying. |
Please render
waterway=canalthinner. The current rendering looks very strange for small irrigation canals and seems to lead people to wrongly tag them aswaterway=ditch,waterway=drain(which are both used for carrying superfluous water) orwaterway=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).
The text was updated successfully, but these errors were encountered: