Talk:Tag:waterway=riverbank

2006: Outdated main article page contents

The main page seemed to have turned into a discussion area, and was very outdated, it's contents have been moved here. This could be refactored or thrown away

(river fill was done using a bitmap graphics editor - SVG file only shows the edges)

Each river has a different size so I think it would be better to define the rivers by areas. FredB 09:25, 6 Jul 2006 (UTC)

By and large, rivers are wider closer to the sea. Therefore the approach taken in some apps is to define the outlines of the river as coastline, and to add a centreline (in OSM speak, a way) for navigational/labelling purposes. Metadata could either be attached to this centreline, or to certain segments of the coastline. --Richard 09:40, 6 Jul 2006 (UTC)

I would support a central linear way augmented by subsidiary areas of water which reference it. It would be better to emphasise the area rather than the edge of the area. (In keeping with this, I think there is a good case for representing areas by a list of nodes rather than a list of segments. But this needs discussion elsewhere.) Perhaps like this:

<way id="54321">
  <tag k="waterway" v="river" />
  ...
</way>
<area>
  <tag k="waterway" v="river" />
  <tag k="river-ref" v="54321" />
  ...
</area> 

Discussion on water direction, towpaths and locks moved to Proposed features/Left/right things

Renderer patches

 <rule k="waterway" v="riverbank">
   <line class='waterway-riverbank'/> 
 </rule>

     .waterway-riverbank {
     stroke-width: 1;
     stroke-linecap: round;
     stroke: blue;
     }
     

Alternative Suggestion

Currently, taking the River Thames as an example, both riverbanks are drawn with the segments pointing downstream. If one riverbank were drawn in the other direction then it would be possible to fill the area between the riverbanks automatically using Osmarender.

Schematically the River Thames currently looks like this, with a <way> made up of segments 2 through 10:

     -->7-->8-->9-->10
1-->2
     -->3-->4-->5-->6

However, if it were drawn like this:

     -->7-->8-->9-->10
1-->6
     <--5<--4<--3<--2

then using an <area> rule in Osmarender rather than a <line> rule would result in a filled area.

The following Osmarender rule implements this:

 <rule k="waterway" v="riverbank">
   <area class='waterway-riverbank'/> 
  </rule>

 .waterway-riverbank {
   fill: #89bac6;
   stroke: #aaaaaa;
   stroke-width: 0.5;
 }

Example

Note: there would need to be a convention about which riverbank goes upstream and which downstream. I suppose this should follow the same convention as boats do - whatever that is.

Note: there is a small bug in Osmarender 2.0 that means that the open ends of the river do not get filled correctly in all circumstances. In the above example, a path is implied from node 10 to node 3 when it should be to node 2. So the corner appears to get cut at the end. This will be corrected in Osmarender 2.1 - ask me if you want a patch for this sooner. 80n 01:38, 1 Aug 2006 (BST)

Looks good! I presume you managed to use those riverbanks without too much trouble?

Yes, I had to change the direction of the segments on one bank and reorder the segments within the way. I did this locally, not in the main database. If this proposal meets with approval I will take the time to do it in the database. 80n 22:11, 1 Aug 2006 (BST)

