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
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=<value>
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.
Rendered as:	Identical to the existing route appearance
Draft start:	2011-xx-xx
RFC start:
Vote start:
Vote end:

Contents 1 Proposal 2 Rationale 2.1 Shortcomings of the existing route specification and extensions 2.2 Solutions Provided by this Proposal 2.3 Integration with Existing Content 3 Concept 3.1 Variants 3.2 Filters 3.3 Predefined dimensions 4 Definitions 5 Tags 6 Members 6.1 Basic Roles 6.2 Role Suffixes 7 Route type independent filter dimensions 7.1 use filters 7.2 time filters 7.3 weather filters 7.4 direction filters 7.5 route level filters 8 Rendering 9 Features/Pages affected 10 Comments

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

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: oneway-tag of one or more of the possible ways (except on foot/hiking routes) forward/backward-tag of one or more of the possible ways 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	public transport, ferry: stop ski: desigated other: everywhere	Entry into the route is allowed: everywhere: any point where the underlying way (not the route) can be entered legally designated: at "entry" locations only entry_exit: at all points marked "entry" or "exit" stop: at all points marked "stop" 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	public transport, ferry: stop ski: desigated other: everywhere	Leaving the route is allowed: everywhere: any point where the underlying way (not the route) can be left legally designated: at "exit" locations only entry_exit: at all points marked "entry" or "exit" stop: at all points marked "stop" 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

• route relation page
• route=piste proposal
• public transport proposal
• route segment proposal

Comments

Nothing here yet