New tagging scheme for portages and rapids?

General talk
1

I noticed, via some some changesets, that there has been a significant change in how canoe and whitewater related features are being tagged.

There are some new tags, rapids which has been used to replace whitewater:section_grade and whitewater:rapid_grade, portage replacing canoe=portage and waterway=portage, a waterway:name tag, and probably others.

It seems user @quincylvania is the driving force behind this initiative, retagging most of the world over the past few weeks, writing wiki pages documenting the new tags, etc.

Since the original whitewater project has been stagnant for a long time, it is perhaps time to have a community discussion about the way forward.

1 Like
2

Hi all! I’ll say up front that I’m happy to add back any tags I removed if people are still using them or want more time to discuss. I do want to change tagging patterns for the better but I don’t want to mess up anyone’s work.

For reference, I’ve been writing wiki pages to document the tags I’m using:

  • https://wiki.openstreetmap.org/wiki/Draft:Water_trails
  • https://wiki.openstreetmap.org/wiki/Key:portage
  • https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dlink
  • https://wiki.openstreetmap.org/wiki/Key:rapids
  • https://wiki.openstreetmap.org/wiki/Key:waterway:name
  • https://wiki.openstreetmap.org/wiki/Key:waterbody:name
  • https://wiki.openstreetmap.org/wiki/Key:sea_kayak

Basically I’ve been trying to improve canoe and kayak feature tagging in OSM in order to encourage mapping and usage.

To go into some detail about whitewater tagging specifically, the historic advice is pretty old and doesn’t really fit with modern OSM tagging patterns. It tries to namespace all relevant data categorically under whitewater, which leads to duplication like name=Thing + whitewater:rapid_name=Thing on the same object. It also has duplicate tags like whitewater:rapid_name and whitewater:section_name, with the difference poorly explained and mappers using them interchangeably. Plus some mappers have used a third tag, whitewater:name. The same is true for whitewater:section_grade, whitewater:rapid_grade, and whitewater:grade.

People want to map rapids both as individual features and as attributes on rivers. Many people have used whitewater=rapid (often misspelled whitewater=rapids) for both of these. Note that not all classes of rapids are even considered whitewater. I argue that whitewater= doesn’t need to be a primary type tag, and individual features would be better tagged with the well-established waterway=rapids (on lines and nodes) and water=rapids (on areas). Whether any given rapids feature even has a primary type tag in OSM has been a gamble, with some mappers just putting whitewater:rapid_grade=unknown or whitewater:rapid_name=Something
on a way or node and nothing else, and not trigging any validator warnings.

Given the critical importance of rapids data to boat safety, I think we need to standardize on a single unambiguous rapids tag that is both easy to use and to process. I’ve been starting to adopt rapids= for this. I have not done widespread re-tagging of whitewater:section_grade= to rapids= on river segments, but I have done some re-tagging when doing other improvements, like moving whitewater:rapid_name= to name= on individual rapids.

4 Likes
3

The whitewater: namespace has the advantage to be completely orthogonal to other tags, and thus the ones who know (paddlers) can map specificities of the rivers related to water sports other won’t know.
Leaving rapid=* to Joe mapper telling “here are white water”.
One caveat with your change is how would you name a feature known to kayaker (a rock, à particular stretch of a river
) that is not a rapid?
That being said, rivers are probably best described in topo books or live forums than in OSM.

4

Thanks Quincy. Whitewater tagging has long been one of those “this isn’t really how OSM tagging should work” niches (see also OpenSeaMap). This is a great improvement.

Waterway tagging is relevant for all river users. There is no hard-and-fast division between “whitewater” and “other navigation”. Namespacing it was a bad move.

2 Likes
5

I wondered a bit about this sort of thing while walking along the Leeds and Liverpool canal. There are lots of signs for the Desmond Family Canoe Trail** but it wasn’t immediately obvious what was mappable. “White water” it most certainly is not.

On reflection, perhaps the portages make sense to be mapped, and presumably something (not sure what) that identifies put-ins etc.

** named after that Richard Desmond. See also this former “Manchester Guardian” article with a comedy misspelling of “Burnley”.

1 Like
6

