Proposal talk:Waterway (relation)

Link to the RFC at the osm talk list: http://lists.openstreetmap.org/pipermail/talk/2010-April/049240.html

general discussion

The wiki page mentions river,stream,drain and uses the way symbol but fails to mention or take into account people that have drawn riverbank areas which uses the river way as one bank, a good example of this is the Murray River on the NSW/Vic border in Australia, the legal definition of the border is the southern bank of the river which follows the main flow of the river.

• http://www.openstreetmap.org/browse/relation/454706

This will most likely be an exception since most of the time people will plot a centreline for the river and the riverbank either side of it. Delta foxtrot2 16:24, 31 March 2010 (UTC)

• as the riverbank way is tagged with river, it fits well into the proposal --Werner2101 10:41, 1 April 2010 (UTC)

what should go into the relation?

Only river skeleton? Skeleton + banks? Skeleton + banks + islands? ... + gates, dams, bridges?

• I'd prefer to put into relation as much as possible. One possible usage of our river relations is ability to extract from database only water ways. For example someone plans a trip on his own boat down the Danube river, and he doesn't have resources to run mkgmap for entire Europe, nor he has enough memory in his Garmin. With a detailed river relation for Danube he can extract only useful cut from database. --Glebius 12:37, 1 April 2010 (UTC)
• I agree with Glebius. Loir 17:32, 1 April 2010 (UTC)
• I think only the center of the river should be part of the relations. Adding everything into the relation makes them large and hard to maintain. It's not very likely that you will ever get a "complete" relation of a river. Your possible usage, extracting a map along a river, can be easily achieved with a simple river relation and some scripts. e.g. "Make a map along the Danube with a given limitation area". (demo_image, The red rectangles represents the garmin map area) --Werner2101 11:40, 2 April 2010 (UTC)
  • We already got complete relation for Volga :) So this is entirely possible and maintainable. --Glebius 13:37, 5 April 2010 (UTC)
• I agree with Werner2101. Only the middle of the river should be maped into relations. 1.) We can see the lenght of the river in every part. 2.) In roads, we make also only the middle line into the road-relation and not the edge of the road, traffic signs or the footway along the road. If you think too much, otherwise you would have to add the parking place, Fast Food etc. along the road. That makes no sense. Smarties 22:23, 2 April 2010 (UTC)
• After trying some waterway mapping methods, I think banks are too deezy for the main waterway relation. Maybe collect waterways in collection relation and append it to waterway relation as riverbanks role. In other hand, springs, gates, dams... are important points (or ways) of interest, I will be glad to see it in relation (and not bridges). Frodrigo 19:09, 3 April 2010 (UTC)

• Keep in mind that Relations/Relations are not Categories; a relation without any roles likely tells us very little or nothing that is not already evident from the geometry. Make the destination/tributary_of a member, not a tag, and add (well, propose to add) the outline of the area that drains to the river as an another member... or other related things. Alv 00:08, 4 April 2010 (UTC)
  • The relation is not used as a categorie here. We add usefull tags that are common for the whole waterway. Adding all the tags to every waterway way segment would be much more work. The relation is usefull to reference or download a whole river, too. I agree that the tributaries of a river could be relation members, too, but the tributaries are not the primary goal of the proposal. I think we should discuss it again when we create watershed relations --Werner2101 10:10, 9 May 2010 (UTC)

• I use waterway=source to tag the node at the beginning of a named river or stream. Often the source of a river is the confluence of two smaller streams and despite the possibility that clever software can determine this point, nevertheless it makes sense to me to tag it. If this proposal goes forward, perhaps the waterway=source node could be a relation member with role=source. AlaskaDave (talk) 18:31, 5 May 2019 (UTC)

Review of waterway relation proposal as a mapper

Thank Werner for getting in touch. I am a big mapper of rivers in remote areas. I am not an expert in or even heavy user of relations. My focus in tagging discussions is on intuitiveness and ease-of-use for the mapper, so I respond accordingly. Others, such as Glebius have already made interesting comments on ease-of-use as a user of map data.