Does it merge OK when the river narrows and becomes a single waterway=river line? (there's an example at Tynemouth if you need a test case, or further along the Thames). Ojw 21:57, 1 Aug 2006 (BST)

The riverbanks meet at a point, whereas the single river line is rendered as a fairly broad line. It may work better if the stroke width of the riverbanks is set to the same width as the river. Overlapping the river with the point also works in that it looks right, but doesn't seem like a kosher way of doing it. 80n 22:11, 1 Aug 2006 (BST)

---

Proposal for correct tagging of larger rivers:

The direction of the water flow is tagged by a central way which has the flow direction (waterway=river). In addition, the riverbanks are also tagged and form a way (waterway=riverbank) in a U-shaped fashion. The water should be always at the right side of the way (land is at the left side). Viewed with respect to flow direction, the way starts at the right riverbank downstream, heads the river up, and follows the left riverbank again downstream. The ways from opposite sides should be connected to generate an U-shape way. Connect these 2 ways at the upstream side by 2 segments which cross the central way (waterway=river) through a node belonging to this central way. Multiple U-shapes of the riverbank form the whole river.

Looks like this:

 waterway=riverbank:  o--6-->o--7-->o--8-->o--7-->o--8-->o--9-->o--10->o
                      ^                    ^
                      |                    |
                      5                    6
                      |                    |
 waterway=river:      o--1-->o--2-->o--3-->o--4-->o--5-->o--6-->o--7-->o
 (flow from left      ^                    ^
 to right)            |                    |
                      4                    5
                      |                    |
 waterway=riverbank:  o<--3--o<--2--o<--1--o<--4--o<--3--o<--2--o<--1--o
                                       here                        here

Note: flow direction is from left to right, numbers represent segments, o represent nodes. One central way (waterway=river) and 2 connecting ways (waterway=riverbank) are depicted. Each start of riverbank way is marked by 'here'. User: CdW, 03 Aug 2007, 15:00

Islands

Using this method islands in a river can be represented by making the island part of the same way as the riverbank but with segments pointing in an anti-clockwise direction. As long as the riverbank is tagged in a clockwise direction then the island will be rendered as a hole in the river.

• Tag both banks of the river as part of the same way
• Tag the left bank first then the right bank so that the segments point clockwise
• Tag each island as part of the same way
• Make sure the segments of the islands go in an anti-clockwise direction

Extension of proposal

This proposal seems a nice way to get rendering of rivers. However I feel it does not adequately cope with the situation where there is a small island in the river. Currently if both the main river bank, and the river bank of the island are tagged as waterway=riverbank then the island does not get displayed.

It seems to me there are a number of possible solutions, which I don't like:

• Instead of tagging the bank of the island as waterway=riverbank, tag it as something like waterway=island, have the rendering rule for this after the rule for waterway=riverbank, and make the rule waterway=island a white fill. Whilst this would work, I don't like it, as the rivebank of the island is not tagged as waterway=-riverbank, as so is factually incorrect.
• Draw the areas of the river such that the main riverbank, and the island riverbank form an area. This is clumsy and not intuitive, and would be particularly difficult where there are many small islands close to each other.

Proposed solution

Extend the tag, so that small islands in rivers are tagged as waterway=riverbank , island=yes. Then have a new osmarender rule which renders these areas with a white fill.

Dmgroom 01:03, 12 November 2006 (UTC)

Could this be extended/adapted for islands within lakes?

So long as the rule for "rendering waterway=riverbank , island=yes" came after the rule for "natural=water" (or whatever rule is used to render lakes) then I think it would work. Alternatively a new rule such as "natural=water island=yes" could also be used. Dmgroom 14:27, 12 November 2006 (UTC)

Islands within lakes use natural=land. Shouldn't we stick with the same?? Frankie Roberto 16:01, 3 August 2007 (BST)

2007: Discussion about the page

Central way in addition to riverbank?

Should a central linear way still be mapped in addition to the riverbank? --Nils 12:17, 15 December 2007 (UTC)

If you don't, then you don't know which way the water flows. --Cartinus 02:39, 29 December 2007 (UTC)

There is another inconvenience NOT mapping river center/flow : the name of the river does not appear along this one ... so IMHO it should be mapped --PhilippeP 13:34, 27 January 2008 (UTC)

Yes. also you should treat the centre-line a bit like roads, and try to ensure connectivity at river junctions. Imagine a rowing boat routing satnav application. And the centre-line should actually be the best navigation line (deepest bit of the river, and going the side of the island which is widest) rather than the exact centre.

There's also some very practical software reasons for always having a centreline. Renderers can use the complicated riverbank areas or fall back to the simple centreline data e.g. if you're zoomed out, or if the renderer is just a bit basic.

-- Harry Wood (talk) 16:59, 16 April 2015 (UTC)

2008: Discussions

Relation

The components of a large river (and indeed the separate ways of a standard waterway=river) could be linked with a relation which gives you the whole river. (Unfortunately component ways in relations are not ordered so this can't determine the direction) David.earl 10:13, 28 January 2008 (UTC)

portion of the way crosses the river

It's a bit troubling that a portion of the way crosses the river but is still marked riverbank. You get a reasonabe rendering, but for other applications this could be problematic. We can't solve this with this proposal using relations or any other current mechanism AFAICS as it would need to identify a 'segment'. David.earl 10:13, 28 January 2008 (UTC)

Look at the 'Proposal for correct tagging of larger rivers' on the talk page, the riverbank does not cross the river, the river center/flow is present and it works in osmarender. --PhilippeP 11:06, 28 January 2008 (UTC)

In that proposal the riverbank still crosses the river, but only once. (U shaped in stead of O schaped.) --Cartinus 21:22, 3 February 2008 (UTC)

Ooops my mistake, I originally thought the riverbank was splitted but it is not --PhilippeP 11:00, 8 February 2008 (UTC)

have_riverbank=yes

The central waterway could interfere with the riverbanks or inner islands at place where it is too close to coast at some zooms/rendering styles. Therefore I have extended the proposal with have_riverbank tag to solve this. --Bilbo 01:36, 18 February 2008 (UTC)

Is this still necessary when all ways are in one relation like in the corresponding proposal? -- Fröstel 16:04, 23 February 2008 (UTC)

The relation as mentioned includes only the riverbank and the islands, but not the centerline - so the relation should be kept as "classical" multipolygon, but the centerline is not in the relation. I think it is desirable to hide the centerline once we zoom in enough to draw the riverbanks. We can either add the riverbanks and centerline in another relation or we can use have_rierbank tag. Or we can specify both .... have_riverbank is easier for people, relation will tell which piece of riverbank correspond to that centerline. --Bilbo 13:56, 25 February 2008 (UTC)

How about putting centerline in the same relation as riverbanks, but with a role "simplified" or so. --Stefanb 21:57, 26 February 2008 (UTC)

There's a similar proposal for the relation (see below), where I suggested role=core. -- Fröstel 22:01, 26 February 2008 (UTC)

Yeah. have_riverbank=yes... I see how it might provide a quick fix for the rendering problem, but it seems a bit clumsly to me. It's the kind of thing relations are designed for. Let's remove that stuff while we're going to the vote (because at the moment even the basic ideas are still only listed as a proposal) Then we can discuss this as a seperate proposal later -- Harry Wood 13:42, 8 May 2008 (UTC)

"area"?

Should the riverbank really be an area? Is a concept as way not better - compare with coastline which I can split...

As a concept yes, but in reality it gives the renderers various problems. A lot of processing has to go on in the Tiles@home and Mapnik renderers to get the coastline as a solid fill. See mailing list discussion [1]Dmgroom 14:18, 1 March 2008 (UTC)

questions before voting

A few questions arise from the proposal and the above discussion:

• If the river areas are to be closed in the fashion the diagram of the proposal's main page shows, ways crossing the river necessarily overlap. Is this desired? JOSM reports overlapping way during validation (however, not as an error).
• Is the central river way supposed to cross the river areas without intersecting the ways crossing the river, as the sketch suggests?

Yes. The way and the area serve a different purpose. There is no need for a node where they intersect. Like you don't need a node where a highway enters a landuse area. --Cartinus 21:53, 10 May 2008 (UTC)

Hmm i've been always mapping these as intersecting, but ... fair point -- Harry Wood (talk) 17:17, 16 April 2015 (UTC)

• Where does the central river way end, within the last river area before the coastline?

At a node that is shared with the coastline. Just like a "narrow" river. --Cartinus 21:53, 10 May 2008 (UTC)

I've been always drawing a little tail out into the ocean because I think I've see minor rendering glitches caused by stopping on the line. -- Harry Wood (talk) 17:17, 16 April 2015 (UTC)

• Is it mandatory to tag the river area with waterway=riverbank and natural=water?

No: If the tag waterway=riverbank is accepted, then the use of natural=water to tag areas of river would be depreciated. Dmgroom 14:03, 11 May 2008 (UTC)

Nowadays (7 years later!) we seem to be moving towards using natural=water instead of waterway=riverbank . See Key:water#Rivers and reservoirs. But the wiki may not match with mappers have mostly done. For feeding into the most systems, the safest option is use both tags, but it terms of correctness things seems to be going the way of natural=water + water=river -- Harry Wood (talk) 17:17, 16 April 2015 (UTC)

• Shouldn't the proposed river relations be considered here explicitly? This could be a source of confusion, as the sketch on that page suggests a different constellation of ways.

7 years later, I think we've essentially settled on using standard multipolygon approaches ...if we want to use relations. However I tend to avoid using relations unless I'm mapping a river with lots of islands. I deal with occasional islands by chopping off the riverbank area at that point in the river. Life is simpler for everyone that way -- Harry Wood (talk) 17:17, 16 April 2015 (UTC)

--Ulf Mehlig 18:43, 9 May 2008 (UTC)

2009: Discussion

Confusing name of value

waterway=riverbank is currently recommended and used to delineate the area in between two opposite riverbanks. I am sure I am not the only one confused by this name; to me a riverbank is linear feature. I understand that the current approach (i.e., it being an area not a line that needs to be stitched together) makes for much easier processing, and I am in no way opposed with this; I just wish the recommended value was slightly different. I would much prefer to use waterway=riverbed or something like this that clearly shows that the tagged feature is an area, not a line. Sorry for adding my two cents so long after "the fact".--sanna 09:33, 13 January 2009 (UTC)

riverbank tagged as natural=water

I'm not sure whether the suggestion to tag riverbank areas with natural:water is a good one, because in my experience difficulties arise with the rendering of islands tagged via multipolygon relations. --Ulf Mehlig 12:18, 27 September 2009 (UTC)

2010: Discussion

Could there be a way to avoid tagging the central river ?

I think we agree that drawing the central river AND the riverbank is a waste of time and duplicated information. I know this is usefull in a few case like :

• 1) Knowing the way the river flows
• 2) Easier to use for "simple" tools which just use the way and not the riverbanks

