User:Marl/route update thoughts
Note: Everything on this page is about sorting my thoughts, to prepare something to propose. It is not a proposal - yet.
| Route Update | |
|---|---|
| Proposal status: | Draft (under way) |
| Proposed by: | marl |
| Tagging: | element_order=none/ordered, oneway=yes/no, route_entry=everywhere/designated/entry_exit/stop, route_exit=everywhere/designated/entry_exit/stop=* |
| Applies to: | route 
|
| Definition: | Introducing a consistent mapping of route variants (different starting or destination points, shortcuts, etc.), recommended stops, route highlights and a scheme for adding route relation members. |
| Statistics: |
|
| Rendered as: | Identical to the existing route appearance |
| Draft started: | 2011-02-05 |
Proposal
Update the existing route feature, adding four tags and an extensible relation membership role naming scheme, initially covering full support for self-documenting route variants, route entry and exit points, via points, highlights and secondly integrating the various needs of different route types and route majority levels inside the OSM database into one concept.
Rationale
Shortcomings of the existing route specification and extensions
The current route feature has some major shortcomings that this proposal is aimed to fix:
- The current route feature description does not support route variants sufficiently.
- As a result, OXOMOA and the current public transport proposal have proposed to split up all public transport route variants into different relations, creating a lot of redundancy. The route segment proposal in its current state can reduce part of the redundancy, but the number of different route relations remains.
- In general, routes (other than public transport, such as hiking or cycling) are intended for individual use, so the number of variants grows exponentially with the number of options (entry points, exit points, alternative ways, shortcuts, detours) that a specific route offers. So unlike for the public transport case, the unfeasibility of creating a route dedicated to each variant is obvious here.
- Some of the public transport features are applicable to other types of routes, not only public transport. In particular, their public_transport=stop_areas and public_transport=stop_positions look quite interesting as recommended places to rest or to stay over night. Of course, the current tag names would not be optimal, but the meaning is similar enough to reuse them and to generalise the scheme.
- The current public transport proposal requires the relation members of every route to be ordered in the way the route is followed. For many routes, this is needed, so that software can figure out how the route is followed. However, for most of the routes, there is an obvious order and it is easier for software than for humans to find it out, as long as all ways are part of the relation. On top, this problem is not specific to public transport, so it should be solved for routes in general.
- When working on ways, mappers should keep intact the routes that are using the changed ways. This is often hard to do, for three reasons. Only the first two of them are already (partly) addressed by the route segment proposal:
- Ways are members of many route relations. Each one must be handled separately.
- Some route relations are very long, resulting in a high probability of update conflicts (two or more mappers are working on different parts the same relation)
- The mapper does not know the requirements he is expected to meet when updating the route. Most routes that I know (including public transport) are just 'bags', containing ways that belong to the route. Some use the (way direction based) forward/backward roles described in the current feature page - which is considered outdated for the public transport people since OXOMOA, where only the order of ways in the relation is relevant.
- Potential entry and exit points are not visible to the user. For local hiking and cycling routes, it is obvious that people can join the route wherever they like. For many long routes, there are recommendations - and these recommendations are worth mapping. Conversely, there are many bus routes out there where the bus driver will stop at any place where it is allowd to stop to let people leave the bus.
- Software cannot derive human-readable names of the ends of the route. Of course from=* and to=* are defined in the public transport proposal, but this is for public transport only and they are not related to an exact geographic position.
Solutions Provided by this Proposal
This proposal is a simple and consistent approach to overcome the shortcomings described above:
- Four new keys. Different defaults per route type make sure that most existing routes will need no change. The keys allow overriding of the default and help both mappers and software deciding upon how to handle the route.
- oneway=* defines whether or not a route is usable in one way or both ways.
- element_order=* defines for a specific route whether or not the elements are expected to be ordered. This enable mappers to update the routes as intended and software to draw the correct conclusions.
- route_entry=* and route_exit=* define where it is possible for a user to enter or to leave a route.
- A scheme for route relation member naming covers the remaining requirements:
- Route variants that, as a side-effect, are self-documenting and easy to recognise by humans as well as by software
- Existing variants can be listed, categorised by variant type (shortcut, detour, option, time or weather restrictions, etc.)
- The ways used by variants
- Points on (at least one variant of) a route that make a route or variant recognisable without the need for variant names ("via" points)
- Highlights (similar to "via" points, but not exactly part of the route).
- It also introduces a generic framework of route levels, to be filled for route types as needed. For public transport it would mean the easy maintenance of express routes routes sharing ways and stops with basic routes (express buses / regular buses, inter-city trains / regional trains / local trains, etc).
- The stop_* roles brought in from public transport are incorporated in the scheme and made available to all relations
- The scheme itself is extensible, providing conflict-free support for requirements of other proposals, such as public transport and route segment
- Entry and exit points for route users, visible to both users and software
- Route variants that, as a side-effect, are self-documenting and easy to recognise by humans as well as by software
Integration with Existing Content
The proposal integrates well with the existing OSM database content
- It is based on existing schemes and combines them into one concept
- Most of the existing routes already comply to this proposal, because of the defaults chosen
- It offers a big flexibility to mappers. It supports all maturity levels a route can have. From the most basic state (collecting ways of a route that has not got much more than a name and a type) to the most sophisted one (ways, stops, breaks and platforms fully documented)
Concept
Variants
a description here how variants are created by adding members with an only_sh_..., only_de_, only_al_, etc., how the routes are added that are used otherwise are added (no_...), how via points and highlights can be integrated and how this makes it easy for software, users and mappers.
Filters
Generalising the variant "filters" to the abstract filter concept
Predefined dimensions
Outlining the idea of other filters (time, weather, direction, route levels)
Definitions
| Term | Explanation |
|---|---|
| Self-Intersecting Route | A route with at least one junction point where the user or software cannot know which way to go, based on the following criteria:
Fully mapped self-Intersecting routes need their elements to be ordered the element_order tag to be set accordingly. |
Tags
(Only new tags (additional to the existing route page) are mentioned here)
| Key | Values | Defaults | Explanation |
|---|---|---|---|
| oneway | yes/no | no | the same as for highways - the default is always no, because only very well-mapped public transport routes have separate route relations per direction |
| element_order | none/ordered | none | For most routes, no element order is needed. Ordering is needed where a route is self-intersecting. In these cases, the user or software cannot derive which way the route exactly is. |
| route_entry | everywhere/designated/entry_exit/stop |
|
Entry into the route is allowed:
Some routes (in particular touristic routes) do stop at positions (often highlights) where it is not possible to enter the route. |
| route_exit | everywhere/designated/entry_exit/stop |
|
Leaving the route is allowed:
Some routes (in particular touristic routes) do stop at positions (often highlights) where it is not possible to leave the route. |
Members
(This is thought to be a replacement for the existing section)
Basic Roles
| Way or Node | Basic Role | Recurrence? | Discussion |
|---|---|---|---|
 |
