Proposal talk:Route Segments

Features needed to obtain the full benefits of segments

I personally think that we should add some features to the route segment idea that enable us to create lean, easy-to-maintain and easy-to-understand routes.

• Automatic handling of small variations in long routes, where the variations are due to well-defined circumstances, such as
  • common shortcuts or extensions (including those due to weather conditions)
  • direction of a route taken, such as one-way street parts (OK, I prefer to use common way definitions for both directions public transport routes at least where a substantial number of ways are shared by both directions, but this applies to all routes).
• When using a segment for a route, it should be possible to define the order in which the segment members are added to the route. This would be beneficial, because unlike routes in general, the current public transport proposal requires a specific order of members inside route relations.

I propose to discuss the need of such mechanisms here. For discussion of details about different solutions I have in mind, I will create a special section for each approach.

--Marl 08:00, 29 January 2011 (UTC)

Generic Filters

This is one of the approaches to tackle small variant problem.

A generic filter mechanism is the most flexible approach, but probably not very easy to understand.

There several dimensions that filters can be applied to, for example:

• time: summer/winter, weekdays, time of day (solves the problem of walking around areas in nature reserves that are close for two months every yar)
• direction of route taken (northbound/southbound, ...)
• weather conditions: ways unusable during rainy periods
• travellers' or vehicles' abilities
  • fitness: Many hiking routes contain optional points that are nice, but mean a considerable detour
  • time constraints: shortcuts

I'm sure that there are many more reasons for filtering.

Generic filtering, unlike the other approaches, is not necessarily specific to route segments. It would improve most route types, relieving mappers from creating variants for all combinations of users' needs (cycling southwards in winter, people who want to see one optional attraction of a hiking route, but not the other).

My proposal for generic filters (if we agree to use them at all) would be roughly this:

• role membership naming
  • Role membership names can have filter expressions appended.
  • The filter expressions follow the well-known turn restriction scheme: [only|no]_<dimension>_<lowvalue>-<highvalue>
  • Unneeded parts can be omitted:
    • If only one value matches, only that one value is mentioned. -<highvalues> is omitted.
    • If all values from a specific value on upwards match, the value is followed by a hyphen, the highvalue itself is missing.
    • If all values up to a specific value match, the value is preceded by a hyphen, <lowvalue> is missing.
    • There might be dimensions that do not need values at all.
  • The dimensions can be one of a predefined set, including those mentioned above:
    • time: derived from the well-known opening hours rules
    • direction: depending on the actual route, there are many options of identifying a direction. 'dir_[forward|backward|from|to|clockwise|counter-clockwise|north|east|south|west]'. Only the first two letters after the "dir_" are sufficient.
      • forward/backward,fo/ba: following the route according to the order (or reverse order) of way memberships
      • from/to, fr/to: towards the "from" tag of the route or towards the "to" tag of the route.
      • clockwise/counter-clockwise, cl/co: for circular routes
      • north/east/south/west, no/ea/so/we: Compass directions
    • weather: humid/wet/flooding/icy
    • tide: to be done, just an idea, maybe interesting for ferries, etc ...
    • option: shortcut/detour (only the first two letters are relevant again) A unique shortcut or detour name must be chosen as a value. Examples:
      • only_de_abccastle (for the tour via ABC castle)
      • no_de_abccastle (the short way leafing out ABC castle)
    • Public transport service level: [no|only]_level_<minlevel>-<maxlevel>, with the levels as described in section Level Filters
  • Multiple filters can be appended to one role membership. If so, all of them must match for the member to be used.

I hope that this is enough to explain the idea.

Please note that this syntax conflicts with the"entry_only/exit_only" part of the current public transport proposal., due to the reverse order ('_only' at the and).

--Marl 09:14, 29 January 2011 (UTC)

Level Filters

This is one of the approaches to tackle small variant problem.

The advantage of this approach is that it is much easier to understand than the generic filters, while it still gives a big amout of the benefits. Essentially, it reduces the generic filters to just one dimension, called levels. Of course, this does not exclude other filters, such as direction filters. They just would not be generic any more.

