I have composed a proposal that would establish a scheme for describing attributes relating to highway and railway gantries. Presently, the wiki page for man_made=gantry mentions some undocumented tags contributors have been using to describe attributes for gantries. in the case of one of those tags, gantry:type, it has been used over 2,000 times. As such, I think there is sufficient demand to warrant creating a tagging scheme to represent gantry attributes. My proposal aims to fill the demands of the users of gantry:type, who endeavored to use the key to describe both the structure type, and the uses of the gantry. My proposal will account for both of these uses. Please read my proposal page for more information.
I tried to include as many common use cases as I could. If you are familiar with the topic and know another common use case that should be included, let me know.
Would “gantry:use:toll=yes … The gantry features cameras and/or sensors for toll enforcement” possibly be better as “use:surveillance … features cameras and/or sensors for surveillance and law enforcement”?
Check the examples section, I intend that the proposed tags are used to describe the gantry, and then the node where the support is is tagged with support=*. That way you can attach a node to the gantry to represent ex: a variable message sign without it explicitly implying that the node is a support.
I intended to have a separate tag for cameras that are not used for tolls, but I lost several edits due to wiki errors and ended up missing it before RFC
I just added a section for gantry:use:camera=yes to describe gantries featuring cameras that are not used for toll enforcement with an example image. Perhaps another for LPRs would be good but I haven’t seen anything on commons yet
gantry:use:* doubles the information of the nodes attached to the gantry’s way. For example, a gantry tagged with gantry:use:destination_sign=yes will also have one or more nodes with traffic_sign=destination (or similar). These two sets of redundant information are likely to become inconsistent over time. Is gantry:use:* really needed?
I understand the duplicate nature of the tag, but I added it as an option to easily query types of gantries just using the tag on the gantry, without having to query for separate objects which would probably often go unmapped. Its sort of in the same vein as tagging a highway with lit=yes, even though you could map street lamps as separate features.
Interesting proposal! From a 3D rendering perspective, I’m mostly interested in the parts relating to the physical structure of the gantry and individual mounted objects.
Are there some good examples in the OSM database of detailed gantry mapping with mounted objects and supports?
Also, is there a convention to figure out on which side of the gantry the mounted objects such as traffic signs are attached or should I expect to figure that out only from context (e.g. direction tags on the signs, or the way direction of the road running below it)?
I like the ability to explicitly map the location and type of support elements.
However, the proposed tagging introduces some potential ambiguity. So far, support=* is generally used as a sub-tag for other objects (“how is this object supported”), rather than as a primary tag (“there is a support here”).
So if a node of the gantry has a support=* tag, it’s not obvious if this is the location of one of the gantry supports, or if it’s just a subtag of one of the elements attached to the gantry. (I’m not sure if the latter would be common, but I could imagine something attached on a gantry with support=suspended, for example?)
It could be avoided by copying the approach used for bridges where bridge supports are mapped using the dedicated bridge:support=* key and inventing gantry:support=*.
I have mapped a couple gantries before where I mapped the mounted variable message sign as a separate object (example)
I have considered making an established “front side” for gantry objects, sort of how it is done for guardrails, where there is a clear difference between each side that should be represented on the map. However, in some cases a single gantry structure can have two fronts if it spans over both directions of travel
I’m not sure how you’d account for this use case if you were to establish a front side for a gantry way. So far, if I do add objects mounted to gantries like my example above, I specify direction=* in degrees to align as best as I can.
I’m not very familiar with direction=*, but there might be a way to say “this mounted object faces perpendicular to the gantry way to the left/right” which I would consider a satisfactory solution.
Yes, support=* was a big thing I struggled with when thinking out this proposal. I was hesitant to create a new support key, but I also felt that support=* was somewhat inappropriate because it was not intended to be a top level tag.
I was not aware of the bridge:support=* key. This was the exact sort of model that I intended to represent gantry supports, something that could serve as a top level tag to just describe the support itself with options available. I’ll definitely add gantry:support=* to the proposal. Thank you!
there might be a way to say “this mounted object faces perpendicular to the gantry way to the left/right” which I would consider a satisfactory solution.
For instance using the :left, right,… sufixes, which would depend on the drawing direction of the gantry.
I second that. Maybe it’s a bit against the common practice with proposals, but could references to osm objects be provided in the Examples section, so that we could start experimenting with 3D rendering?
I didn’t notice the support= part. Still disagree with gantry:support= when there’s no need for another feature key. man_made=column is already documented to be possible for supporting structures.
Conceptually, the feature has problem with tube gantries. It’s a single tube, only in 3D. There’s no independent supporting part.
