Martin said: " tags on the way apply to the way, those on the relation to tag relation as a whole. There is no general inheritance from the relation to its members."
When I made my statement about inheritance I tried to choose my words carefully. I said that those tags only _implicitly_ apply to all the ways in the relation because it's certainly not obvious that they do, or might. If a Wikidata tag appearing in the relation doesn't apply to every way, that means it would have to appear on each and every way, which would be, in my opinion, both illogical and needlessly redundant. However, if it does apply, then what are we to make of Martin's claim that there is no general inheritance? It makes no sense, from a software designer's perspective, to create a data structure that behaves one way for certain objects and differently for others and then not specify that behavior in some way for all to see. Kevin said: " So -- a physical attribute (highway=*, surface=*, building=*, bridge=*, whatever...) always goes on a physical object (a node, way, or multipolygon). Relations other than multipolygons are not physical objects, but conceptual groupings. They get the attributes that belong to the groupings - name, operator, contact information, network, reference, Wikipedia, website, .... They do not get attributes of the physical objects that compose them - those attributes belong to the objects and are not generally understood to be inherited from the relation." Sidestepping any talk about multipolygons for now, my contention that rendering issues have influenced OSM mappers to apply tags to every way has been supported many times in this long thread. In Kevin's most recent post, he says, "Also, because of various issues with data modeling, 'ref=*' sort of has to be there [on the ways], but that's a whole other discussion". Indeed it is, but nevertheless, it's often problems with rendering that motivate people to place tags on ways that rightfully belong only on the relation. Kevin goes on to say, Relations ... are not physical objects but conceptual groupings. They get the attributes that belong to the grouings- name, operator, Wikipedia, etc. They do not get the attributes of the physical objects that compose them - those attributes belong to the objects and are not generally understood to be inherited from the relation." One of the things I'm trying to learn here is just how those rules and that understanding came about. Gerd wrote earlier in this thread about my (admitted) desire to use relations to reduce data redundancy. He said: "The idea is not new and I think there similar discussions before. I think one of the arguments against it was that many editors are not able to handle relations good enough, I fear this is still true. I think the same problem is on the consumer side." I understand, but should those sorts of conseiderations really influence how we use relations? If so, it's like the cart driving the horse, so to speak. It's not a perfect world and my somewhat idealistic approach to this whole problem may indeed be foolish but I still feel that we mappers should be the driving force behind how we map things, not data consumers or writers of editors. IMO, part of the problem here, as I've said several times already, is the poorly written Wiki that leaves us in a quandary when trying to reason out the proper usage of relations. I'll bet nobody on this list can show me a place in the Wiki where it says that relations can contain no tags that refer to physical properties of objects. In fact, there's no explanation of the data structure at all. (Or maybe there is and I just haven't found it yet.) If someone can provide some evidence other than someone's opinion that a relation should not contain any tags that are concerned with physical characteristics of its member ways, I'll think to myself, that's really short-sighted, but if it's the law, I'll accept it and move on. Either way, I've learned a lot and will benefit from this discussion going forward. Dave On Fri, Nov 9, 2018 at 5:39 AM Richard <ricoz....@gmail.com> wrote: > On Tue, Nov 06, 2018 at 11:26:49PM -0600, Gerd Petermann wrote: > > Hi all, > > > > after reading the last comments in this thread I tried again to convince > > Dave that the rather special rules for multipolygon relations cannot be > used > > for all types of relations, esp. not those with route=pipeline and that > he > > should not remove tags like man_made=pipeline from ways of such a > relation, > > see this long discussion: > > https://www.openstreetmap.org/changeset/64027881 > > > > I give up now because for me a type=multipolygon relation is something > > completely different and Dave insists that it is are not. Seems we are > both > > frustated now :-( > > my experience with waterways tells me that "essential tags" (like > natural=water) > allways belong to the members and not any encompassing relation such as > relation:waterway. > man_made=pipeline looks like on of those tags I would always put on the > members, > not the relation. > > Richard > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
