Hi Martin, at a first glance I thought you're joking with this proposal. Editor software often fuses nodes on the same coordinate, that's right unfortunately, but it's not a problem of nodes being on the same spot, but a bug in the editors. The handling of relations in most cases is even more complicated than the selection of one particular node of several ones on the same spot.
It might be an idea to do something like that when extending the data model somewhen in the future, but it is similar to how multipolygons are built as relations: at most a hack, but not a clean solution. That's why there are several discussions and proposals towards an area data type. The node relation you propose is similar, and even worse: it introduces another level of indirection for data consumption. And: Why restrict to nodes? why not use a way relation as well for ways sharing the same spot (e.g. tram and highway, communication cables and water tubes, ...) The relation makes using the data more difficult, but doesn't improve editing IMHO. If at all it circumvents misbehaviour of editor software (more or less automatic merging of nodes). regards Peter Am 10.07.2014 11:10, schrieb Martin Koppenhoefer: > > >> Am 10/lug/2014 um 10:09 schrieb Pieren <pier...@gmail.com>: >> >> I don't see any problem to have over two elements on the same >> position if they have different "ele" or "layer" values. > > > I think from a practical point of view these situations are > problematic, both for creation and selection of these nodes. Editor > software usually fuses those nodes, so you have to either edit the > coords manually or zoom very close and approximate the position. > Basically you have to apply some kind of hack and what people usually > do is put the nodes very close without a real overlap to overcome > these issues (selection and creation). > > Also overlapping ways for stuff like a retaining wall below a wall > below a fence below barbed wire would be a nightmare so these > situations tend to get modeled in fewer detail to circumvent the > problem. > > cheers, Martin _______________________________________________ > Tagging mailing list Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging