Hi Christian, I'd like to continue this discussion. I agree, lat/long information should not be duplicated. Ideally, this would exist as a list of elements (each with their own tag) within a single database entry for the relation (and it's lat/long.) To my knowledge (admittedly little) of OpenStreetMap's database structure, this is not how things are typically done however, so overlapping nodes, while not being ideal, would satisfy the current scheme. I don't see this dramatically increasing the size of the database more than any other relation.
To address the one object, one element, that's why this would be a relation instead of a key or value tag. It can convey "There are 5 elements on this pole or being supported by it, but if all you look at is the ground, you'll just see the pole." While on-the-ground mapping makes sense, I think it's more accurate to say map what is actually there as some elements in the world are not neatly placed on the ground (oh how glorious that world would be to map!) Guideposts are an interesting point and certainly used more in other areas than the Southern United States where I am, but this seems to try and explain where the guidepost is telling you to go and from where (similar to bus routes with their `to`, `from`, `via` roles.) I don't see a conflict with the current guidepost tagging and this overall mast proposal. This would be used as much more a node relation than route relation (with the exception of the wire over intersections piece, which I would be willing to let fall off and address some other day.) > .. creating one relation for each attachment if they are heterogeneous > - compare 2) - could probably be justified by the need to store tag sets > per attachments which might overlap key-wise (key collision; for instance, in > the event generic tags like color=* or location=* are to be used to > further speficy a street_sign and a traffic_sign mounted on the same > pole) 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. > while you can view the attachements as single physical entities as > well, this is cumbersome with osm, because location-wise they'd only differ > in height and ele=* is a somewhat optional key, while lat/lon are primarily > used to identify a node, the most basic bit of information to relate to a > physical object on ground within the osm ecosystem. The height / elevation issue is somewhat trying to be addressed by the order in which elements are added to the relation, similar to how a bus route must be in the proper order in a route relation. As far as lat/long, see my point above in the first paragraph. At any rate, the pole / mast (as in real life) is the common element connecting these items to the ground so the lat/long of the element meeting the ground would be what the relation is about. > However, if you have to different masts/posts/poles standing close, but > separately, next to each other, imho, two nodes (non-overlapping) should > be used. There may be objects where 'separateness' is hard to decide, > e. g. if they are physically linked above ground in some way, or have a > tripod shape, separate on ground but touching at the top.. I've thought about this for more than just this relation, such as signs with 2 poles, I suppose `support:count=2` is an option, but I agree that's not accurately displaying what is on the ground. Maybe the mast relation can have a member support? That way elements supported by multiple supports can be grouped if all the elements share this common (multiple) support? Maybe a relation of relations if some elements are on both some on only one? Truly just brainstorming on that one and haven't fleshed it out. Subjectivity is always hard of where to draw the line, but the world is imperfect, I think we would have to trust the local mapper / surveyor that they think as far as standing close (though I would agree with you as 2 nodes, I'm not trying to solve this issue with this relation.) Thanks for your thoughts and I look forward to your reply and any other feedback! -- GA_Kevin (OSM,Wiki,Forum,OSMUS Slack,Discord) > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