But do you think it could be possible to represent 1) by, (this is just an idea) drawing the riverbanks in the direction the river flows ?

sletuffe 11:15, 6 June 2010 (UTC)

No. We don't agree that drawing the central river AND the riverbank is a waste of time. In fact that approach has been the agreed way to map "large" rivers for several years now. We don't do riverbanks in the direction flow because, as is clearly illustrated in the diagrams, the waterway=riverbank ways form closed polygons, so you have to have one side upstream one side downstream -- Harry Wood 09:02, 7 June 2010 (UTC)

Okay, excuse me for my undiplomatic sentence, please read : "I think that drawing (...) is a waste of time".

Yes, I know we have done that for a long time, and it prooved to be working and usable. I am just wondering, not even suggesting that we shouldn't, but wondering if another way of doing could save mappers time, avoid duplicating data (such as name maybe) while still beeing friendly enough to data consumers. Given the way it is suggested to tag now, of course riverbanks are automatically opposing in direction, but tagging the river using, for example, the type=multipolygon area system, then riverbanks could both have the same direction. sletuffe 17:24, 8 June 2010 (UTC)

I can't imagine that making anything easier for mappers, and it will definitely break any "simple" tools (your point number 2) So I guess its fun idea to float, but not really a practical change mappers should consider.

Also the centre-line is not only for indicating direction. Imagine a boat routing satnav application. The centre-line should actually be the best navigation line. Deepest bit of the river (if we ever have any way of knowing it), and going the side of the island which is widest, rather than necessarily following the exact centre. In other words: the centreline is useful duplication of information, but more than that it's the most important information, and also captures some unique information not represented by the river banks.