From that perspective, I think Werner and Smarties have done a good job and I support the proposal. It is lightweight to implement and simple to understand. The study and summary of existing methods is a particularly good, I wish everyone would do that! http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/planet_waterways.html

As I understand it the focus is on treating a waterway (river, canal, ...) as a broadly linear entity. Here is how I see it working as a mapper, and some assumptions and questions.

I can map a river as a series of possibly disconnected ways (waterway=river and/or waterway=riverbank). Sometimes I draw both a river way as a centre-line AND riverbank. Sometimes I draw river OR riverbank.

Once I have reasonably identified the river, I can create an initial relation. All I need is 3 things. I like this feature of the proposal! Simple and elegant! :-

type=waterway waterway=river (the way for a river may change into "stream" in the upper reaches or have canalised sections, but that does not affect the relation) name=XYZ River

I can then add the relation to all my waterway=river ways.

Question: Is there any reason why I should not *optionally* add it to all my riverbank areas too? And indeed anything else, waterfalls, lakes it passes through, harbours, ferry terminals, ... etc? All we are saying is that they have a relationship to a linear waterway thing. User Smarties, using a road analogy, says this makes no sense. But is that true? As long as the user of a road route relation can depend on the centre-line of the road being there, why not put fast food service points? They will either help some user extract information about a river or road or can simply be ignored.

Back to being a mapper. Over time, I can add more detail to the waterway relation:

I can add names in different languages. I can add reference ids. Other things I might optionally want to add are core statistics, most likely length in km. Possibly a ;-separated list of what ISO 3166 countries it flows through or borders.

I can add a wikipedia link. Note: I prefer to use wikipedia:en instead of wikipedia. This allows other people to add links in other languages and for automated software to correctly find the right URL.

tributary_of . (tributary_of is more intuitive to me, but I appreciate 'destination' is is more generic). Yes, as mapper, I would like the simple option of marking in plain text that a river I've found in Ecuador is an Amazonian tributary, or that it actually goes to the Pacific. However, in the future we might want to put a list of relation ids of other waterway relations when Potlatch, JOSM or their replacements can handle it. Should we reserve a waterway relationship tag name for this?

watershed. This is not mentioned in the proposal. Someone has done a lot of work on this in Russia. I assume the simplest option is to do nothing. A waterway relation needs to know nothing about watershed. But waterway relations could simply be added to a watershed relation. There a very few examples of rivers that flow into two watersheds (one in Brazil I think), but they could simply be added to both.

MikeCollinson 11:19, 11 April 2010 (UTC)

destination vs. tributary_of

On the talk page of the river relation the tributary_of=* tag mentioned (Talk:Relations/Proposed/Rivers). Both tags destination and tributary_of are used a lot.

• I'd prefer destination because tributary_of does not fit well if the waterway does not end in another river. e.g. The destination of the Nile would be the Mediterranean Sea. --Werner2101 12:43, 26 February 2010 (UTC)
• I also prefer destination=* instead of tributary_of=* to describe where the destination of the waterway is. destination=* is more multifunctional. destination=* It can also be used in channels, drains and rivers which flow into the Sea, while tributary_of=* applies only to rivers. Smarties 23:29, 10 March 2010 (UTC)
• Isn't this redundent information, since that information can be encoded in it's own way/relation etc? (ie no diff than adding is_in tags to everything) Delta foxtrot2 16:19, 31 March 2010 (UTC)
• I agree that destination is more "general" than "tributary_of". We should discuss no the name of the tag, but its contents. Should that be a string with some word, or should it be the ID of the object in the database? I prefer the latter. But the problem is that we do not have objects for oceans and very large lakes. --Glebius 12:30, 1 April 2010 (UTC)
  • I think a simple name of the destination river/sea is enough. If we'd like to create data structures that can represent all links between rivers, we should work on the type=watershed relations described by katpatuka. --Werner2101 11:55, 2 April 2010 (UTC)
• I always think linking object by name is bad solution. A way of do it (but never aplly) is append tributaries relations as members of destination relation. Or add destinations to tributaries relations. Frodrigo 19:15, 3 April 2010 (UTC)
  • It's just a small hint. Adding them as relations is also not required, as waterways are usually connected. --Werner2101 10:43, 2 January 2011 (UTC)
