For example, if I collect a number of Ways in a Relation and add a combination of access-related Keys to it, will those also apply to the individual Ways?
1 Like
In the database? No.
3rd-party might consider the information in the relation and apply them to their members.
1 Like
Thank you.
I have a system of ways with three access Keys each (access=private & bicycle=no & foot=yes), and hoped I could implement it by just making each of them part of a Relation that has those Keys.
relations are typically not thought of a “collection” of something. This should be done by other means of tagging.
“relation” - as the word also says - describes the relation of different objects on one another. E.g. you have a polygon and there are other which are holes. Or you have way and turn vias which may or may not be allowed to use.
See this warning at the top
https://wiki.openstreetmap.org/wiki/Relation:collection
Flo
I knew that already. My mistake was reading the line “Most tags can be added once to the waterway relation instead of being added and maintained on each segment” on /wiki/Relation:waterway, and thinking it applied to all tags on all relations.
1 Like
With some relation types such as multipolygon, multilinestring, and boundary, all the tags go on the relation, leaving the member ways with nothing except perhaps source=*. This is because the relation as a whole is the only feature being mapped. (That said, sometimes the member ways do have other tags, because they represent unrelated features that share the same geometry by coincidence.)
Other relation types like route and restriction are additive; that is, each member way still needs tags that represent the physical feature being bound together by the more abstract relation. A turn restriction is meaningless without information about the distinct roads that you can’t turn from and to. On these relation types, tags about the relation sometimes appear on the member ways redundantly, for backwards compatibility only.
On its face, a waterway relation represents a waterway, the same thing being modeled as multiple ways, but some mappers include other things like tributaries and such, which turns it into a somewhat broader concept. Even if you only include the main stream in the waterway relation, it’s normal and expected to redundantly tag the member ways with basic tags such as waterway=* and name=*. Identifier-like tags such as wikidata=* tend to go only on the relation, because, when possible, tagging a single element is more compatible with the use cases for these identifiers.
5 Likes
Huh, I guess Relations are even more diverse than Ways, then. And those can be simple (e.g. Fence), directed (e.g. Stream), sided (e.g. Cliff) or closed (Area).
The wiki page doesn’t mention anything about applying tags to its members, though, and it’s not even listed when editing on OSM. And Relation:site doesn’t seem to work that way either.
I’m starting to suspect that Multipolygon and routes are the only actively supported relation types…
Add “boundary” to that list and for rendering, you’re about right, actually. Routers are also interested in type=restriction as well
For completeness, taginfo has the list, and for each type you can look at the projects that advertise that they consume it.
The other one that has some rendering support is type=site (more than listed at taginfo) - OpenCampingMap and Open Infrastructure Map do support that.
1 Like
This is a somewhat rare relation type. As the documentation explains, it’s similar to a multipolygon in concept.
A number of data consumers also make use of route relations. For example, among the layers featured on osm.org, OpenCycleMap highlights cycling routes based on cycling route relations, and among the routers featured on the site, Valhalla and OSRM use route relations to obtain cardinal directions associated with the route. On mobile platforms, route relations influence the display of route markers (route shields) in OsmAnd and Organic Maps and also power some applications’ public transit routing capabilities.