(blank)/route | zero or more | the ways making up the route. |
|
link | zero or more | Link roads (highway=*_link) from and to the route. See highway=motorway_link! |
 |
stop | zero or more | A point on the route where a planned stop is needed or recommended for reasons due to the route. This can be anything from a recommended break, up to a public transport stop_position. |
|
stop:<number> | zero or more | A Bus stop or train halt, on the route. The number starts with 0. This is not needed to preserve order of stops in API v0.6, just use role=stop and change the order of the stops in the relation. Deprecated. |
|
forward/backward:stop:<number> | zero or more | A Bus stop or train halt, on the route, which is only be used in one direction. The direction is related to the direction of the way, nothing to do with towards/away from any bus station or terminus. This is not needed to preserve order of stops in API v0.6, just use role=forward/backward_stop and change the order of the stops in the relation. Deprecated. |
|
forward/backward:stop | zero or more | A Bus stop or train halt, on the route, which is only be used in one direction. The direction is related to the direction of the way, nothing to do with towards/away from any bus station or terminus. Deprecated. |
... to be continued
Role Suffixes
| Basic Role | Role Suffix | Recurrence per role membership | Discussion |
|---|---|---|---|
| (blank)/route | forward/backward | zero or more | If a route should only be followed in one direction for some or all of its length and traffic AND the assumed vehicle is allowed to go both directions on the same way, the "role" can indicate this for some or all of the constituent ways. "forward" means the route follows this way only in the direction of the way and "backward" means the route runs only against the direction of the way. (Makes sense only if element_order=none.) |
| (blank)/route | north/south/east/west | zero or more | in North America road are signed with their orientation, as a replacement for forward/backward |
| (all) | with_... | zero or more | "with" filter operator |
| (all) | only_... | zero or more | "only" filter operator |
| (all) | no_... | zero or more | "no" filter operator |
... to be continued
Route type independent filter dimensions
use filters
need to find a better name for this
Use filters select parts of a route where the route user can do things. They do not form route variants. The dimension name is "use".
| Value | Explanation |
|---|---|
| entry | The point can be used as an entry point into the route |
| exit | The point can be used as an exit point out of the route |
Examples:
| Base Role | Operator | Dimension | Value | Full Role | Explanation |
|---|---|---|---|---|---|
| stop | only | use | exit | stop_only_use_exit | the stop is for exit only (in a route that otherwise can be left at every stop, as it is default for bus routes |
| stop | with | use | exit | stop_with_use_exit | the stop is for exit(in a route that can be entered or left at dedicated places only) |
| stop | with | use | exit, entry | stop_with_use_entry_with_use_exit | the stop is for both entry and exit(in a route that can be entered or left at dedicated places only) |
time filters
weather filters
direction filters
Direction filters are used to generate direction variants from a route. The dimension name is "direction" or "dir".
| Value | Explanation (The element is used only if the route is [not] followed ...) |
|---|---|
| forward, fo | ... according to the order of way memberships |
| reverse, re | ... according to the reverse order of way memberships |
| forward, fo | ... towards the route's "to" tag |
| backward, ba | ... towards the route's "from" tag |
| clockwise, cl | ... clockwise (for circular routes) |
| clockwise, co | ... counter-clockwise (for circular routes) |
| north, no | ... northwards |
| east, ea | ... eastwards |
| south, so | ... southwards |
| west, no | ... westwards |
Examples:
| Base Role | Operator | Dimension | Value | Full Role | Explanation |
|---|---|---|---|---|---|
| (empty) | only | dir | forward | only_dir_forward | the way is used only on the trip along the order of way memberships |
| (empty) | only | dir | backward | only_dir_backward | the way is used only on the trip along the reverse order of way memberships |
| stop | only | dir | forward | stop_only_dir_forward | the stop is for valid on the trip along the order of way memberships |
route level filters
need a better name for these
Rendering
What renderers and other software can do
Software can use OSM data to display route variants without knowing about the dimensions used. The program just has to load the route relation, to expand all segments and to list the filter dimensions found. Entry, exit, via points and highligts can be displayed as a characterisation of the alternative. For selecting an individual variant, the user can choose one from every available dimension, except from the "option", "detour" and "shortcut" dimensions, from which he can select any number.
Only the "direction" dimension needs some special handling, because the "forward" direction (the only option in the current public transport proposal) and the "backward" direction do not mean anything to a user looking at a rendered map. In these cases, the route's entry and exit points and (if no entry or exit points are available) the "from" and "to" tags must be used.
Features/Pages affected
Comments
Nothing here yet