• I dislike this tag, no matter how it is named. It does not bear any usable information. Let's say we have a destination=Blue River. There may be a dozen of rivers with that name so we don't know which. It's also possible that we don't find an object with that name at all, because it has name=Río Azul. We could search for an object with name:en=Blue River then, but how do we know that we are searching for an English tag value? The language of the destination=* tag value is not specified in this proposal. It would be better to include the destination as a member with role=destination. But even this is useless, because of what Werner2101 said. Assuming that the end node of a waterway is part of its destination too, the destination can be determined automatically. --Fkv 22:28, 17 October 2011 (BST)

tributary vs. tributary_of relation role

A tributary waterway is part of this tributary_of. But tributary_of is not part of current waterway. I think so tributary waterway relation role can be added on current waterway with role tributary. This way of link waterway has advantage to build watershed (drainage basin) just by recurse on tributaries relation role, without need of specific relation dislike WikiProject_Rivers. Frodrigo 09:33, 31 July 2010 (UTC)

• I am unconfortable with this way of doing. It makes the relation even more complexe with ways/relation as members which are not the main river. Also, virtualy, the watershed "fr:bassin versant ?" can still be constructed by shared nodes betweed water ways, without the need of a pyramidal member tributary inclusion (IMHO)sletuffe 17:00, 29 September 2010 (BST)
• I don't like the tributary_of relation role. The waterway relations are no longer describing only the waterway if you add the tributaries, but the watershed to. Watersheds could be created with your system (type=watershed or type=waterway;waterway=watershed) and make use of the waterway relations as members, but mixing waterways and watersheds together is not a good idea. As sletuffe stated already the watersheds can be traversed with the shared nodes of waterways (even if this is little bit more complex then using hierarchical watersheds or tributary_of relation role in waterway relations. --Werner2101 12:10, 24 October 2010 (BST)
  • Some time ago I wrote a small script that traces down watersheds and build a hierarchy of waterway relations. So there is no need of tributary members at all. hierarchical waterway view --Werner2101 10:38, 2 January 2011 (UTC)

syntax of the reference tag

It is slightly hard to guess the meaning of the ref:sandre= or ref:fgkz= tags. Both are only abbreviation of national numbering schemes.

An alternative tagging could use the country codes, like often seen in wikipedia:de and name:ru tags:

ref:fr=A0000--1234
ref:de=1246

A second alternative combines both tagging schemes:

ref:fr=sandre:A0000--1234
ref:de=fgkz:1246

or:

ref:fr:sandre=A0000--1234
ref:de:fgkz=1246

--Werner2101

• When a river flows only through one country he should get only one reference like ref=A0000--1234. But if it flows through several countries, we should add more references. First I thought that it is easier to sort by country. But now I find it easier if we sort only for shortcuts. Such as ref:fgkz=1246 or ref:sandre=A0000--1234. Smarties 15:58, 29 March 2010 (UTC)

I prefere to know a indicator of a ref. If only ref is tagged you do not get much information and it is not that easy to know what is meant. --Skyper 13:02, 1 April 2010 (UTC)

waterway=ditch

I've added waterway=ditch as a subtype, because you can compare it with waterway=drain. I hope that's ok. (Edit by Ebbe73)

• Yes it is Ok. Thanks to Ebbe73, He has pointed out that we forgot waterway=ditch. Smarties 21:55, 28 April 2010 (UTC)
• Thanks, you're right --Werner2101 09:41, 9 May 2010 (UTC)

Why?

What is supposed to be the use of a waterway relation at all? -- Malenki 19:28, 22 October 2010 (BST)

• to build one object for every waterway. You can add common tags to that relation. I've extended the main article a bit now. --Werner2101 10:40, 2 January 2011 (UTC)

and be able to create something like that : [1] which would be much more harder to create if there wasn't waterway relations. (To give an hint, this map is not just made by drawing any waterway=river because it whould be a huge mess of lots of small rivers, but instead only waterways relation exeeding a given length of ~60km are displayed) sletuffe 15:31, 2 January 2011 (UTC)