If saving the mappers some time is the aim, it might be possible to design some neat plugins for mapping wide rivers more quickly. E.g. start by mapping the centreline and the plugin lets you add the riverbanks quickly (roughly) It would be a bit of blunt instrument, but could be useful for getting all the large rivers of china and siberia mapped. Or map the riverbanks first and the tool finds the centreline and adds it.

-- Harry Wood (talk) 17:33, 16 April 2015 (UTC)

2011: Discussion

Distributary or anabranch

Sorry, I don't know which is the correct name in English, just looked for it on Wikipedia. I am trying to map some streams in Medium Paraná River that branch off the mainstem. How do I do it? I made differente riverways for the mainstem and the distributaries, all of them included in a multipolygon relation. --Pertile 00:40, 3 April 2011 (BST)

It's mostly possible to do these things without multipolygon relations. Can you give us a link to the map? (click 'permalink' in the bottom right and paste in the URL here) -- Harry Wood 11:32, 3 April 2011 (BST)

This is the link. Thanks in advance. --Pertile 23:43, 9 April 2011 (BST)

OK. Quite a complex river bank. It all looks OK apart from this bit is not finished off yet.

Further to the north around here the islands have all been mapped using a big multipolygon. The islands are holes in the multipolygon. You could continue to map it that way, but instead you can draw in separate areas for the tributary channels. I suppose it depends how you want to think of it. A bunch of separate channels, or a bunch of islands?

Let's map them as separate channels. It's close to that at the moment anyway. So the main part of the river is part of a multipolyon, but you can ignore this. There's a just a few things to fixup here:

1: The waterway=river way should be roughly down the middle of the river, so shift those nodes a bit further towards centreline.

2: The western edge of the river is already mapped with some place=island areas. The way of the waterway=riverbank needs to be at the same place and sharing the same nodes in fact. Create new nodes on the riverbank way, and then as you go down you need to "join" the nodes pressing "J" in potlatch (or "m" to "merge" in JOSM)

3: Finally the separate channels have centrelines already, but these should probably join onto the centreline of the main river. This will mean that any system ignore riverbanks will still make sense of a centreline river network from the waterway=river data.

-- Harry Wood 11:35, 10 April 2011 (BST)

Thank you very much. --Pertile 22:50, 10 April 2011 (BST)

2012: Discussions

New page changes about waterway=riverbank on rivers's banks

At http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank#River_junctions a new changed appeared proposing to use waterway=riverbank for banks while it almost always was used for areas.

First, I kind of agree that riverbank doesn't sound like an area thing, but I find it risky for usage to have two exact same tags+values for different things (one to record the water bed and one for the bank) so I find the warning it is incompatible with the mainstream definition of waterway=riverbank as an area tag. So use this interpretation at your own risk more than appropriate at least.

