User:Polderrunner/Scratchpad

Highway relation

Here are some thoughts on a possible proposal for a "highway" relation collecting individual highway segments.

Rationale

As the layout or properties of a highway often change quite frequently the osm representation of the highway may end up getting very fragmented. Reasons for such fragmentation may be change of lane numbers, change of speed limits, bridges or different memberships of route relations. This leads to a number of problems.

• One disadvantage of such fragmentation is that common tags will have to be repeated on every little segment making maintenance more difficult.
• A potentially bigger problem is that each splitting of a way causes a new version to be created of any relation having this way as member. This is a significant issue for large route relations having hundreds or even thousands of members. The history of such relations tend to grow exponentially with their size requiring a lot of database resources and making history lookups virtually impossible. Edit conflicts on large relations are more likely and usually cause big headaches for the involved mappers. The relations often end up getting damaged in such situations.
• Further, renderers typically cannot join such way segments in order to render e.g. the street name over multiple segments, the result often being that no street name is rendered as the rendered name won't fit.
• A special problem concerns roundabouts which should normally be mapped as a closed polygon (otherwise routing applications may not guide drivers correctly). However, sometimes a roundabout needs to be split into multiple pieces, e.g. due to bridges or detailed lane mapping.

There are already a few proposed relations dealing with these problems to some degree. Relations/Proposed/Street is intended to collect parts of a street together with any addresses on that street. Relations/Proposed/Collected_Ways is more universal and intended for highways, railways and waterways. Relation:multilinestring is a very general concept for collecting ways or other multistring relations having some shared tags. One thing characterizing these proposals is that they are rather general and therefore may not be usable as direct replacements for highway way segments where specific properties are expected. The main purpose of the present proposal is to provide a relation that can directly replace a way as member in a route relation thus mitigating the expensive relation updating. Therefore some restrictions must be imposed on this relation, e.g. it must comprise at least a highway=* tag and a name=*/ref=* tag for highway types requiring this information. The other problems mentioned will also be addressed by such a relation.

Tagging ideas

A section of highway in which all way segments share at least the highway, name and ref tags may be mapped using a dedicated relation having type=highway combined with any standard highway tags. Example:

type=highway 
highway=motorway 
ref=A20 
oneway=yes

The member ways should keep all tags that are not shared by all members (e.g. maxspeed=*, bridge=* or lanes=*).

For backward compatibility the member ways should probably be tagged with highway, name and ref tags at least until such a highway relation is well supported by all major applications. This will defeat the purpose of reducing tag redundancy a bit although it is expected to be a temporary measure. The other advantages remain.

Undecided issues

• One way per direction for dual carriage ways or one relation for both directions? If the latter option is selected should it be allowed to include both oneway and twoway sections in the same relation? May roundabouts be members?
• Roles of members? (currently just left empty)
• Which tags must be shared by all members? (for now highway, name, ref)

New idea for lane tagging

Considering the objections against the lane_group proposal here is an alternative.

lane_type=left|straight|straight+right|right This specifies the lane turn type. Values may be normal, left, left+straight, straight, straight+right, right, all, merge_right/left, weave, hard_shoulder_running, plus_lane etc.

lane_type:backward=left|straight+right The direction field specifies the lane types for the forward/backward directions respectively. The lane order is from left to right as seen in the direction of travel! For oneway highways the direction field is not needed.

lane_use=all|all|psv This specifies lanes reserved for certain user groups. Values may be all, psv, hgv, cycle, hov (high occupance vehicle) etc.

lane_change=right|both|left|none This specifies whether a vehicle may change to the adjacent lane left or right. Values may be left, right, both or none.

lane_match=?? Some way of describing how lanes align between two road segments.

The new tags may be combined with existing tags like lanes=3, maxspeed:lanes=80|80|60, hgv:lanes=no|yes|yes, destination:lanes=dest-A|dest-B|dest-C etc.