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 . 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 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)