duplicate data on members and relations

nyuriks · 2017-09-28T21:16:24.000Z

Hi. Often, the same tag is defined on a relation, and on some of its members. For example, a “wikipedia” tag may be set on a highway relation, and on the ways. The key:wikipedia page recommends not to duplicate such information:

provide, for an extensive feature encompassing many individual ways, such as a long railway line or river, a single Wikipedia link from a relation covering the entire feature rather than attaching a link to every single way individually.

Storing duplicates is bad for several reasons. It is not consistent (some ways may have it, some don’t, and it is never clear why), it makes data harder to process (consumers need to figure out why data differs), it creates an opportunity for errors, it makes it confusing if relation states one thing and the way - another. The same logic applies to other duplicate data, such as multilingual names. Unless the local segment of the river has a different name, all multilingual names should be set on a relation, not its members. I think the only exception should be “name” tag itself (not “name:xx”) - because that makes it easier for editors to understand what is what.

https://wiki.openstreetmap.org/wiki/Wikipedia_Link_Improvement_Project#Duplicate_tags_on_a_relation_and_its_members

Use “show results” in the last section to see and fix these cases.

Thanks!

Weide · 2017-09-29T08:55:11.000Z

+1
but…

…we should note, that there is no general rule that a relation may carry common tags of it’s members. The same tag may even have a completely different purpose for the relation. Example: “incomplete=yes/no” in a relation might refer to missing members while the same tag in a member might refer to the completeness of that member.

nyuriks · 2017-09-29T13:30:03.000Z

Weide, of course. I didn’t mean to mindlessly move everything. I think the only ones that clearly make sense are Wikipedia, wikidata, and name:xx. There might be a few others, but that’s in a case by case basis.