> Gesendet: Freitag, 7. März 2025 um 21:03 > Von: Kevin <ga_kevin_tagg...@fastmail.com> > An: Tagging <tagging@openstreetmap.org> > CC: "Christian Müller" <cmu...@gmx.de> > Betreff: Re: [Tagging] MAST RELATION > > I'm maybe not quite following you here but this is aiming to address where > you want to tag the elements on a pole, or mast, not just the pole/mast > itself. These can be of many different types: traffic signals, surveillance > cameras, signs, advertisements, pedestrian crossing buttons, electric / > communication wires, etc. not just simple guideposts. Each could be valuable > to add to the database (and indeed, already have tags) but cannot be > accurately captured with the current scheme.
Yes, I actually have anticipated the points made, no need to iterate: the argument was logically split into the homogenous and heterogeneous attach- ments to a pole or mast. The guidepost tagging illustrates this. There are simple guideposts and more complex ones. Only for the complex ones, where attachments are non-uniform (type-wise) it actually makes sense to employ relations to 'map' reality. Please compare e. g. the image material in category https://commons.wikimedia.org/wiki/Category:Cycle_node_network_signs_in_Lower_Saxony These mostly adhere to a common pattern and it does not make sense to describe the common properties of all of these more than once. All you need for these is a good, discriminating tag that says (defines) a node to represent an object belonging to this group and then it suffices to tag only the information that _differs_ between them. The discriminating tag will let humans and machines know what group of objects the node belongs to, it will set it a- part from other nodes mapping different objects/aspects of what's on ground. In Germany there are multiple networks of guideposts, so for example a proper discrimination to group a network does _not_ end at tagging information=guidepost If the guidpost to be mapped belongs to a specific (and systematic) network the wiki suggests to add e. g. network=* or similar tags to further specify the type of guidepost. All generic information of how the posting signs are shaped, their size, the color they have, etc. are usually _not_ part of the database (unless maybe they deviate from the standard set up by the organisation that operates the guideposts network). The last five paragraphs describe the homo- geneous variant of poles, i.e. where the attachments do not differ in size, shape or color, but merely by the content printed on them. For these type of objects, by all means, the creation of relations is _rarely_ necessary, as the key-value tagging on the node (or maybe an osm-way, if the signs are attached to a kiosk or small box building..) does the job. Yes, I've understood you, that this homo- geneous setting is not the use-case you're primarily aiming at, but it helps to differ- entiate anything more complex, when the attachments are neither uniform nor necess- arily present in the same manner from pole to pole. Still focusing on the above, there is lots of sample data that references these 'simple' objects, e.g. if you've multiple cycling routes refering to a single guideposts, that guidepost _may_ be a member of all the cycling routes it relates to. (comparable to a train station in the public transport tagging; it may be referenced by the multiple train routes passing the station). Although OSM holds to some degree 3d-data, most editors map from a birds-eye view and overlapping nodes are (for mappers) mostly a maintenance night- mare, even if the reasons to employ them are topo- logically sound. For example, OSM does not map bricks in the wall, it maps the wall, using corner nodes and connecting lines. This is an abstraction of reality, mostly the attributes height=* and width=* will abstract away a lot of wall details, and if the data is re- played in a 3d viewer, there is loss of information. This is acceptable and in harmony with the project scope. Although some have used OSM data for flight simu- lator games, the project itself does not have the goal to house data to give a photorealistic re- production of the world. Instead it orients to support a number of use cases in civil engineering and private and commercial routing/pathfinding. That said, your proposal needs to account for tag-economic aspects of the data to be held in the osm database. For example, automated tools added non-descriptive tags to database objects in the past, i.e. the software revision used to edit an object. Later it was realized that this information was not only a resource hog but use- less for most practical applications and thus, subsequently removed (again, by edit bots..). Roughly spoken, anything that adheres to a pattern and would lead to lots of repetition in object tags is a target of later removal. Its simply not worth the effort, most of the time, to tag repeating parts of a system or subsystem that are inherent to its design. The approach osm has dealt with this in the past was to assume reasonable defaults, as per aspect of a subsystem, and then omit the tag fully, as long as an instance on ground does not deviate from this default. Again, imho, your proposal will get disapproval if you stick to overlapping nodes (for this pur- pose) and take into account to complicate data user's as well as human contributor's lives. Is it possible to do it this way? Of course, abso- lutely, but it is not the best approach. There is lot of precedence in the data, and in the wiki illustrating this. Greetings _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
