Talk:Relation:waterway

members/riverbank or water

The text "The waterbody of the river. This can consist out of riverbank ways, or water=* (multi)polygons" appears to say that the waterbody could be tagged with just water=*, not with the usual combination natural=water + water=*. I assume this is unintended? RicoZ (talk) 11:30, 18 May 2015 (UTC)

Actually there's still no standard defined and usages are varying; even many rivers do not attach their riverbanks to the relation listing the linear members.

This recent comment was added because there was a discussion about this informal/de facto use (it is mostly used on long rivers, for which there's a need to split riverbanks into relations, that are progressively built up but not continuously along the whole river, and listing the relation used to collect the riverbank polygons avoid creating these relations multiple times: the single reference by a single member in the waterway relation allows finding the riverbank relation immediately without having to look for it in riverbank polygons that are extremely far away).

Since long the role "riverbank" was used for this purpose (on long rivers), but only recently there was a new "waterbody" added (for smaller rivers) and documented here: this recent adition can be seen as a duplicate, except that duringf dicussions we also discovered that the role "canalway" was also used).

This is subject to discussion such as this one, to propose a standardisation scheme, discuss their advantages, vote for it, then apply it.

But for now there's no standard (except that the role "riverbank" is used since much longer time and for much longer rivers, but nothing was considered for making differences with "canalways". "Waterbody" is proposed now, but it could as well designate lakes, or meshes of drains and of irrigation conducts (that are not always inondated, but rivers also are not always inondated everywhere on their riverbanks, so the permanence of waters is not a distinctive attribute).

Note also that if there's still no standard for the member to include in waterway relations, the type of elements that are referenced by these members may also be closed polygons, or multipolygon relations collecting multiple closed ways, or sets of connected ways with various types (for example the terminal type of the river on the mouth on the sea may be a way that is also a segment of coastline, or one of these ways may be the limit of a dam or the central line of an highway; it could also be an administrative boundary, for exampel when the river has its local name changing, or another boundary for example the border of a lake crossed by the river...) — Verdy_p ^(talk) 13:17, 18 May 2015 (UTC)