You don't need relations to calculate river lengths. You can find out which parts belong together by comparing node coordinates (espescially of start and end nodes) and maybe layers. --Fkv 21:45, 17 October 2011 (BST)

I don't know what you mean by "layers", but nodes coordinates are not enough to tell which river continues where in the case of river confluence. sletuffe 11:36, 18 October 2011 (BST)

I mean that one waterway may cross the other over a bridge (bridge=yes + layer=1). Of course there shouldn't be an intersection node. In case of river confluence, the direction of ways matters. The river continues where the way points away from the confluence point. If a river branches, the continuation can be ignored which has either another or no name, or the lower-grade waterway=* tag. If both are equal, both continuations must be followed. Usually they join at a later point, or they form a river delta, ending up in the same sea. --Fkv 02:54, 19 October 2011 (BST)

What you suggest is to define if a river continues or stop by checking if the way after the confluence has the same name as the one before ? I fear this is prone to errors. Suppose the river crosses countries, it's name=* might change, suppose the way in a local region is known by a different name or other reasons for those two ways to have different name I haven't thought of. Therefore we need a way to know wich river ends and which river continue at the confluence point. That's, to my point of view, what this relation aims at recording. sletuffe 11:09, 19 October 2011 (BST)

We ware talking about confluences where at the same point the river branches. I.e. rivers A and B join at a point where rivers C and D start. Now it seems a rare case that C and D have other names than A and B. However, you are right in that we need to take name mismatches into account. Following a river downwards automatically won't work because we don't know where to stop.

What about this algorithm:

table river_section:
   id number
   has_a_confluent boolean
   primary_confluent_id number
   section_length float
   length_including_confluent_chain float
table confluent_candidate
   id number
   confluent_id number
   confluent_grade alpha  // river, stream...
Step 1: split waterways on non start-or-end nodes that are part of other waterway
Step 2: fill in river_section.id and calculate section_length for each waterway=*
Step 3: for each river_section:
              check if start_node is part of other waterway object(s)
                 for each of those:
                    if the node is not the start node of the other object, add record to confluent_candidate
                      if there is at least one confluent_candidate:
                        determine highest-level confluent_grade of them
                        delete those with other grade
                        set has_a_confluent to true
                     otherwise set has_a_confluent to false and length_including_confluent_chain to length
Step 4: iterate over all river_section's with has_a_confluent=true and primary_confluent_id=null as long as such exist
              for each of those:
                 if all confluent candidates have length_including_confluent_chain not null:
                    sort them by this means:
                       if chain A and chain B have more than the end node in common:
                          give preference to the chain with shorter length between that common node and the end node
                          // don't follow meanders if there is an abbreviation
                       otherwise give preference to the chain with greater length
                       // todo: in the uncertain case of equal length, do some more comparisons
                       take topmost candidate
                    write its id to river_section.primary_confluent_id
                    set length_including_confluent_chain to length + chain length
Step 5: Each river has now total river length (= length_including_confluent_chain) in final river section. More information (e.g. all river names) can be found by traversing the confluent chain using river_section.primary_confluent_id.

One drawback of that approach is that it only compares lengths, not water flow, as this is not mapped usually. --Fkv 06:43, 21 October 2011 (BST)

It seems to me that the one and only practical use of current waterway relations is that you can set wikipedia links on them. --Fkv 21:45, 17 October 2011 (BST)

and name, and ref. sletuffe 11:36, 18 October 2011 (BST)

you can use it to, to set a link from wikipedia to the waterway object or download it within every programm you like. That's the main benefit of the waterway relations. --Werner2101 07:06, 29 October 2011 (BST)

Different waterway sections

There are waterways which widen from waterway=stream to waterway=river, and have straightened sections which are waterway=ditch or waterway=drain. The page should describe what happens when the relation omits waterway=*, to allow different kinds of sections. And what happens if the relation has, e.g., waterway=river, but sections are waterway=drain? —Michael Z. 2011-05-12 01:43 z