Second is that even if we accept that double tagging, using waterway to describe the bank of a river isn't really accurate either, it's not a water's way, it's a bank, shore, border or a coast but not a river way.

My proposition to avoid conflicting tags is to propose what I allready use for that : another set of tags. May I introduce those four tags natural=riverbank natural=lakebank man_made=riverbank man_made=lakebank ? sletuffe 16:18, 3 September 2012 (BST)

The continued attempts to redefine riverbank are annoying. Dear Sanderd17, there is no reason to modify the meaning of a tag which already has a widely used different meaning. Doing so just makes any transition from riverbank to natural=water much more messy. If you want a tag for banks, invent one and propose it. I don't particularly care whether you call it waterway=bank, whatever=riverbank or something else, as long at it doesn't already have a different meaning.

As for sletuffe's suggestion: The idea to use a different key is good, but I don't think that mappers should be forced to be forced to guess whether a riverbank is man made or natural if they are not interested in that. If that distinction is tagged at all, it should be a subtag imo. --Tordanik 19:28, 13 September 2012 (BST)

Your suggestion on my suggestion is a wise one. That makes sense. What counts first if someone wants to tag banks is that it is a bank, natural, man made, lake or whatever is secondary, therefore a additionnal tag is better. I'll probably switch my suggestion to proper "proposal page" to gather remarks sletuffe 20:01, 13 September 2012 (BST)

I tried something here : Proposed_features/banks sletuffe 23:38, 13 September 2012 (BST)

I missed this discussion, but as I commented on the User_talk:Tordanik, the waterway=riverbank has been used on non-closed ways for a while now (or at least documented this way). The original tagging schema with the multipolygon relation (even before the proposal to use natural=water for every water body) mentioned that the outer ways (which are non-closed) should contain the tag waterway=riverbank. I don't want to redefine the waterway=riverbank tag, I just want to make the page a bit consistent, and merge it (in some way) with the current approved proposal to use natural=water for every water body. It was not my idea (you can even verify that I never voted for that proposal), but if it's agreed, it should be mentioned in every page of the wiki that has some relevance to it. And this has a lot of relevance to it. It didn't feel like redefining waterway=riverbank in my view, I thought it was already used that way. --Sanderd17 12:13, 19 September 2012 (BST)

It is true that the page has recommended duplicated tagging with both riverbank ways and riverbank multipolygons even before your edits, and that this is inconsistent with "onWay=no". The reason I gave for my revert was therefore not appropriate, I simply had not noticed this recommendation in the text.

However, even if we acknowledge that this inconsistency exists and want to correct it, it could also be corrected in the other direction: by removing the suggestion to tag the members of waterway multipolygons. And I believe that this would actually be more consistent with the OSM universe outside of the wiki. For example, JOSM validator will generate warnings if you apply waterway=riverbank to ways, and I do not know of data consumers that expect the duplicate waterway=riverbank on members of riverbank multipolygons. --Tordanik 13:33, 19 September 2012 (BST)

The duplicate mapping of the area tags on the outer way and/or the multipolygon#usage was part of the multipolygon definition. You can find some hints about that on the Talk:Relation:multipolygon page. As you can read on the multipolygon page now, it is recommend only add the area tags to the multipolygon and remove the area properties from the outer ways. I think that change should just be applied to any area mapping including the riverbank areas. --Werner2101 09:47, 29 December 2012 (UTC)

Problems with giant river multipolygons

I was asked to provide citations for the following three statements regarding the suggested approach of mapping an entire river as a single, huge multipolygon:

1. longer rivers mapped with that approach cause problems for many data users
2. multipolygons for the entire river offer no tangible advantages
3. they place an unnecessary burden on data consumers.

I'm convinced that statement 1 is true from personal experience as a developer who struggles with handling these relations. I have been told about similar difficulties by at least two other developers, and there were also issues with Osmarender previously documented on this page which I have not experienced myself. You may remove the "many" if you feel that this qualifier is unsupportable, but at least some data users do quite obviously have difficulties handling multipolygons of this size.Tordanik 23:10, 11 February 2013 (UTC)

I'll be happy to remove the word "many". "Many" suggests that a majority of data users have difficulties. Those using osm2pgsql for instance, wouldn't have that much difficulty as the support for multipolygon (wich is what this 2nd model is describing in fact) is allready coded in. Even more, osm2pgsql users might have more problems with the split river model when it comes to computing the surface area of a large river or when you want vector export as a single object for use in a vector client. I'd say that since the type=multipolygon model has been more and more widly used by mappers, software support for it increases and can both be re-used for any type of areas. sletuffe (talk) 11:42, 12 February 2013 (UTC)