The roles waterbody and riverbank are only rarly used. 0.14% (see [1]. I'm not happy that the definition page of the relation has been changed "documentation of use". Almost nobody is using it!

I think we should discuss the documentation of new roles first, before changing the definition page.

Some arguments against that roles again: Impossible to maintain You will never get complete waterways with it's waterbodys. Hard to work with: as soon as you add riverbanks to relations you can no longer download them. e.g The Amazonas has a neat small relation (without waterbodies), but if you add riverbanks it will become useless. Redundant: As soon as you have the centerline of the river, a computer can collect all waterareas that are intersected by the centerline. Destroying applications: Wikipedia shows the rivers in the map using the relations (WIWOSM). It just causes troubles if you add stuff that is not part of the river ... or not necessary to describe it. --Werner2101 (talk) 18:10, 19 May 2015 (UTC)

I am in favor of radically shortening the text describing this and mentioning it is neither approved nor recommended to add riverbanks as members of the relation. Also this page is not here to describe how to tag riverbanks especially as the text is misleading. RicoZ (talk) 15:12, 29 May 2015 (UTC)

I am really opposed to your claimed argument impossible be maintained. This is completely wrong, even if you do not participate to this maintenance effort on this part of the data. There are even tools developed specifically to help this task and to check that everything is still correct. The argument that it is used only a few rivers is balanced by the fact that we need these banks only for large rivers and most rivers are in fact tiny streams (or drains) for which there's no value to add aditional tagging of their surface.

There are not so many large rivers, by 0.14% over all rivers is still a good score for large rivers using this feature (even if there a many others for which we would benefit of more precise maps showing their effective surface: rivers are not just a thin line and where they are even larger than a building or a common street with only one or two ways, there's good value to map these water surfaces, in order to correctly locate things that are along the borders or for fluvial navigation to show obstacles or special areas in waters (harbours, sandbanks and rockbeds at low depth, specific equipements such as pumps, wrecks, protected areas for fishes, birds or plants...), or simply to have a better estimation of distances between borders (can you simply jump over it, or do you need a boat if you can't swim?).

Large rivers are also the longest, and to not all sections will be crossed by the "main_stream" or "side_stream" lines (this is frequently wrong when there are many arms and the correct number of side_streams is discussed when water level varies): you cannot model everything only with the linear model, but you still need to have knowledge of the whole surface and more local details on subsurfaces. In summary, these relations collecting many objects (whose cut are compeltely arbitrary and constitute in fact a single object), is definitely not redundant. This is not for the same purpose.

Now if you have many areas tagged as watter surface, it is difficult to determine to which river each one belongs (the basic "*_stream" lines won't give a correct answer in many places). We need a way to collect these joined surfaces, and a multipolygon relation is a perfect standard tool for that ! Let's just avoid creating many relations for the same river (to avoid duplicates), and this gives the role you'll insert in the waterway relation with a single member.

If your argument is that the data is just too much incomplete, then stop participating in OSM because nothing will ever be complete in OSM ! If this is because it is too difficult for you, then let others do the job. At the begining it was incorrectly judged that it would be impossible to have alsmot all buildings in OSM and even enough details to create realistic 3D rendering. Give more time to the project (which is still young), you'll get more data and more use of it. Mapping riverbanks has never been a stalled or regressing project, it continues growing normally.

Finally your statement about WIWOSM is simply wrong. May be Wikipedia currently has some limitations/bugs in limited cases but this is not a valid reason to stop. WIWOSM is also a work in progress, just like all other renderings (including Mapnik on OSM.org, or Mapquest): these renderings evolve when there are enough data which is actively maintained and that have also their own QA tools (this is the case of riverbanks, like there are tools for "landuse" and "natural" areas, even if most of them have very poor quality in terms of precision!) — Verdy_p ^(talk) 19:33, 29 May 2015 (UTC)

I wish there were good tools: debugging something as simple as a superflous natural=water on some parent relation is a nightmare. This tag gets inherited all the way down to the riverbanks multipolygons and floods islands. With all these parent relations it took me an hour to fix a single instance. Lake Geneva is still "disappearing" for some renderers because of some subtle error which people were trying to find for years:( RicoZ (talk) 11:04, 30 May 2015 (UTC)

Wrong: tags on relation must not be inherited down to member objects (this is an old way of doing things, when multipolygons were initially introduced). It is clear now that tags must be hold by the relation and not member objects when these members alone do not form the feature having this tag. But there are still meople that create multipolygons without any tag, asssuming that the tags will be collected from members. This is a bad thing: the goal in OSM is to place tags essentially on the parent object (the relation for all member objects, or the way for nodes), not on the isolated object that does not qualify alone for this tag because it is incomplete. — Verdy_p ^(talk) 00:08, 31 May 2015 (UTC)

What is the "right" parent object where to put waterway=riverbank or natural=water. There are chains of relations and people might accidentally put tags like natural=water to a Relation:waterway - I would expect this to cause havoc. RicoZ (talk) 12:33, 31 May 2015 (UTC)

Hmmm.... THat page documents a relation for type waterway, this is fully documented as being linear in nature. Even if there's a single member inside with a role "riverbank" I wondder how they can imagine adding natural=water" also on this relation, because of the presence of this member (which is neither main_stream nor side_stream) and much more doing this "by accident", unless they have absolutely not read any part of the doc. There's absolutely no tool doing this automatically by moving tags upward in one (or more) parent relations without looking at the role for which it was added and without loading at the same time the tags for the parent relation and seeing that it is effectively not a water surface but a linear feature. (if you still do that you are likely also merging riverbanks surfaces with other surfaces like landuses, river harbours, or various other features including linear bridge sections, without understanding what you are doing; someone will alert you and will cancel such completely wrong interpretation).

I've never seen any case where a relation was tags both as a linear waterway and a water/riverbank surface. Everything is possible though, but such accidents happen with almost all tags by those that don't know what they are doing and that should first learn by looking around (even without reading this doc). Chances are in fact that they don't understand at all how the editors work with relations (the most likely reason I think, fomr those using iD online for the first time, because iD is very difficult to use and very confusive with relations, much more that Potlatch 2 that has been unlisted too soon from the list of supported editors! You'll understand that I really don't like iD that has caused much more damages in the database than previously Potlatch 2 used by beginners).

JOSM is the only tool that can you can use reliably to work easily with rivers, and other large objects like boundaries (even for adding small objects such as turn restrictions (that correlate two ways and one node), iD is still unusable, but beginners could make the same havoc with iD by assigning highway tags to the node of the restriction relation... This cannot still happen by accident in iD because it is very difficult there to select the parent relation to modify in iD...

If this ever happens, this will still not break the linear feature itself. It is however much more likely that existing riverbanks will be possibly broken (but not because of modifications of waterways relations themselves.

Beginners can do a lot of havoc in the database with iD, but not just on this relation. iD is just made for working on small isolated objects that are not dependent from others, or just for adding some name tags or filling addresses for POIs, seriously you can(t use it to map rivers and any large object. — Verdy_p ^(talk) 21:52, 31 May 2015 (UTC)

Old Courses of the waterway?

Does anyone think it's a good idea/support the idea of having a member which is the old course of a waterway. Not necessarily every course which has ever existed, but say some significant historical courses, especially when the waterway has been artificially altered. For example the course of the waterway prior to canalisation. It could be a member under 'waterway=oldcourse'.

I think this falls into the domain of historical mapping, which many consider beyond the scope of OSM. So if you want to do this, proceed with caution so you don't step on people's toes. Perhaps the Open Historical Map would be more welcoming here? --Tordanik 10:28, 15 December 2015 (UTC)

Add weirs to waterway

Should they be added to waterways? --TBKMrt (talk) 18:15, 7 November 2017 (UTC)

I don't think weirs should be added to waterway relations. Once they are mapped (Tag:waterway=weir), they can anyway be extracted programmatically by looking for weirs that intersect the waterway relation, e.g. all weirs on the river Rhein:

[out:json][timeout:10];
relation["name"="Rhein"]["type"="waterway"];
way(r);
node(w)->.a;
(
 node.a[waterway=weir];
 way(bn.a)[waterway=weir];
);
out body;
>;
out skel qt;

--JoeG (talk) 02:14, 9 November 2017 (UTC)

Sort order?

This line was just added:

"The sort order should begin with the spring or the uppermost member."

Can someone confirm if this is, in fact, common practice? I have not bothered to use a particular order, whether source first and mouth last, or the opposite, as long as the ways are in the correct order. I suspec that many waterway relations are not even sorted, since this can be easily changed by mistake, and is not obvious. --Jeisenbe (talk) 08:58, 26 February 2020 (UTC)

Source for sort order is here : https://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Waterway#members, first row in table.----Hb 14:18, 26 February 2020 (UTC)

That link is from an 8 year old discussion on a proposal talk page, and did not get into the voted proposal. Could you please tell me if all of the waterways in the places that you have checked are already sorted in this way? Or are you proposing that this is a good idea, even though it is not actually the standard practice yet? --Jeisenbe (talk) 00:44, 27 February 2020 (UTC)

As the discussed sentence was already replaced, the merely rhetorical bloat above is obsolete. What is needed is an answer to the open question, if the spring (small beginning) or the mouth of a river (big end) should be first in the sort order of its parts. ----Hb 02:28, 27 February 2020 (UTC)

I'm not trying to be rhetorical, I really want to know how other mappers are doing this. Since I map in Indonesia (where there are very few other mappers) and the USA (where all the waterways were imported), I don't have a clear idea if this is common practice in other countries. It certainly makes sense, now that you mention it, for the waterway relation to start at the spring or source as the first member, and end at the mouth or confluence, and I will probably try to remember this when I edit relations. But I'm not sure if it is 1) necessary (probably database users can handle relations which are reversed?) or 2) standard practice already. --Jeisenbe (talk) 06:32, 27 February 2020 (UTC)

Suggestion to add all local names?

The text says: "When a river gets multiple names (because it passes in multiple language regions), use all different names in the name tag, ordered from source to mouth, and split by hyphens."

That would mean that the relation for a long river like the Danube could have a half-dozen names separated by hypens. Is this actually done in practice? Is it actually helpful?

The individual local ways which make up the river should have the local name in each segment, so that should be sufficient to make it clear what the river is named in each place. --Jeisenbe (talk) 07:30, 25 January 2021 (UTC)

Ideally, a Danube relation would have tags like name:de=Donau, name:hu=Duna, and so on for each native language along its course. But something has to be entered for name=* on the relation itself (leaving it empty would just look ugly), and the English name alone won't cut it. -happy5214 11:02, 6 November 2021 (UTC)

I don't like the specified separator to put between names: "hyphens". I'm pretty sure that some rivers, in some languages, have a hyphenated name. I would suggest separating the names with a semicolon (like we do for multi-valued tags). Anyone disagree? Fred73000 (talk) 13:41, 8 July 2022 (UTC)

Semicolon makes more sense to me, too, yeah. Go ahead and change that. JesseFW (talk) 14:08, 8 July 2022 (UTC)

The Wiki is supposed to reflect mapping practices, not dictate them (except for CoC pages of course). I haven't seen semicolon-separated names for rivers anywhere and I've mapped more than a few, so I suggest proposing this recommendation more formally to get broader community input and support. 501ghost (talk) 15:34, 8 July 2022 (UTC)

according to overpass-turbo, there are currently 1201 waterway relations with a name with a hyphen, example: https://www.openstreetmap.org/relation/178418. And 66948 waterway ways with a name with a hyphen, not always because that's the name of the river but because it's sometimes said that this waterway goes from such place to such place. Example : https://www.openstreetmap.org/way/8086488. 200 waterway ways with a semicolon, not clear why, I suspect mostly errors (many of these names have a semicolon at the end of the name or 2 times the same name separated by a semicolon). And 0 relation has a name with a semicolon. Fred73000 (talk) 20:09, 10 July 2022 (UTC)

"66948 waterway ways with a name with a hyphen, not always because that's the name of the river but because it's sometimes said that this waterway goes from such place to such place." - Sometimes that is the name, like here: https://www.openstreetmap.org/relation/12230517 . That has nothing to do with the river passing through multiple language regions. For features in/through multiple language regions, a slash (the / ) is already in use. This is done for multilingual countries like Switzerland and for some water bodies such as the strait of Dover. That said, this mapping practice is also being questioned, as Schweiz/Suisse/Svizzera/Svizra or Rhein/Rhin/Rijn is technically not a name, but a collection of several versions of the name. That's why I'm saying that this discussion needs to be had on a more popular disucssion platform than this Wiki talk page. --501ghost (talk) 02:00, 12 July 2022 (UTC)

Yes, you are right, some people use the "/" character (4328 waterway ways which means 1075 different waterways + 252 waterway relations). And nobody the ";" (zero for the relation waterway, 200 waterway ways which means 110 different waterways). I was thinking of the semicolon because it is the official separator when there are seveval values (see https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator). But I'm ok with the "/" character because, even if a waterway relation name never appears on a map, the waterway way name appears and "/" is more common. Best regards. ~~

Distributaries

How should distributaries (e.g. at river deltas) be handled in the relation? Some rivers, especially at deltas, have distributaries which are notable in their own right (such as the Atchafalaya River in Louisiana, a distributary of the Mississippi; and the many named channels of the Rhine Delta). The current de facto spec only allows for tributary waterway relations to be included as members. -happy5214 10:48, 6 November 2021 (UTC)

• My understanding is that it would be best to name each distributary individually identically to how one would name a river, then combine all segments into a waterway relation with the role "main_stream" and then include only the distributary relations (without the segments themselves) into a parent river or distributary relation with the presumably role "distributary" which is not yet established. Moreover it would be good to have separate roles for main and secondary distributaries. --VileGecko (talk) 09:05, 14 April 2022 (UTC)

Tributary role

JesseFW, you added tributary role here, mentioning that it "has advantages and disadvantages" (Special:Diff/1943783). Were these advantages and disadvantages discussed somewhere? A waterway relation generally is for an individual river, its attributes such as name, length and ref generally don't apply to tributaries. Member relations with this role confusingly suggest otherwise. I think use of such role should be discourage. If it's really necessary to collect tirbutaries of a waterway, then alternatively some additonal relation for a basin or river network could be created, perhaps. Pikse 17:54, 9 January 2022 (UTC)

I agree that mapping tributaries should be discouraged, simply because they go against the One feature, one OSM element policy. I would even go as far as proposing to phase this practice out, but that requires convincing a few users like Tilia_J who are enthousiastically adding them to existing waterway relations. 501ghost (talk) 20:19, 9 January 2022 (UTC)

I don't remember where I saw the previous discussion of the `tributary` role. I don't disagree with the concerns you both have raised about it, and I'd support you clarifying the text on the page to explain the downsides more clearly. JesseFW (talk) 01:16, 10 January 2022 (UTC)

(This Wikipedian sees we don't indent here.) The new "network" relation that Pikse proposes would IMO only work within the OSM relation model as a relation of one waterway (using its relation) and its tributaries/distributaries (via their waterway or "basin"/"network" relations). I'm not familiar with where this concept of implied relational inheritance is mentioned on-wiki, if someone can point me to that. (And as an aside, including the length in the current waterway relation is arguably pointless, as it ought to be derived from the main_stream way lengths.) -happy5214 15:38, 6 March 2022 (UTC)

I didn't necessarily propose a new type of relation. I only implied that some cleaner solution should be found if it's necessary to gather tributaries of a river. I don't quite get what you mean by "relational inheritance". Members in separate basin or river network relation could be other relations, just like some relation members that currently have tributary role within waterway relation.

Well, lenght tag is currently documented here. But more importantly, name and identifiers of a river also generally don't apply to tributaries of given river. Pikse 17:40, 16 March 2022 (UTC)

@Pikse: "Relational inheritance" was a reference to the following part of your original post: "[...] its attributes such as name, length and ref generally don't apply to tributaries. Member relations with this role confusingly suggest otherwise[,]" which to me seemed to imply that you felt the attributes were being inherited by the tributary waterway relations by virtue of being included as members of another waterway relation with the tributary role.

Would "envision" be a better word than "propose" in reference to the basin/watershed relation? I didn't mean to imply that you were making a formal proposal (I guess the word "propose" has that kind of connotation here? I'm not particularly familiar with the tag proposal process.), but were rather just positing the idea. -happy5214 06:46, 17 March 2022 (UTC)

To illustrate what I mean, take for example relation 3541310. This relation is/was for a river named "Peetri jõgi". This name is not used for another river (nor any other tributary) that was recently added into first relation using tributary role. These are two separate rivers, one is not part of another, one just flows into another. A river without its tributaries is an individual geographical feature and an individual geographic feature is generally denoted by individual OSM feature. While relation 3541310 per its members is currently for a group of different geographical objects (multiple rivers). Pikse 17:49, 17 March 2022 (UTC)

---

Krako73, you wrote new description for tributary role. You wrote about "small streams with no names", claiming that "we can consider these streams as part of the watercourse itself". I don't think this is an adequate generalization. By including an unnamed stream in a relation of a larger named watercourse you basically make this unnamed stream into a named object.

I suppose in some cases it is possible that certain smaller streams branching off of the main stream are considered as parts of the same watercourse as the main stream. This however should be verified using some reliable source in every individual case. Also it's probably better not use tributary role for these parts as this will likely lead us back to situation where people misleadingly add other larger tributaries with different names as parts of the same watercourse, too. Pikse 07:09, 1 June 2023 (UTC)

Thanks for keeping an eye on this, Pikse. I agree with your concerns about Krako73's addition, and encourage you to edit the page to address them. JesseFW (talk) 12:01, 1 June 2023 (UTC)

The previous text said "no tributary role at all" : I could be agree with that because a waterway relation should be a unique watercourse, see the main page. The problem is that, in taginfo : https://taginfo.openstreetmap.org/relations/waterway#roles, there are 24 000 ways/relations with this role. Osm is the result of mappers : if so many mappers are using this role, it means that we have to find why and try to explain to others when to use this role. And what I found is : when a watercourse has a name and several ways, some mappers add these ways in one relation (sometimes with the tag destination) and nothing more, some others add the relation as a tributary of another river/stream relation. When the watercourse is very short (only one way) and has no name, some do nothing, some others add these small watercourses as a tributary of a bigger river. My changes on the main page of the wiki try to explain that.

In fact the problem is bigger than the 24 000 roles = some mappers, maybe because they have read the old version of the wiki and saw that they should not use the role tributary, use the role side_stream or an empty role on the tributary watercourses. If they now see in the wiki that the role tributary is allowed, they will stop to put a wrong role on the members in the relation and osm database will be better.

The word tributary is clear = it is a tributary so it is not the same watercourse, the ways of the watercourse should have the role main_stream or side_stream. I also changed this part of the main page = before my changes, a main_stream could have a role main_stream or an empty role. Empty is a bad role because we don't know if they forgot to add roles, if the relation should be a mix of main/side/tributary roles, if the waterway is a true waterway relation or should be a watershed, or if the empty roles are truly main_stream roles. I think to tell to mappers "add a role on every members of the relation" will improve the waterway relations and will stop to hide tributary members. I don't know how many tributary members we have currently in waterway relations but clearly much more than the 24 000 roles tributary. I hope that my changes on the wiki page will slowly improve what is really in osm. Best regards. Krako73 (talk) 18:42, 3 June 2023 (UTC)

As you now point out, different people have used tributary role differently. Which is expected as for a long time it was used without this wiki page mentioning it at all. It hasn't been used only for short unnamed tributaries as you suggested in the list of roles. This is also evident in your example relation that in addition to smaller unnamed ways includes a couple of relations with different names as tributaries. Therefore I don't see a good reason or good way to derive role description from existing uses. The fact that people have used a role does not necessarily mean that it should be used in these various manners nor that its usage should be encouraged.

I don't think it matters here that the meaning of word "tributary" is clear. First and foremost a waterway relation is for a unique watercourse and the inclusion of tributaries conflicts this purpose. As a rule an individual geographic object is supposed to be represented by an individual OSM element, and this individual OSM element no longer exists if a waterway relation is repurposed to be a catch-all for related stuff (including tributaries).

I think side_stream role is fine for small river sections such as old river bends that still connect with the main stream on one end (if in sources it is considered as part of the same watercourse of course). But inclusion of larger tributaries in a relation of a unique watercourse just messes up the data as far as I can see. It shouldn't be necessary to filter out some arbitrary relation parts to obtain this unique geographical object.

As for the removal of "empty" role, I think it'd be better to discuss this separately. I'll post about it another section below. Pikse 08:15, 4 June 2023 (UTC)

One feature, one OSM element and waterway relations

Waterway relations are unable to replace tagging using ways, and they are additional object. How it deals with One feature, one OSM element? Is it an exception to this rule? Mateusz Konieczny (talk) 20:44, 13 February 2022 (UTC)

As I understand it, the waterway relation is the single OSM element that represents the whole of the (named) waterway, as opposed to the individual ways (which have to be broken up to represent such things as culverts (most commonly), differing widths, and other aspects of specific sections of a waterway). So I don't think this is an exception. JesseFW (talk) 22:46, 13 February 2022 (UTC)

The practice of including a name=* on the individual ways is, technically, redundant, but helpful in confirming that the way is actually part of the larger waterway, and allows data users who merely want to display that name to avoid having to pay attention to the relation. JesseFW (talk) 22:49, 13 February 2022 (UTC)

Additionally, the name may be different if the waterway passes different countries with different languages. --KrilleOSM (talk) 23:49, 13 February 2022 (UTC)

name=* is redundant solely in cases where waterway is not changing its primary name across its course and is named along its entire way. So data consumers need to support it anyway, and it is worth mapping in this way to avoid pointless confusion Mateusz Konieczny (talk) 17:27, 14 February 2022 (UTC)

distance or length?

Which tag should be used to denote the length of a waterway: distance=* or length=*? maro21 23:40, 27 April 2022 (UTC)

Neither, length of a waterway is already included by mapping it as a line. For external estimates - add wikipedia=* + wikidata=* Mateusz Konieczny (talk) 06:16, 28 April 2022 (UTC)

Where is it included? I'm asking because I don't know whether treat waterway the same as route and add distance in kilometers or length in meters. maro21 22:48, 30 April 2022 (UTC)

OSM is geographical database. When you map node its location is recorded, there is no need to tag its latitude/longitude. When you map area, its geometry is inherently included there is no need to map an area. When you map line its length is already included (distance between successive nodes). In case of waterway relation adding length of ways in relation with role which is empty or main_stream gives you waterway length. There is no need to add it as a tag Mateusz Konieczny (talk) 06:45, 1 May 2022 (UTC)

My question was "WHERE is length included?" maro21 10:37, 1 May 2022 (UTC)

Resolved: My question came from the fact that I'd seen the "distance" tag on the relation of one large river, but after querying overpass I see that "length" dominates - 174:20, and "distance" really should only be used on route relations. maro21 10:37, 1 May 2022 (UTC)

Empty role

In last revision an empty (none) role was removed from list of roles. Was there a prior discussion about it somewhere? The page now claims that due to missing role it is impossible to know which role is meant. However so far an empty role was documented as an equivalent to main_stream. Based on this existing usages of empty role seem clear to me. I doubt there is a good reason to make things more complicated to change all existing empty roles. I suppose empty role as main_stream equivalent has been considered fine because other roles are less common and often a waterway relation includes only main stream segments. Of course there may be usages of empty roles around that are actually not for main stream segments but wrong roles being used can happen both with and without empty role. Pikse 08:15, 4 June 2023 (UTC)

Yes, we should still document the empty role as equivalent to main_stream. JesseFW (talk) 12:16, 4 June 2023 (UTC)

For this relation with empty roles https://www.openstreetmap.org/relation/5237609/history (see version 13), it was easy and I fixed it with the correct type. But what do you think about this waterway relation with empty roles : https://www.openstreetmap.org/relation/12378325 ? Is it a waterway relation or should the type be changed ? If it is one, do you think that all roles are main_stream ? Which ones are not and what should be the correct roles ? Do you really think that the 35848 relations with at least one empty roles means that these are waterway relations with main_stream roles ? Krako73 (talk) 16:01, 12 June 2023 (UTC)

This example does seem suspicious but I don't think that the empty role per se is the problem there. If this data isn't verifiable then even if we avoided empty role we still wouldn't know what other role would be correct to use. Pikse 06:22, 16 June 2023 (UTC)