Proposal:Simplify man made=bridge mapping
| Simplify man made=bridge mapping | |
|---|---|
| Proposal status: | Inactive (inactive) |
| Proposed by: | RicoZ |
| Tagging: | man_made=bridge |
| Applies to: | area,way |
| Definition: | Mapping of objects on bridges and in tunnels, multilevel bridges/tunnels |
| Statistics: |
|
| Draft started: | 2015-06-09 |
| Proposed on: | 2015-06-09 |
The approved proposal ( Proposed_features/man_made=bridge ) introduced the concept of bridges defined by an area and one or more ways using this bridge. The equivalent proposal for tunnels is now on the way (see Proposed features/man_made=tunnel ).
This proposal provides
- a simple scheme how to map objects on bridges and in tunnels can be mapped
- a way to map multi-level bridges and tunnels
More complex mapping of these features can be done using the Relations/Proposed/Bridges and Tunnels.
At the moment this is work in progress to adapt for the comming man_made=tunnel and natural=cave
Objects on bridges
Objects on bridges such as benches, waste baskets:
- node type objects which are part of one of the ways on the bridge or the outline declared byman_made=bridge/tunnel are declared to inherit the bridge/tunnel and layer attributes of those ways - no additional tagging is needed. This should also apply for objects on bridges/tunnels mapped using the conventional linear bridge scheme.
- objects not meeting this condition will be considered to be on the bridge/in the tunnel if
Ways on bridges
location=bridge instead of bridge=*
High/rail-ways across a man_made=bridge can be tagged with
instead of the currently applied bridge=* + layer=*
During a transitional phase (and beyond that if wanted) both methods can be used together.
Routers that evaluate bridge=movable (none currently?) should learn to inherit the bridge type from man_made=bridge.
Requires that man_made=tunnel is actually rendered, otherwise no tunnel will be visible at all.
Rationale
This will make it easier to keep the data consistent, easier to render man_made=bridge nicely and avoid routing problems.
It makes it easier for data consumers to see that the way is not a separate bridge in itself but a part of a bigger bridge making the whole bridge easier to render. Also it will avoid the situation that if a way is split in the middle of a bridge=movable routing software could consider it as two consecutive movable bridges which would typically distort routing cost calculation.
Because the bridge type is no longer stored as part of every single way crossing the bridge there will be no inconsistencies if the bridge type is changed or refined as those details are inherited from the man_made=bridge.
Finally, a simple bridges inside a tunnel (or the reverse) will work without headaches.
Multi-level bridges and tunnels
can be tagged as
- man_made=bridge + layer=* - outline + layer of the bridge in relation to other objects above or bellow the bridge
Ways on such multi-level bridges will be tagged with
- location=bridge + level=* (level of the way on the bridge) + layer=* (layer of the bridge, same as above)
Previously, this required the use of the mentioned hypothetical bridge/tunnel relation and was more prone to confusion and undefined results (see Talk:Proposed features/man_made=bridge#Multi-level example and Talk:Proposed features/man_made=bridge#Multilevel example does not work like in the picture).
Simple man_made=bridge structures
Further down the future trail:
- for rather simple single level bridges high/water/rail-ways running across the man_made=bridge bridge will inherit the layer=*, bridge=* and all other common attributes from the man_made=bridge and get an implicit location=bridge added. Thus these ways no longer need to be split where they enter and exit the bridge and tagged with layer and bridge tags separately except for the rare case of multilevel bridges where each way will need additional level information. Sharing a node with the man_made=bridge where the ways enter and exit the bridge should be sufficient to derive all other information.
May require nontrivial enhancements of tools, not clear when/if/how this part will be feasible.
Rationale
One of he goals of the man_made=bridge proposal was that attributes that belong to the bridge (such as name=*, height=*, layer=*) are attached to the man_made=bridge structure and ways using this bridge "inherit" these common attributes.
For backward compatibility reasons it was required that in addition to tagging man_made=bridge with layer, all ways using the bridge are also tagged with bridge and layer attributes separately. This requires splitting each way crossing the bridge in 3 parts and attaching all relevant attributes, making it unnecessary laborious to create complex bridges. Reviewing complex bridges with more than 2 ways it is evident that a significant percentage of such bridges contains various errors in the placement of bridge and layer tags, this simplification should make it easier to maintain such bridges in a correct state.
During a transition period and for non-trivial cases explicit layer, level and/or location=bridge tags may still be required.
See also
- concept to develop 3D mapping of bridges Bridge3D
- highway as area - Proposed_features/area:highway
- Simple Indoor Tagging
- Simple 3D buildings