Does it make sense to use a relation to group sections of a road that each have unique tags together?

Say you have a section of a road that has parking restrictions, then another section of that road that doesn’t. Both sections are part of the same road just at different positions. It feels silly to tag each section with the road’s name and surface and condition when it’s common for each segment. The only difference would be the restrictions on each segment.

I was thinking that one could turn the road segments into a relation with the main relation containing the road name and surface etc, and the components would each have their respective conditions. If this is appropriate, what relation would I use to group them? If it is inappropriate, why?

1 Like

No data consumer will parse that. Relations are sui generis constructs, they’re not a method of bouncing shared tags down onto ways.

6 Likes

I’ll add that tagging on ways is the easy thing in OSM, and can be mastered very quickly by any new user. Relations are a bit more complicated : keep it simple !

4 Likes

You still need to be split them for that. Then it’s not much difference if you tag them directly.
Unless you use some linear referencing method. But that’s undefined now, and complicated.
There were some ideas about street-parking. They only stayed as ideas. OpenStreetMap and Curb Regulations — SharedStreets

And what if there the tag used for the street should be unique (like wikidata or wikipedia)? Would you discourage the using of the relations then too? In the links below is such example.

vs.

1 Like

I put wiki and etymology tags on a relation if a street consists of more than a few parts with same name to capture wiki/etymology info e.g. Streets easily are 3 or more parts… asphalt, paving_stones, sett, asphalt and there you have 4. Can’t merge those not to speak of the vrs turn restrictions etc for points where sidetreets meet.

For names can’t do… all related addresses start being flagged as ‘can’t find street with matching name’ and usage of associatedStreet is not very common and frankly no idea if data consumers do anything with this as with type:street relations.

When roads like the Tiburtina Valeria, the SS16 consist of hundreds to thousands of sections it becomes comical… a mapper started adding etymology tags to the SS16 which has over 4000 members and many sections of that road have local names assigned by the communities it passes thru at that.

2 Likes

So what is the best praxis approach?: 1. to use street relations for wikidata and similar unique tags in order not to duplicate them or 2. to repeat the same wikidata tag over and over on each part of the street to satisfy renderers?

I checked the Tiburtina Valeria street (see the links below) and the wikidata tag Q3975349 is used there multiple time on each section of the road.

Yes, am aware and said what I thought of that, but not going to seek them out along the ca 250km way, same as the long standing confusion of that road by some tagged as SR5 when all the km posts old and new continue to be installed as SS5 i.e. I cycled down Pratola Peliigna to Pescara centre last year, every single one up and down is SS5 (Strada Statale v Strada Regionale). Look at the ref and names on the map…:upside_down_face:

So what’s best practise. I make street relations when more than a few parts AND when I make changes to a street for other reasons and find the name etymology of the ‘did not know that’ type… Via Napoleone does not tickle me fancy.

Perhaps Tiburtina Valeria has more in common with a route=road relation? It seems rather similar to Strade dei Parchi, for example:

Go to Pescara start (or end if you will) and seek out the sign posts… Via Tiburtina Valeria

Many signs point direction to this road just say ‘Tiburtina’, like since say 2000 years… very old.

I’d say approach (1) is definitely appropriate (preferable, even) for unique tags (though I’d recommend using type=street instead, which is more generic, for tags like wikidata, whereas type=associatedStreet is specifically meant for modeling address relations.

As for (2), I think it’s unfortunately unavoidable for the main non-unique tags, especially those that are particularly important for navigation (name, address:*, etc.) but otherwise I’d venture saying it’s OK to add properties like lit, surface, tree_lined, sidewalk, etc. (assuming they’re identical for the entire street) to the street relation instead of duplicating them for every segment.

That said, I wouldn’t be surprised if people start telling me that certain apps, editors, routers or validators would start complaining if these are missing from the street segments themselves even if they’re tagged in the relation. Ultimately it ends up being a question of whether we consider a property (and its use) important enough to tag for the renderer/validator/editor instead of what would produce the cleanest modeling in OSM’s data.

1 Like

Yes. I think it’s OK to create a relation for the purpose of wikidata linking, not least because the id of this relation will be (relatively) stable and be cross-linked with wikidata. wikidata can then show a map of the member ways, which is neat. You have to accept that relations rot without maintenance, but that’s not critical if the link is the objective.

But you have to distinguish between using relations purely as a construct to enable external linking and expecting OSM data consumers to exploit them. This is not realistic, not least because you will end up with conflicting tags on ways and the relation.

That said, I don’t see the point of etymology wiki-linking. I see a lot of “South Road/Steet etc.” tagged with an etymology for “South”, which seems very low value data.

2 Likes