The basic idea is that the various route types often generate variants along dimensions determined by the route type.

I am not talking about the classic public transport route variants, because the route segments already provide a good solution for this problem, without the need for such an extension.

Levels typically occur here:

• express routes on public transport, sharing the ways and some of the stops (positions/platforms) with normal routes
• many hiking or cycling routes have long and short versions.

This is how it could work:

Extending Relation Membership Names:

• Relation members may be marked with a level attribute as an appendix to the route relation membership name. Example: stop_level_-10, meaning that the mentioned stop will be used when a route up to level 10 is built.
• The basic level is 0. It is used for members that are usually when travelling along a route.
• When defining an ordinary route based on a segment containing levels, the levels are ignored. In my example, a "stop_level_-10" member would be included into the main route just with the role "stop".
• When defining a higher level route, such an express route, the route segment would be included with a role name "level_10", meaning that members with a non-matching level attribute will not be considered to be part of the route.
• This can also be used for ways leading to stop positions that are used by certain levels only.
  • The way leading to the level 0 stop would be included with 'level_-9'.
  • The straight way bypassing the special way would be included with 'level_10-'.

An idea of defined levels:

• Railway:
  • Local trains: 0 (In Germany: RB, MEr, etc.)
  • Express trains: 10 (In Germany: RE, ME, ...)
  • ???: 20 (in Germany: IC, EC, ...)
  • ???: 30 (in Germany: ICE, in France: TGV, in Belgium: Thalys)

• Buses:
  • Ordinary buses: 0
  • Express buses: 10
  • Buses between cities that serve less stops that normal express buses (or other special, such as airport express buses, with only a few stops along shared bus routes): 20
  • International bus services: 30

• Hiking/Cycling (unfortunately, this does not support the individual inclusion of optional parts):
  • The longest variant: 0
  • The most frequently used variant (if shorter than the longest one): 10
  • A short variant, using all offered shortcuts: 20

The step of 10 for each main level leaves space for special arrangements, such as express buses serving more stops off-peak, when the normal buses run a reduced service. In this example, such stops might be marked level 9.

OK, this is my idea about level filtering. Of course, I prefer this scheme only in conjunction with a direction filtering.

Now I hope that a good discussion will start. I have no time left right now for a description of a direction filtering, but I think that it's not needed today, as you probably see what I mean in general ...

--Marl 10:18, 29 January 2011 (UTC)

Not needed

It is already possible to split long routes into segments, as relations can contain relations.

What you call a "segment" is simply a relation.

This whole thing is not needed.

Lulu-Ann

I think it is needed to define this. Because segments can be used in several parent routes. Right now if I want to use segments in order to make my life as an editor easier, the renderers don't understand. When I add a child relation to a parent, the child part is not rendered as part of the parent.

--Polyglot 10:11, 31 March 2011 (BST)

I agree that this is needed. Lulu-Ann is right that this is just a relation, but what matters here is the labeling applied to that relation. With the right labeling renders know how to combine a child relation with its parent. --MarkS 22:26, 1 April 2011 (BST)

Abstract proposal

The only purpose of a route segment is to be included in another relation, it serves no purpose for itself. I therefore propose a more abstract approach:

• The list relation is of type=list. Its only purpose is to be included as a member in other relations, to split them up into smaller parts. Other than type=list, it should only contain tags relevant for editing (e.g. note=*).
• Adding a list relation as a member of another relation is equivalent to adding all members of the list relation to the other relation. The order of the members and their roles are preserved.

-- Eckhart 16:20, 3 May 2011 (BST)

