From OpenStreetMap Wiki

Jump to: navigation, search

Discuss Proposed features/Large rivers here

Riverbanks and ways

Did I understand the proposal correctly that both sides of the river have to be the same way? I have been creating them as two ways, with their right side pointing towards the water - and I just noticed that osmarender already tries to render them. For an example, please have a look at the area of Moabit (Name finder) in osmarender (and mapnik for a well-rendered reference without the riverbanks), and give me an example of how the proposal is meant. Should I split the rivers into several segments and create closed ways only for the riverbanks? Thanks, -- Relet 14:13, 16 June 2007 (BST)

~~OTOH, it seems to work with separate ways for each riverbank at the Rummelsburg lake near Rummelsburg station. -- Relet 14:17, 16 June 2007 (BST)~~

Fixed and understood. I still don't like it too much. ;-) -- Relet 11:18, 19 June 2007 (BST)

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)

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)

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)

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)

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)

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

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

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)

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)

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)

Talk:Tag:waterway=riverbank

Contents

Riverbanks and ways

Outdated main article page contents

Renderer patches

Alternative Suggestion

Example

Islands

Extension of proposal

Proposed solution

Central way in addition to riverbank?

Relation

portion of the way crosses the river

have_riverbank=yes

"area"?

questions before voting

Confusing name of value

riverbank tagged as natural=water

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

Distributary or anabranch

Personal tools

Namespaces

Variants

Views

Actions

Search

site

Toolbox