Proposal talk:Rivers Classification
General
Seems to be simple, without complexity issues, fixing problems appearing in Proposed features/Waterways classification Mateusz Konieczny (talk) 20:36, 1 September 2017 (UTC)
Is entire river supposed to be mapped with the same importance tag? Not that at least some major rivers start as small stream - is it also supposed to be mapped as very important river? Mateusz Konieczny (talk) 15:48, 2 September 2017 (UTC)
- Yes, importance is an attribute of the entire river. If you draw on a map just a part of the river where it is wider that some average, that would puzzle a user, especially when they know the river is longer. --Zverik (talk) 18:09, 2 September 2017 (UTC)
Relations
But these relations are mapped inconsistently, and even if you could maintain a hundred relations for major rivers, I doubt all the big rivers would have their relations mapped in at least a decade, without breaking any of these.
May you please give me an example of a "major" river with a broken relation?--Ethylisocyanat (talk) 21:28, 2 September 2017 (UTC)
- No, I can not. For that we at least need to have a list of relations for major rivers, and we don't. To answer yout question, I would need to go through all handred rivers and check their relations: while the question took you a minute, I would need to spend several hours to answer it. I know of a few major road relations that are constantly broken, why that won't be the case for river relations? --Zverik (talk) 07:01, 3 September 2017 (UTC)
- Actually there exists such QA tool, so we can check these relations quite easy: http://www.h-renrew.de/h/osm/osmchecks/07_watershed/index.html --Kocio (talk) 07:17, 3 September 2017 (UTC)
I'm in favour of this proposal if it is applied only to waterway relations. The classification seems crude but effective. But if it's meant to be applied to the whole river, then it should be applied to the relation - that's what it's for. Adding ways to a relation and then adding a tag is much easier than trying to ensure that all ways are tagged separately. Yes, there are some broken relations (e.g. which describe all rivers in a catchment rather than a single river), but as someone who has specifically been working on this, I'd say you'd be surprised by current progress. The number of relations is already in the 10s of thousands, not 100s. It's safe to assume that rivers without relations are either small, or would have a relation created very soon to ensure they are rendered. I would also add that at least major rivers should have a wikipedia/wikidata tag, reflecting their importance. -- JoeG (talk) 07:58, 3 September 2017 (UTC)
- Hi Joe, thanks for the idea about relations. I have thought about it, and I am more in favour of tagging the ways still. Because waterway relations contain more than just ways forming the river, they also contain side-streams. That is one more way these relations could be broken. Also it makes harder for data consumers to process relations to find the value of the tag. But of course, waterway relations should also have the river tag. --Zverik (talk) 10:15, 16 October 2017 (UTC)
- Thanks for the response. Just to clarify, I wouldn't say that waterway relations with side-streams are broken. It is quite common for rivers to split into several channels, all of which are still part of the same river. Marking a member as a side-stream is yet another marker of importance available to the data consumer - do you want all branches of a major river, or just the main one? --JoeG (talk) 05:50, 18 October 2017 (UTC)
- Hi Joe, thanks for the idea about relations. I have thought about it, and I am more in favour of tagging the ways still. Because waterway relations contain more than just ways forming the river, they also contain side-streams. That is one more way these relations could be broken. Also it makes harder for data consumers to process relations to find the value of the tag. But of course, waterway relations should also have the river tag. --Zverik (talk) 10:15, 16 October 2017 (UTC)
Voting
It seems that there are no more comments for a long time. Do you plan to move this proposal towards voting phase or it still needs some work? -- Kocio (talk) 15:49, 15 October 2017 (UTC)
- Thanks for reminding! I'll add a section about tagging river relations if present, and will start voting — today or tomorrow. --Zverik (talk) 08:29, 16 October 2017 (UTC)
An overall review
I never thought this would actually be put up to a vote but since it is let me just summarize quickly why this is a very bad idea. I have not brought up these points before because i consider them obvious but apparently they are either not or there are major interests that for some seem to supersede these issues:
- The proposal suggests introducing a locally non-verifiable importance tag for rivers with the expressed sole purpose of steering rendering in zoomable mercator web maps. As such it is preemptive tagging for the renderer (http://blog.imagico.de/social-engineering-in-openstreetmap/) in purity.
- The pro forma verifiable criteria for the three level classification system are practically not verifiable and the proposal explicity states that they are not binding. Newly introducing such a system would deliberately ignore the lessons learned from past problems with originally vague classification systems like for roads and populated places.
- If length and drainage basin size of rivers were verifiable quantities it would make much more sense to tag them directly instead of calculating a combined discrete three level score.
- Length and drainage basin size of rivers are quantities that - where stated - almost always come from databases which are not open data so suggesting diligent and systematic mapping of these tags is an invitation to database rights violations.
- Neither the length nor the drainage basin size are well defined so neither of them is verifiable even with unlimited ressources. Navigable rivers often have an official length measurement (https://de.wikipedia.org/wiki/Kilometrierung) but the length of a river ultimately is a function of the scale you measure at - not unlike the coastline length (https://en.wikipedia.org/wiki/How_Long_Is_the_Coast_of_Britain%3F_Statistical_Self-Similarity_and_Fractional_Dimension) but with a very different function of scale dependency of course. Drainage basin size is not well defined either, especially in dry regions and areas with Karst geology (like the question if the Kalahari basin belongs to the Orange River drainage, the western tributaries of the Nile in Sudan or Hulun Lake draining into the Amur or not).
- The proposed classification system is orthogonal to the existing river/stream classification, meaning there can be (and are) waterways that would need to be tagged waterway=stream + river=major under these rules making them highly confusing for mappers. This relationship is misrepresented by the proposal.
- Tagging values which are by definition a property of an entire river to the individual ways is a waste of time and a nightmare in data consistency.
--Imagico (talk) 10:44, 16 October 2017 (UTC)
- The proposal starts with a word "subjective", and it indicates that the numbers provided are merely pointers, not exact limits.
- We have tons of locally non-verifiable tags, including highway=* (in some countries) and place=*. The page Tagging for the renderer is not applicable here, because this is not incorrect tagging, this is helping many renderers. Like adding a layer=-1 for tunnels: a renderer in many cases can calculate it by itself, but why not help it. It is also unlike is_in: the value of the tag in many cases cannot be automatically determined by other data in OSM, and if it can, it is quite hard (and I'm citing the proposal here).
- This proposal actually builds on lessons learned from highway and place classification. It suggests numeric limits and offers regional adjustments. What else can it do? The alternative way would be a numeric classification based on some built-in parameters — but that would be even more locally unverifiable and redundant.
- Length is already mapped, drainage basin is not, but that is not the issue. These values change quite often, values are not easy to find, and nobody here would commit to updating these regularly. So I am not proposing to add these.
- The proposal clearly says that river=* tag should go only on waterway=river tagged ways. Streams are excluded from this, even if they are parts of a major river. In some countries stream tagging is not based on "a person can jump over it" rule.
- As you can see by this moment, the proposed river classification tries to be region-independent and context-independent. That what prompted some of the decisions. Calculating this field from context is nearly impossible, that's why I propose a manually-checked partly subjective classification.
- Tagging a lot of things, including highway statuses, is a nightmare in data consistency, as I have long observed and I'm sure you did too. "Waste of time" is a proposition nobody can dispel, so I leave it to you. I don't require you to add these tags, so I'm not sure how it would waste your time.
- Thanks for the reply but none of your comments actually addresses any of the issues i pointed out. You confirm many of my points of critique (in particular that the proposed tagging is subjective and non-verifiable and that the potentially verifiable criteria are just non-binding pointers) but you dismiss these problems since as i read it you essentially emphasize that you think the interest in having this tagged (based on the wishful thinking that use of the tags is actually going to meet any requirement of usefulness) supersedes any of the problems i mentioned and warrants ignoring the core principle of verifiability. And you might want to read the mentioned link on http://blog.imagico.de/social-engineering-in-openstreetmap/ regarding the concept of preemptive tagging for the renderer. And waste of time refers to tagging the individual ways although by definition this tag would always be the same for all members of a waterway relation.
- Also see the comment Frederik made on the tagging ML on August 29:
- Subjective tagging has no place in OSM because it is not verifiable; we don't want that and we shouldn't let people think we do.