Lists are supposed to be ordered exactly, this is not the case for routes, whose order should preferably be infered from the topology, with easier editing (forward/backward roles should be avoided absolutely, instead member nodes with roles "stop:enter/exit" should be used; ways will be automatically interconnected and the direction infered from enter/exit nodes. — Verdy_p ^(talk) 22:07, 20 October 2016 (UTC)

Conflicting with other type=route

I think it should be avoided to use the same type=route as the "full route" relations. For sake of clarity, and avoid missinterpreting those segment route to real "full route". Since the goal of this proposal is to build a sub-part geometry of the whole route, I'd suggest to use a geometry constructor : Relation:multilinestring sletuffe 17:09, 30 November 2012 (UTC)

Or probably just another tag: type=route_segment, which will avoid all confusions with full routes including them as members.

Caveat: old softwares that don't recognize them will not be able to infer a full route which may appear broken with missing parts. That's why the designer chose to keep type=route but with a discrimating tag segment=yes (absent from full routes): old softwares will ignore the last tag and will process all these relations having the same network/ref as being part of the same route,without being able top determine directions and orders (the same rationale was used when route_master relations were created: they can safely be ignored, but then you won't be able to discriminate directions and variants, or if a variant is shorter than an another, the route appears as a graph with intersection nodes).

For now, without route segments, we need to add some ways multiple times as members of the same route relation, in order to modelize the T-like branches (or "_O_" looping branches) where the same way is taken several times, possibly in the same direction or in reverse directions, for the same target direction), and this causes problems when ordering ways (JOSM does not like the same member to be added multiple times, and creating an order is difficult).

Note also that for routes that are using transport_version=2, they are now preferably created with one route for each target direction, and taken only in one way (using backward/forward roles is no longer needed), but we still need to indicate which stop is the enter/initial one (and preferably as well which one is the exit/terminus one), so that the order can be infered correctly.

In my opinion the from=*, via=* and to=* tags are not needed at all in routes, or should just give a traveller-friendly name (the name of a station as seen in buses and travel guides, which is frequently much less precise, frequently indicate just a city name, or the name of an quarter/neighborhood, and not the exact and unique disambiguated stop name, possibly even longer than those displayed on poles in stations or platforms). Using qualified roles instead on platforms/stops in route relations will make it more friendly (we could as well use enter/exit precisions on roles for member ways in routes, but these ways tend to be split frequently, or redrawn, creating multiple members with the same enter/exit role.

Usually member ways are preferably left without any role in routes, and only stops (nodes on route ways) and/or platforms (nodes, ways or relations near the route way, but not connected directly to it) members should be qualified with an enter/exit role specifier:

In a route relation, or in a route segment relation,

• at most one stop can be qualified as "stop:enter", at most one platform can be qualified as "platform:enter", at most one stop can be qualified as "stop:exit", and at most one platform can be qualified as "platform:exit;
• unless routes are circular, they should all contain a single "stop:enter" node member, and a single "stop:exit" node member;
• for circular routes, no stop or platform are tagged at all, but the route itself is explicitly marked with circular=yes;
• bus/tram/train routes however are never really circular even if they enter and exit at the same stop node, as they operate in service times always from a starting point and will have a known terminus when ending their service (but it may still be usefull to close an effective loop where enter/exit nodes are different but in fact for the same station: every one must exit at the stop:exit node before the loop junction and can only enter at the stop:enter node; between the two there's a small link way which should be added as well to the relation but with a role such as "link" (renderers such as sketch diagrams may choose to not render at all these link ways, or just with a dashed/dotted pattern). If passengers can stay within the vehicle on these links, no role should be set on these link ways, as it is a real loop that should be rendered normally (as a "one-way" loop connecting the exit stop to the enter stop).
• bus/tram/train routes whose enter and exit stops are at the same node should be using a "stop:loop" role for this member node, instead of two member nodes with "stop:enter" and "stop:exit"; note that this stop node may be in the middle of a linear route (looping at both ends but without stopping there: route segments, rather than route-masters may also be needed to modelize the full route correctly, because route-masters are preferably used for distinct services with distinct variants and /or directions). But only for these circular routes, at least one way member should indicate a "forward/backward" role (it should be set on a short link way, connected to the stop with a enter/exit stop role, or a node member with "stop:end" role if it is dual)

With this approach combining route-masters for complete lines including all variants and directions, route-segments for complex routes with branches or loops, and enter/exit/loop stops with optional enter/exit platforms, the order or members in relations is no longer significant at all, and there's no more any duplicate members needed. — Verdy_p ^(talk) 22:03, 20 October 2016 (UTC)