This isn't about "multipolygon support" - all the tools I'm talking about do support multipolygons. This is specifically about the size of the resulting object. There would also be a problem if the entire river was drawn as a single large way (but luckily this is not allowed by the API).--Tordanik 15:16, 12 February 2013 (UTC)

What exactly is the problem with the "size of the resulting object" ? There are several huuuudge polygons in the db (check out Italy for example) and the processing of such big multipolygon still works. I' unsure if big rivers would be by several order of magnitude bigger (and also what is size, what is big ?).

About the "that would be a problem about the river's central way" I'm not sure, that is allready done : http://api.openstreetmap.fr/analyse/cgi-bin/index.py?relation=132818 for a 6339 points object of 1000km and it isn't really complexe to manage with proper tools. But it gives you far more power and ease of processing because you don't need to stick pieces by their name or by geometry consideration. sletuffe (talk) 16:33, 12 February 2013 (UTC)

Italy: border relation, can easily be thrown away for many use cases. Loire: waterway relation, can easily be thrown away for many use cases. If you were proposing to add the individual river area segments to the waterway relation - like the river way segments - to make it easier to find out that they belong together, then my complaint would not apply. The problem is that the giant multipolygon (which I and others cannot easily process) replaces the smaller closed ways and multipolygons (which we do need for processing). --Tordanik 17:21, 12 February 2013 (UTC)

As for calculating the surface area of a large river or producing a single vector object for an entire river, the same argument could be used against splitting roads into separate ways, which is nevertheless commonplace and - in the case of T-junctions - even inevitable. --Tordanik 15:16, 12 February 2013 (UTC)

I'm using the same argument against splitting roads for the same reasons. OSM is an ever moving model, there might be better result with model X in case Y but we are talking about large rivers here. The topic of model unification across all OSM area objects is another topic and discussed here http://lists.openstreetmap.org/pipermail/dev/2013-February/026541.html and needs more insight of the current OSM storing model, and isn't easy to deal with at all ;-) sletuffe (talk) 16:33, 12 February 2013 (UTC)

Regarding statement 2, I consider demonstrating the advantages of this mapping style for everyday uses of OSM data a responsibility of those supporting it. Until this has happened, I believe that the statement can be presumed true.Tordanik 23:10, 11 February 2013 (UTC)

I have an easy one, day to day seen : check the river "la Seine" on the opencycle map : http://www.openstreetmap.org/?lat=49.0359&lon=1.55788&zoom=16&layers=C As you can see if you look carefully, there is a white line marking the arbitrary junction between the two sticked polygons. This wouldn't be seen in the type=multipolygon model, or at least, this wouldn't require tricks in the style to solve this "junction line"

Here is another drawing use case : Proposed_features/banks#Use_case_exemple where drawing the river's banks is much easier with the multipolygon model. sletuffe (talk) 11:42, 12 February 2013 (UTC)

Using one multipolygon for each river isn't going to solve the tiny-white-line issue entirely, as it also appears at junctions between rivers, between rivers and lakes, or rivers and the sea - unless you want a single multipolygon for all water bodies in the world. But it could be worked around quite easily by drawing a thin outline in the same color as the fill color around each river polygon.Tordanik 23:10, 11 February 2013 (UTC)

True, but it solves it, easily, in several cases at once and even without touching the mapnik style, you won't expect such a good result without consumer data effort ! Staying with the splitted joined polygon doesn't solve any, at least mine does solve most, beside river confluence point. sletuffe (talk) 16:33, 12 February 2013 (UTC)

It removes several, but not all, of the tiny-white-line cases, but causes the river to completely disappear from other renderings. Meanwhile, a trivial change to the render style could treat all cases of tiny-white-line without affecting any other tools. Why would anyone consider the giant multipolygon when facing this trade-off? --Tordanik 17:21, 12 February 2013 (UTC)

The second use case is simply an advantage of using multipolygons per se, and I'm fine with that. It works just as well without limiting yourself to only one multipolygon per river. --Tordanik 15:16, 12 February 2013 (UTC)

Only partially, but if you find the style modification to mapnik to support rendering in the case I linked to, with the stiching polygon model, I'm sure some maps rendering admin would be glad to know how (me at least). I've tried, but I failed. Since real banks aren't tagged at all, there is no easy way to tel appart what is an arbitrary stiching junction and what is the real bank of the river. And that's what makes this rendering very hard. while the linked image, is created with rendering of the model I'm proposing, and that was quite easy. While I still admit the lake/river junction still needs care at tagging side. sletuffe (talk) 16:33, 12 February 2013 (UTC)

Statement 3 is merely a logical conclusion of the previous statements.