Thanks. I've added an hint to the waterway key: just use the larger waterway type for the relation. --Werner2101 12:01, 13 June 2011 (BST)

Actually I think that a river is normally a river from its beginning on. No need to tag it stream for the initial part, in fact that would harm the data quality IMHO (for instance even with "stupid" rendering it would be nice to have the river visible from its start to the end in medium zoom levels).--Dieterdreist 13:44, 19 February 2012 (UTC)

Well, that's why the relation has a waterway=river tag, while the way segments can have waterway=stream tag. The way tags are for the ways, and the relation tags are for the relations (see. key:waterway) for the way definitions. For the relation the river Rhine only gets one waterway=river tag, even if it might start as a small stream somewhere in austria. That's what the note on the main page is good for. Hopefully we get a situation when we have one relation for each river and a single relation can match to single wikipedia entry e.g. ([2]). --Werner2101 16:43, 20 February 2012 (UTC)

I find it too complexe/not generic enough (sly's model)

I know I might seam a bit extrem, (and a dreamer ?) but I feel that multiplying relation types is bad in regard of the osm data usability for tool developpers. This multiplicity might seam to serve mappers well, but makes it harder to people who wants to use the data. Therefore, I think there is a tradeoff. And this relation could possibly be, at least in it's core, as generic as possible.

My exemple of dream is the type=multipolygon relation. It's generic, re-usable, and when you understand one, you can use it for boundaries, forest, lakes, large rivers, natural reserv, etc. It ends being easy for mappers as well as users.

Ok, let's stop the blabla, let's see how and if it could be simplified : sletuffe 16:39, 20 February 2012 (UTC)

Is the spring member necessary ?

I think the role=spring member is not necessary, or else, whould we need to include the confluence point as well ? It can be found automatically by taking the first node of the entire relation (given nodes are all ordered in the way the river flows) sletuffe 16:39, 20 February 2012 (UTC)

The spring came from the french mappers. It's not really required (optional in the proposal) and can be dropped if nobody likes it. I don't care much about it. --Werner2101 17:06, 20 February 2012 (UTC)

This member is not main part of proposal. But there is spring, but not always. Even when there is spring, is not always mapped, especially in not yet mapped mountain. OSM have to deals with partially mapped data. First node is not always the spring, first node not always start of the (still partial) waterway. Partial topology is not sufficiency, topology it self is not sufficiency (there is also subterranean river). Frodrigo 15:20, 21 February 2012 (UTC)

role=main_stream

I suggest that the role for the main stream should be "none", not one or the other. Therefore the construction logic of the whole river could be re-used for any entities that needs to be represented as a long line made of multiple ways. sletuffe 16:39, 20 February 2012 (UTC)

I think, as soon as there are more than one roles it is better to have a name for each one.

Just compare it to multipolygons, where we have the inner and outer role, where outer can either be written as outer or None. --Werner2101 17:32, 20 February 2012 (UTC)

role=side_stream

This one is not the river skeleton, I think it should be left aside.

• Either we consider it to be automatically detectable by the fact it shares it's two extrem nodes with the main stream
• Or we construct a new specific relation having the skeleton relation as member, the side streams as members, the riverbank as member, and what ever else cannot be a simple geometry. sletuffe 16:39, 20 February 2012 (UTC)

Sometime tributaries of rivers flow into the side_stream, if the side_stream is a member of the waterway relations it's easier to create watersheds by analyzing all the waterway relations. (see the tools section)--Werner2101 16:53, 20 February 2012 (UTC)

Thematic relation addres need of deals with complex object, isn't pure geometric grouping (eg look at public transport relations). Over simplification of waterway relation is nonsenses, objective of waterway relation is not deals with an over simplificated waterway as a multilistring. Frodrigo 13:53, 22 February 2012 (UTC)

I do agree with that. Not every element can be represented by over-simplistic geometry model. But the current proposal for type=waterway doesn't covers everything either, for exemple, the river's bed is not included. Which means another double tagging of name, ref, etc. in an other relation for the type=multipolygon+(natural=water or waterway=riberbank) is still needed.

My proposal to include all that would look like this :

relation

Key	Value	Description
type	whole_river
waterway	[river, stream, canal, drain, ditch]	If the waterway starts as a stream and becomes larger, then use the tag of the largest waterway (e.g. river). If the whole waterway is useable as a canal (even if parts of it are a true river) tag is as canal
name	*	+name:fr +name:it ...
ref	* (optional)	any kind of reference
*	*	any tags applying to the whole river, if it is does apply only on some members, put those tag on members (like boat=no/yes)

members

Object type	Role	Recurrence	Description
	main_stream	one only	the type=multilinestring relation forming the central stream, starting at spring ending at confluence point or sea/ocean
	river_bed	one only	the type=multipolygon relation forming the whole bed of this river/canal
	side_stream	zero or more	Any segments or groupe of segment (in a type=multilinestring relation) that are side streams of the river, if they have special name in their own, put name=* on them. Note : One side stream should only be one and only one member, not the composition of different members
	spring	optional	natural=spring The spring of the river
	?	optionnal	Any way, relation or node member which cannot be geometry linked to the river (maybe/maybe not tributary rivers)

Just after I wrote this tab to describe the model I have in mind, I find it in fact very close to frodrigo's : User:Frodrigo/Relation:Waterway with one important (to me difference) : All the members I propose are autonomous, you don't have to process all members to construct the whole geometries, because all members describe only one geometry. Thus, if you want the main_stream, just process the only main_stream member, if you want the river bed, same. sletuffe 14:37, 22 February 2012 (UTC)

As soon as you have the main_stream, it is possible to get all riverbank areas (river_bed in your table) that touch the river. It would be lot of work to collect and create the riverbank relations. That's just a waste of the mappers time. And I guess you'll not be able to download a single (complete) riverbank relation from the api, because they are so big. I think the node density on riverbanks is 10 to 20 times higher than on rivers.--Werner2101 18:20, 22 February 2012 (UTC)

I think there might be a case where that is not true : It might happen that a canal shares it's waterway with a river, and in that case both the canal's waterway and the river's waterway will intersect a common river bed. Altough I agree we should try to let the mapper's work to a minimum, I think it's worse doing it for the sake of usage simplicity and relationnal linking between river's elements (bed/main_line/side_stream).

API : I think API limitations and technical issues are aside from the proposal. However you turn it, dowloading the whole water bed won't be easy and wether it's a member of not will not change that. And if the river bed is a multipolygon relation, it should be possible to only download parts of it the same way as with huge forest/lakes just as it is now with multipolygon waterway=riverbank relations. sletuffe 19:34, 22 February 2012 (UTC)

Creating large rivers by using multiple main_stream segments (ways or your kind of multilinestring) might be an option. Just the same as the relations type=boundary_segments that build larger boundaries. TMC segments for road routes, ...--Werner2101 18:20, 22 February 2012 (UTC)

yes it could be. But processing tools will need a list of roles to know wich one means what and with which it should be joined in a flow of several other roles. My goal is to gather in the same relation (the child relation in my model) the ways forming one geometry for one object. I wrote the type=boundary_segments proposal you mentionned in this spirit of being a child member of a type=multipolygon/boundary relation with and only with members that together form one boundary (there are no needs for special roles with special processing rules). The type=boundary_segments relation is the equivalent of my new type=multilinestring relation proposal as a model, but I regret to have choosen an un-generic name value back then. sletuffe 19:49, 22 February 2012 (UTC)

Before writing down my model on User:Frodrigo/Relation:Waterway, I try something similar to your proposed. I found it too verbose and endly complicated. You spread idea of simplicity and you propose a more numerous relations solution. After using a 3 relations strategy (meta relation + centre line (and side stream) relation + multipolygon riverbank), I found it's heavy. Now using a light version putting centre line directly in relation, keeping riverbank as optional role. Secondly side stream is only a minor alternate way of waterway, keeping them along mainstream and only distinguish with role seen me light (but break your multilinesting generic idea). Frodrigo 19:01, 22 February 2012 (UTC)

One more relation is the price to pay if I want geometry isolation for all constituant of what is a river. If the goal was to have the minimum number of relation, we whould have gone for only one with every ways (riverbank/main/side) in it with appropriate roles. This should work by the way, but I think that generic processing algorithms (like the one used in osm2pgsql for multipolygon) would have problems. Here I don't want to say that we should model according to osm2pgsql abilities, but I want to keep that in mind if we want to have tools to process data because there are allready few. sletuffe 21:06, 22 February 2012 (UTC)

choosen word for the type

type=waterway was maybe choosen to describe it is a waterway, however, like multipolygon, this is redundant because the relation allready has a tag waterway=*, let's make it even more generic and only related to the shape, have a look at my proposal : Relation:multilinestring

Given the fact that the database is allready full of type=waterway, type=waterway could be indicated as valid relation type as well as type=multilinestring for a waterway relation and expressing it has the same geometry construction. (like type=boundary and type=multipolygon almost are when it comes to boundary relations) sletuffe 16:39, 20 February 2012 (UTC)

Well, this proposal tries to simplify the waterway relations and reduces the relation types. type=river, type=stream, type=collection + collection=waterway, type=route + route=waterway will go away. A waterway is not simple a geometry shape like a multipolygon. I guess the right geometrical description for a waterway would be DAG (directed acyclic graph), not a multiline or a multilinestring. The type=waterway was choosen as it existed already and it's a good word to match all waterway types (streams and canals), too. --Werner2101 16:59, 20 February 2012 (UTC)

Far away goal

My goal is to propose to have generic relation type for building simple geometries in order to have a "framework" on which mappers can build more complex entities when needed or use them as is when the need is simple. I don't say every thing can be simple, but I think this proposal (waterway) could be.

Not all elements of this proposal could be applied to waterways, but I think at least moving a little towards simplication whould be good. sletuffe 16:39, 20 February 2012 (UTC)

If someone asks for the faraway goal of the proposal, I'd say that we get a one to one match between wikipedia articles and osm waterway relations. As we add the wikipedia tags to the relations, it will be easy to match wikipedia to osm and vice versa.

Additionaly with the relations and a cool tool, we can trace every drop of water from the spring to the oceans all over the world. I'm just dreaming ;-) --Werner2101 17:04, 20 February 2012 (UTC)

Tracing the waterstreams all over the world - that will be cool. Smarties 19:41, 20 April 2012 (BST)

Remove tag waterway=[river, stream, canal, drain, ditch]

After all, the relation is never a collection of the same waterway type. Why should we specify "the tag of the largest waterway" when it can be deduced by the ways members ? For the purpose of this relation, the "type=waterway" is enough. --Pieren 21:11, 21 February 2012 (UTC)

I think sly way in double tag type=waterway+waterway=* is better. After all the tag type=waterway is useless. We are not using type=waterway+waterway=* on ways. Frodrigo 13:13, 22 February 2012 (UTC)

My choice whould be to drop type=waterway and keep waterway=*. I agree with pieren that one is enough. But since there exist canals using a portion of a river, I find it fine (and needed) to have a waterway=canal on the relation and one member having waterway=river. sletuffe 14:02, 22 February 2012 (UTC)

Most relations (at least all approved and all proposed) have a relation type. The latter (waterway=[stream,river,canal) is less important. The type tag makes it easy to select all relations of a type for post processing. In general it's useful to see all the relations that have no relation type that might be added accidently by new mappers. It's a good starting point for quality assurance work. If that's all what's missing to persuade you so that you agree to the proposal, I can make the waterway=* tag optional. --Werner2101 18:37, 22 February 2012 (UTC)

(Don't know if that answer was for me or for pieren) . I might not have made myself clear, I meant to have the type=waterway replaced by type=multilinestring. The fact that a relation describes a waterway or a boundary is depicted by the tags it has like waterway=* or a boundary=* (for exemple this is what is done with the type=multipolygon). What I'd like is the type=* tag to be used as a geometry type description if it belongs to the list of geometry construct type tags (multipolygon/multilinestring) in order to have a common processing algorithm when using data. sletuffe 19:22, 22 February 2012 (UTC)