Peter, I think (but am not 100% certain) that super-relations are the data structure you look for, the "different type of relation." It isn't QUITE a "different type" but rather a method of gathering relations together that structures them "sensibly," so, for example, a renderer can make sense of them. We do this with the distinction between "plain" multipolygon relations and boundary relations, for example. (The latter have some additional members in the relation with distinct "roles" and that makes them act — display — with certain behavior in the renderer).
Pilot projects are a good idea, but they need to be exceedingly clear and concise in what they are testing or developing (or both, and really, both in a back-and-forth is what works best in the long term). So, "it's time to be specific!" If renderer authors / developers were to chime in here with their understandings / implementations of how "names of areas in super-relations" are understood and rendered, that would be helpful. In fact, that seems like it is what is being "wished for," even if not explicitly: a full explanation of how to best "name complex natural=* areas in multiple multipolygons." If we don't get that dialog here, we can achieve the same results with experimentation and time. This (the wondering how things get rendered, or thinking that developing something new could get rendered, and importantly HOW this happens) can be a difficult topic in OSM. It often frustrates, confuses and doesn't seem (to me) like it is talked about frequently enough. However, "mapping, then rendering" is part of the wondrous magic of OSM. I understandable that so much "that's really amazing" could easily give rise to "other things should be realized as just as amazing, too." However, that's not how it works: no matter how wonderful technology is, we always wish it could be something better. But it doesn't GET better until we develop a path to get us there. That starts with clear explanations, good intentions, skilled people and time. This project does amazing things as we give ourselves these simple ingredients. SteveA > On Dec 13, 2020, at 3:26 AM, Peter Elderson <[email protected]> wrote: > > My answer only targets the question in the subject. > > No matter whether you put the same name on all parts, or on or some kind of > collective, you need a way for data users to know that all the parts together > have a name. > Tagging the same name on all parts makes the name a free text id needing > uniqueness - for me a bad choice. > Yet another polygon around the area, don't like that. I think we have too > many of those already. > Tagging all parts with a truly unique Id in a special key could do the trick, > but who issues/manages the unique ids? > Putting the parts as members in a relation achieves the same: a unique Id > common to all the parts; the name tag and possible other common attributes go > on the relation. > This gives renderers the exact extent of the total area, and the extents of > the subareas, which can have names and other attributes of their own. > Since an MP does not cover all possible layouts, you would need a different > type of relation. Maybe an existing type can be used, or a specialised type > can be defined. > > I would think a pilot project could test the concept for mappers, renderers > and other data users. If succesful, showcase. If not, document and delete. > > Peter Elderson <remainder redacted for brevity> _______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