Please note that all this is specifically about attempts to build a single multipolygon for an entire river. Using multipolygons for smaller sections of the river does not cause these problems. --Tordanik 23:10, 11 February 2013 (UTC)

global answer : I am not saying that the "one multipolygon only for one river" doesn't have any problems at all (for the mappers for example, it might create editing difficulties) but I think saying that for data consumers it creates more problems than it solves, I am not agreeing. Or the true answer being "everything is relative (to the tools you are using and to the result you want to get)sletuffe (talk) 11:45, 12 February 2013 (UTC)

Too much relativism can easily conceal that some solutions are indeed more problematic than others. I think I have explained why "one multipolygon per river" is either not needed or insufficient to solve most of the problems you gave as examples. --Tordanik 15:16, 12 February 2013 (UTC)

I feel that I won't be able to convince you, just like it won't be easy to convince me. Isn't this the case where we express what are the different possible modeling ? with drawbacks and advantages ? with the first one on top beeing the more used ? If the answer is yes : to let the best survive, then the sentence they should not be used. Use multiple small multipolygons instead. shouldn't be used IMHO, this isn't objectiv, let the mappers decide. sletuffe (talk) 16:33, 12 February 2013 (UTC)

By the way, I find the subject interesting, and not at all trivial, could this be of interest to move this discussion to the [tagging] list, to discuss this matter more widely ? sletuffe (talk) 16:59, 12 February 2013 (UTC)

"Let the mappers decide" won't work anymore as rivers all over Europe are being inserted into relations on a large scale by non-local mappers already.

There was a discussion on [tagging] about this a while ago, by the way. You can find it in the archives here: [2]. If you feel your arguments were not fairly represented, you can of course start another one. --Tordanik 17:54, 12 February 2013 (UTC)

Very good thread, thanks for sharing. Most of what I and you said is expressed there, with a list of pro and cons of the two solutions. This relate closely the the question of Areas objects I linked on [dev]. I won't be restarting a thread, but reading this one carefully and maybe added some more thoughts. sletuffe (talk) 18:22, 12 February 2013 (UTC)

2015: Improvements

This page is very difficult to understand because of more more additions without consolidation. Let's improve!--Jojo4u (talk) 10:29, 11 July 2015 (UTC)

1. Not defined for relations

In the infobox "onRelation" is "yes". But waterway=riverbank is not defined for relations. There is no relation of sole type "waterway=riverbank". It is defined as an area and thus also used as a multipolygon. Multipolgons are excluded from "onRelation".--Jojo4u (talk) 10:33, 11 July 2015 (UTC) Overpassing in Europe+North America I found one example one example of a relation waterway=riverbank without type=multipolygon. But this a tagging mistake since type=waterway defines the whole river and so this example should be subtagged waterway=river instead of riverbank.--Jojo4u (talk) 10:47, 11 July 2015 (UTC)

I agree, that's a straightforward correction. I've thus edited the "on relation" attribute. --Tordanik 17:56, 11 July 2015 (UTC)

2. Consolidating How to map

Tagging a riverbank falls into 2 categories:

1. Without or with few islands - Recommended tagging is as an segmented area with segment borders after some reasonable distance or at the location of islands. See remark by Harry Wood on 17:17, 16 April 2015 (UTC) on this page.
2. With many islands - Recommended tagging as multipolygon with one outer and 1..n inner.--Jojo4u (talk) 11:05, 11 July 2015 (UTC)

3. Usage of Relation:waterway

This relation is representing the whole river including it's linear representation and the waterbody/riverbank. The section Unification of the island case and normal case with a multipolygon relation would be rewritten for this relation instead a multipolygon with severals outer as it is now.--Jojo4u (talk) 11:05, 11 July 2015 (UTC)

I agree that we should recommend the waterway relation here, as it's the approved solution for the problem. It could also help to shorten the page if we relied mostly on the relation documentation page and only included a short description here. --Tordanik 18:04, 11 July 2015 (UTC)

The waterway relation was originally intended and approved only for the linear representation of the river and not for the riverbank, islands and whatever else. If you look at the talkpage it is a controversial addition and I would not like to have this page to endorse either method. It is not approved btw. RicoZ (talk) 20:41, 12 July 2015 (UTC)

You are right, riverbank as member was excluded in the proposal and is currently debated. I didn't check the discussion page. --Jojo4u (talk) 22:34, 12 July 2015 (UTC)

Why only large?

Is there actually consensus to forbid mapping small rivers as areas? Mateusz Konieczny (talk) 11:13, 2 May 2019 (UTC)

Large is only relative. A river as area doesn't add much information, and is hard to maintain (changing water levels and such). But if you get to a certain detail on the map, people start zooming in, and it makes sense to map the water area anyway. --Sanderd17 (talk) 19:00, 2 May 2019 (UTC)