Yes, there are similar portages on the Monmouthshire & Brecon Canal. It’s often done as part of a loop with the parallel River Usk. The Mon & Brec is decidedly not whitewater, but it would be daft to tag infrastructure on the Mon & Brec with one tag and the exact equivalent on the Usk 300m away as something else.

canoe=put_in seems to be moderately well used.

1 Like
7

Not quite dead, but a niche tag for sure.

8

Until a new tagging scheme is settled I would suggest a revert of the already done changsets since information is removed. For example:

(Away with rapid-tags is replaed by a single node not showing the extent of the rapid)

It is very tiresome to manually add a lot of features that later gets destroyd by a knight in shining armour thinking that his logic is better than someone elses.
Not intended as an insult to quincylvania, but this phenomen is way too common.

I agree that the tagging of rapids can be improved, but until it is agreed how to do it, no information shall be removed/destroyed.

9

@AndersAndersson Thanks for bringing this up since it’s another data issue with rapids tagging patterns worth explaining.

For clarity, I’ve been doing a lot of whitewater cleanup and only in a couple instances did I replace a waterway=rapids line with a node + attribute tags on the river segment. I did not destroy any data, just moved it. Let me illustrate:

It’s nice to map individual rapids as distinct point of interest features. This helps with rendering and geocoding. Rapids have been mapped as individual nodes, lines, and areas. Nodes and areas work well, but lines have been mapped inconsistently.

Some mappers draw waterway=rapids lines laterally along the crest of a rapid:

Some mappers draw waterway=rapids lines longitudinally along the flow of the river. These tend to overlap with waterway=river features.

Sometimes they are glued together, which is difficult to maintain:

Sometimes they replace the river entirely, which is unexpected and removes valuable information like the name of the river:

If we can’t be sure if a given waterway=rapids line is mapped across the river or along the river, then we can’t do things like measure a rapid’s length or render arrows on the downstream side. It would be much better to pick one or the other as standard.

Really, lateral and longitudinal rapids are actually two different types of features. The first is an individual “rapid” where waters flow over a drop. The second is a section of swiftly-moving river that may have a distinct name. As such, I’ve started moving the tags for rapids mapped longitudinally to the waterway=river segment, which has the relevant geometry. The rapid POI itself can then be mapped as a waterway=rapids node, or ideally as a natural=water + water=rapids area. You can still query the river tags if you want to know the length of a specific rapid.

Since no data consumers appear to be relying on the prior tagging pattern, I didn’t feel the need to ask permission before making the change.

1 Like
10

This kind of systematic and remote tagging is certainly worth a discussion beforehand. These are low usage tags, but I’m sure contributors mapping those will bother.

2 Likes
11

OsmAND and OpenSeaMap used these tags in some fashion.

12

I’ve been slowly building out a padding map map using OSM data for a while, and very much agree that the current state of rapids on the map makes the data really difficult to use.

I’d really like to render rapids in a similar style to the USGS — using either a perpendicular bar across a stream line, or a directional pattern drawn in a water area.

Rapids mapped as nodes and areas are pretty reasonable today, but as @quincylvania pointed out, rapids mapped as linear ways can be mapped in so many different ways, the amount of code necessary to determine what it’s representing and how to render it simply isn’t worth it. Currently I just take the point at the center of the line and show an icon.

I’d support any sort of effort to make these consistent, or just outright discouraging mapping rapids as linear ways.

1 Like
13

Another data consumer: WaterwayMap.org has a canoe map. I don’t know anything about canoeing. I added it on request. @quincylvania has been providing useful feedback, (incl. the portage tag).

1 Like
14

So happen to be mapping around Lago di Ridracoli and noticed canoes, lots of them, for rent to be suspected.

image

Non of the feeder streams to the dammed reservoir lake were mapped thru, the sum exit turning that into a river. Think with standing at 898 km the 1000 might get scaled after the connections have been created.

:grin:

image
image351×545 65.1 KB

15

As I wrote in the changeset, I will appologise and crawl out of this thread with my tail between my legs, since my critisism was based on a missunderstanding. You did not replace a rapid way with a node. I just missed what you did in that and another changeset.

I look forward to a good and logical way to tag both canoe and rapids in the future.

2 Likes