What you propose is an algorithm that does a sort of “guess”. For doing some sort of guess, we don’t need to introduce a new relation. That could be done also without a relation.
Introducing a new relation should lead to better data and more well-structured information. There should be a certain gain in information. This will work only if the relation proposal is really clear. If not, probably it will happen the same things as with the “site” relation (=there are “site” relations in the database, but little software support for this). I think that Никита has touched a very important question: Is there inheritence? Means: Are tags on the relation also considered tags of the members? And how to deal with conflicts? This is not as trivial as it sounds. I’ll take some of your examples: – “name=Schwedenhöhlen” + “natural=cave_entrance” on the relation. “name=Schwedenhöhle 1…” + “natural=cave_entrance” on the nodes. Open questions: What does the relation represent? A collection of cave entrances? Or the caves themself? If it represents the caves themself, the tag natural=cave_entrance does not seem to be too appropriate. If it represents a collection of cave entrances, a rendering of the general name might be useful. But it might be useful to render it bigger than the individual names. – “name=Schwedenhöhlen” on the relation. “name=Schwedenhöhle 1…” + “natural=cave_entrance” on the nodes. You would have to go to the nodes, interpretate them and use the same rendering style also for the relation. Probably also not as trivial as it sounds. What, if not all nodes does not have the same tag (example: a natural=cliff within this group). Is this considered as error? Does this prevent the rendering? Your proposal was was count: More natural=cave_entrance occurences than natural=cliff occurences would make the relation render as a natural=cave_entrance. For me, this does not look like an improvement of the current data quality, but rather like a degradation of the data quality. At least, I would suggest to treat such cases as “invalid” relations which should be ignored by data consumers. – “name=Schönefelder Seen” + “natural=water” on the relation. No tags at the member areas. Is the “name” tag propageted to the members? If soo, we have the same problem like before: The name “Schönefelder Seen” is not appropriate for them. If the “name” tag is _not_ propageted to the members, we have another problem: “natural=water” has to be propageted to the members nevertheless; so we have some tags that are propageted (natural=water) and others that are not propagated (name=Schönefelder Seen), and we need rules how to determine which tags are propageted and which tags are not propagated. – “name=Schönefelder Seen” on the relation. “natural=water” at the member areas. Members propagate their tags to the relation. So a renderer can determine the color for rendering the name of teh relation. Sounds easy for the “Schönefelder Seen”. But this solution would create conflicts when applied to the caves, because the cave relation members have also individual names, and these names would conflict with the relation name. All this is too complex for a catch-them-all algorithm. To get a good rendering, you will probably need special algorithms for each type of feature. I understand that you want to have a simple and generic solution. But I doubt that this will create any benefit in the real practice. And I fear – if it is as generic as you propse – it will end up like the “site” relation. Your original idea was to give to give a common name to various objects. So, logically, the relation could be limited for usage together with the tag “name”: Something like type=common_name for relations, together with name=* on the relation. The members have an empty role. The members may not have any of the name*=* tags. All members are requiered to have the same tags; otherwise the relation is considered invalid. But even this is problematic: Imagine that you have boat=yes at one of the “Schönefelder Seen” lakes and boat=no at another of the “Schönefelder Seen” lakes. Imagine further a renderer that renders the labels of lakes in different colours, depending if the can be used by boats or not. I think we need a special tagging for each of these features. But type=cluster could help anyway. Introduce type=cluster for relations. But use it only together with special tags like natural=group_of_lakes – these special tags needs to be introduced also. type=cluster could also be used together with the existing place=archipelago. So you would have to make an own tagging decription for each feature (group of lakes, group of cliffs …) and this leads to a clear documentation and clear rules. _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