There is no reason not to map small rivers as areas but the main reason many people do it is that most renderers ignore river width tags and I think this is wrong on both sides. Renderers should user river width and mappers should not map for the renderers or work around their deficits. RicoZ (talk) 10:57, 3 May 2019 (UTC)

I think there is a consensus that streams tagged with waterway=stream should not be mapped as areas. Usually this means anything smaller than 2 or 3 meters wide, but sometimes up to 5 meters or more. Perhaps if we want to discourage mapping very narrow rivers as areas, we could mention this relative cut-off, but the line varies based on how intensively a certain region is mapped. I wouldn't think there was anything wrong with mapping a 5 to 10 meter wide river as an area, if all of the wider rivers have already been mapped in the region --Jeisenbe (talk) 04:41, 10 August 2019 (UTC)

I am not sure about it. Note that in some place people are using area:highway=* to map footways as areas! Mateusz Konieczny (talk) 23:29, 11 August 2019 (UTC)

I think the real issue is that Carto and maybe other renderers ignore "width" attribute of waterways. Fix that and people will stop wasting their time to map 2m wide streams as areas.... RicoZ (talk) 18:21, 13 August 2019 (UTC)

“Don't use both tags”

Why is it wrong to use both natural=water and water=river, and waterway=riverbank? Wouldn't it be an ideal workaround for engines and renderers that don't support both? —S. Jevtić ^talk·OSM 17:40, 12 August 2019 (UTC)

• Yes, in this case using both tagging schemes at once should be perfectly fine Mateusz Konieczny (talk) 18:18, 12 August 2019 (UTC)

I agree. In practice there's not much problem in just using waterway=riverbank (or just natural=water + water=river), because both waterway=riverbank and natural=water have been used since very early in the history of OSM. I believe just about all renders and database users will support both tags as "water". Just using waterway=riverbank has the benefit of only requiring one tag to clearly specify flowing river water, and should just about always be handled as a water area, so I think just using that is enough. If there is a specific database user that needs natural=water + water=river, it's no harm to add this, too. --Jeisenbe (talk) 10:11, 13 August 2019 (UTC)

1. the workaround is not needed, I strongly believe there doesn't exist a renderer that would support only one of the schemes
2. you will shoot your feet sooner or later, there is a considerable number of corner cases that may manifest in some renderer or another if you use both tags in an unusual combination. Some years ago I spent a few hours figuring out why the islands of the Isar river between Sylvensteiin reservoir and Bad Tölz suddenly disappeared.. the reason the river was marked with a riverbanks multipolygon and someone added a natural=water somewhere ( I think it was the river relation).

Summary.. no reason to do it, just asking for trouble. RicoZ (talk) 18:15, 13 August 2019 (UTC)

• No. Duplication of different tagging schemas leads to confusion & errors. Doing so would be considered tagging 'incorrectly' to suit the renderer. Renderers should adapt to suit what's in the OSM database. Most do render both schemas, I believe.

natural=water, water=river is the preferable schema as it aligns with all other bodies of water.(pond, lake etc). The two tags allows a convenient way for renderers & data users to filter data. (search for 'natural' if all bodies of water are required, or be more specific by using the 'water' tag). It also discourages the mis-tagging of canals as riverbanks. DaveF63 (talk) 21:43, 2 November 2020 (UTC)

• Using two tagging schemes, both indicating the same thing is not "tagging 'incorrectly' to suit the renderer". Duplication may be pointless or undesirable, but it is not "tagging 'incorrectly' to suit the renderer". Mateusz Konieczny (talk) 16:46, 3 November 2020 (UTC)

The OSM database requires quality not quantity. The two tagging schemes are mutually exclusive. Adding both, because programmers can't be bothered to write a couple of lines of code to handle both, is tagging incorrectly to suit the renderer.--DaveF63 (talk) 19:59, 4 November 2020 (UTC)

"The two tagging schemes are mutually exclusive" - untrue, you can use both on a single object. And if both mean the same it is not an incorrect tagging (tagging with say landcover=water would be unusual and not preferred, but also would not be incorrect) Mateusz Konieczny (talk) 09:10, 5 November 2020 (UTC)

2020 Discussion

Made of water?

At the very top we read

The tag waterway=riverbank is used to map the water-covered area of a river

OK, but we usually think of riverbanks as being made out of land, not water. So right away there should be a sentence saying

Yes we know riverbanks are made out of land, and one can stand on them without getting one's feet wet, but we are using this term to make a rectangle etc. around the water in the river

etc. Jidanni (talk) 23:24, 26 March 2020 (UTC)