Waterway relations are not rendered?

I was working on a river in Sudan.
A single way should be used for both the boundary and a river.
However, when I do that, the river vanishes from the main OSM rendering.

I followed the instructions on http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Tagging and http://wiki.openstreetmap.org/wiki/Relation:waterway

  1. Add the way to a relation.
  2. Don’t use any tags on the way itself.
  3. Tag the relation with “type=waterway” and “waterway=river”.

JOSM doesn’t render the way as a river, and the www.openstreetmap.org tiles don’t show the river at all!
Am I doing something wrong, or is the documentation wrong, or are waterway relations simply not supported by anything?

Hi
from http://www.openstreetmap.org can you, via the share button on the right, paste a link here of the area you are editing, so we can check if all looks ok.
I suspect you are doing it correctly and just need to wait for the tiles to be rendered with your changes.
You can put the tiles in the queue earlier by ‘dirtying the tiles’ if you are feeling impatient. From the osm link above, right-click the image and select ‘view image’, then add /dirty to the url
i.e. c.tile.openstreetmap.org/13/7577/4746.png/dirtyand hit return and you will see a message ‘Tile submitted for rendering’
The tiles that you ‘dirty’ should be updated in a few minutes.

Nevw, you can see an example at http://www.openstreetmap.org/#map=16/10.3771/25.9308
There should be a river flowing along that boundary and to the east.
The tiles refresh within 30 seconds; i.e. when I remove the “waterway” tag from the way and put it on the relation instead, the river vanishes. The fact it’s vanishing means the tiles are updating.
Note, as I said, that JOSM also fails to draw the way as a river, even though it belongs to a relation which is a river.
JOSM does not have that problem with border relations.
This makes me thing that both JOSM and openstreetmap.org’s default rendering fail to support waterway relations.
Do you know if that is the case?

Too complex for me…best I just watch and learn. I can see the river in Josm flowing off to the right. Where the river shares tags with the admin boundary might be conflict for the renderer to resolve. This is an interesting question you raise.

The renderer draws it correctly in similar cases, e.g. when a way is tagged as waterway, but is a member of a relation tagged as boundary.
E.g. at http://www.openstreetmap.org/#map=18/-27.34386/30.48163
You can see how it’s drawn as both water and boundary.
So the question remains, boundary relations are clearly supported, are waterway relations not supported?

For your information, the relation type “waterway” is not intended to replace the tag “waterway” on ways but, as said on the wiki, “to group elements of a waterway=*” : http://wiki.openstreetmap.org/wiki/Types_of_relation

See also the wiki about the type=waterway, section “Members”:
any kind of waterway ways. They usually have a waterway=[river, canal, stream, drain, ditch] tag
no riverbank areas

Basically, this relation is ignored by renderers and is more used by other applications trying to retrieve a whole river geometry and all its tributaries through a relation id.

Hi,
the waterway-relation is optional and if existing, it’s **additional ** to the waterway-line.

So, simply draw you river as a line with waterway=river and the river-area as waterway=riverbank.

And as usual areas may also be tagged as multipolygon-relation.

Thanks Pieren and chris66. I have restored the “waterway-” tag to the ways themselves, and they render correctly again.

It is unfortunate that this behavior is inconsistent with the wiki at http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Tagging which says:
“It is suggested to apply all tags which describe the area to the relation, and not to the ways. In many cases this may result in completely untagged ways.”

In the case of waterways, the practice of additional tags (waterway on both the way and relation) seems redundant, and not suggested practice.

This remark is only for multipolygon relations types. The problem with the waterway relation is that the proposal is not very good. It’s also not answering a rendering issue (then renderers don’t care about it).

The problem is the relation collecting multiple waterways of different types (stream, river, canal). The “waterway subtype” in the relation is a mistake. The documented solution says “If the waterway starts as a stream and becomes larger, then use the tag of the largest waterway (e.g. river).”. But could be computed by any data consumer loading all relations members. It’s true that the feature should be tagged only on a element. Today, the “waterway” value in the relation can conflict with the waterway value in the way which is in general a bad concept.