User:Slhh/ÖPNV Vorentwurf
Hier ist das zurückgezogene Proposal (Stand 29.7.13) von User:Weide gesichert, da viele Probleme aufgezeigt und auch interessante Lösungsansätze vorgesetellt werden. Nur die gewählte Gesamtlösung scheint wenig attraktiv zu sein. Es wäre zu untersuchen, ob die Probleme nicht auch durch eine hinreichend kompatible Lösung gelöst werden können.--Slhh (talk) 01:52, 2 August 2013 (UTC)
Die Segmente sind jetzt wieder drin. Nach einer Diskussion im Forum denke ich, dass der Einsatz von Segmenten dem einzelnen Mapper überlassen werden sollte. Sie haben zwar nicht meine ursprünglichen Hoffnungen an Verbesserung der Übersichtlichkeit erfüllt, aber sie sind wohl manchmal sinnvoll einsetzbar.
Die pt2_version ist wieder drin. pt2_version=1 gilt für diesen Vorschlag und kann weggelassen werden. Andere Werte sind für zukünftige Überarbeitungen.
Falls jemand mutig ist und testen will: ganz hinten habe ich eine preset.xml für JOSM angehängt. Bitte vorsichtig sein und nichts hochladen!
Preface
This proposal is a result of the experiences with the Public Transport Proposal, which has been accepted in the voting closed at 20-apr-2011.
It mainly replaces the relation types and leaves everything else essentially untouched.
The new relations will also no longer depend on data from stop_area and alike.
Some new tags and one new value are added to the the non relation part of the public traffic proposal.
The new relation types and the new tags do not introduce incompatibilities for existing programs, as everything introduced here is designed to be ignored by them. Programs supporting this proposal will use the new relation kinds and ignore the corresponding old ones.
This does however not hold for the the new value of public_transport. But for most programs the new value any_platform will be just synonymous to the already existing value platform and for the others the required changes will be minor ones.
Problems addressed
Names of stops
The tags name and ref have been used in so many different ways, that they have become nearly unusable for automatic processing.
Example
Assume the Fargo railway station has the number 12345 in some railway station list and the platform number 4 is to be tagged. Value combinations for ref and name found in OSM include:
name=Fargo, ref=12345, platform=4 name=Platform 4, ref=4 name=Fargo 4, ref=12345 name=Fargo Bahnsteig 4, ref=12345 name=Fargo platform 4, ref=4 ...
Nodes as platforms
The proposal mentioned above aimed at replacing highway=bus_stop and alike by public_transport=* in the long run. But for platforms it says "... Way or Area where the passengers can wait for the vehicles. If there is no platform in the real world, one can place a Node at the pole.". Now there is no way to express "here is a platform node with unknown details" as it was possible with highway=bus_stop and the transition to the new way of expressing things cannot be completed. This case occurs rather often.
There should be a value saying nothing about the details of the platform even if it is a node.
Values of roles and the meaning of member sequence
While mapping was enhanced very much by the Public Traffic Proposal, interpretation of the relations found "in the wild" became/is now a very hard job, as rules incompatible to each other are in effect simultaneously. The many mappers thinking, that these rules were compatible and could be intermixed freely, produced many relations which are plainly wrong when interpreted by any of the known rule sets.
OSMI, Öpnvkarte and the JOSM-Validator suffer from these problems as they cannot guess the set of rules to be applied.
The appropriate values for roles and the meaning of the member sequence is a property of the relation type and so type=route should not have been reused.
But if the old type is not reused, the problem of keeping the old ones has to be addressed as the renderers and others programs cannot be expected to change immediately.
Vehicles stopping twice at one station
For many passengers using public traffic the most important question is "When do I have to press the stop button?".
It is therefore essential, that stopping twice at different platforms of the same stop leads to a double appearance of the name in the list of stops.
Comparing stop names to get the list of stops is not appropriate.
The roles should give an indication whether a member introduces a new stop or just gives additional information for an old one.
Vehicles using several platforms at one stop
Subway and tram stops at "big event" places and airport commuters sometimes use platforms on both sides of the car to get a sufficient throughput of passengers. These platforms should not be interpreted as several stops.
Platforms being partially on bridges are splitted. When they occur in the routes platform list, they should not be interpreted as several stops.
So again, the roles should give an indication whether a member introduces a new stop or just gives additional information for an old one.
Completeness of the stop sequence and the tour
A list of stops is not very useful, if you don't know whether it's complete or not. The same holds for the list of ways used by the vehicle.
Construction works
Longer lasting construction works may influence the variants of a route and sometimes may it be worthwhile mapping them.
Renderers may want to include them only if they last long enough and use the "normal" variant otherwise. But what is "long enough" depends heavily on the release cycle of the corresponding map and therefore cannot be decided by the mapper.
So both variants should be available even if only one of them is used at any time. Having both variants available is also better for mapping, as changes to the inactive route can be done in the normal way and changing the same variant and then changing it back is an error prone process.
Variants should get tags to specify a time range of inactivity or activity.
Segments
As more and more variants of routes are added, editing some streets becomes really boring, as the same editing operations have to be done again and again. Therefore public traffic subroutes should be defined.
There is however a real danger to introduce a "cool" feature which will be overused by mappers or by the combined effort of mappers. So recursion ("subsubroutes"", ...) should not be allowed, even though it could come handy sometimes.
Local variants
Routes can vary in two different ways:
1.: "Real" variants are differences in the sequence of stations or the time needed between them. They should be represented by a variant relation for each variant.
2.: "Local" variants are minor variants without any different station sequence and without different travelling durations. They occur mainly at big train stations and at stations where slow and fast trains meet. Different platforms are used for different tours of the same variant.
More and more local variants emerge in the course of detail mapping. The consequences for the traditional "one relation per variant" mapping are fatal. A station mapped in detail and having three different platforms for the same variant multiplies the number of variants by three und this multiplication process is repeated for the next one. This process creates huge amounts of variants making the route practically unreadable.
These local variants should be implemented in a different way to avoid the multiplication effects.
Roundabouts
There are different opinions of what mentioning a roundabout as member of a tour means. Some mappers accept a roundabout member as a representative of a partial use of that roundabout and some require, that splitting a roundabout and putting all of it's parts at place previously used by the complete roundabout should never introduce errors. Both ideas do have a value, but they are incompatible to each other.
The problem can be solved by introducing a special role for complete roundabouts which represent only part of it's way. Mechanical splitting will then lead to automatically recognizable errors, which can be handled by the editor or easily be recognized by other programs like OSMI or KeepRight.
The special case of stops inside of roundabouts which introduce a "one and a half times" usage of the roundabout should also be addressed.(example: N48.729571 E2.127432)
Colours
The tag colour has been used not only for official colours associated with the object but also for rendering requests of the mappers. It should be possible to correct these entries without deleting information. Different tags for the different meanings of colour should be defined.
Renaming on the fly
Some public transport lines are renamed while being on their way. For the passengers this is an important information which can can only be expressed as a note now. There should be a means of expressing it in a machine readable way.
Different names for opposite directions
Some public transport lines have different names depending on the direction. As "revert direction" is an important operation for many information programs, this information should be stored in a machine readable way.
Stop positions as part of route relations
Useful routing in public traffic consists of
1.: routing the public traffic vehicles
2.: routing the passengers between platforms and at the beginning and the end of the route.
Trying to solve the first problem without using time tables is futile. But the
second problem is one of the strengths of OSM, as we can compute much more
realistic distances between platforms as anyone else because we already have
the footways, stairs and elevators in many of those parts of the world where
these problems occur.
So having stop position entries in the route in addition to platform entries serves no purpose. They may be useful -- but not as a part of the route.
- _exit_only and
- _entry_only are not really useful as first and
last stop markers and for intermediate stops they are not needed as time table routing doesn't use them. So they should be omitted.
Variants of ferries in tidal water
There is an infinite amount of variants in reality and so we have to reduce this count drastically. Clear rules are needed to decide which of them should be mapped and which not.
The routes of ferries in tidal water change rather often due to sediment movement. To incorporate these changes, some kind of observation date is useful.
In the case of point-to-point connections rendering the duration of the variant may be useful to allow passengers to order new tickets for the next vehicle depending on the variant observed... A duration tag should be defined to allow renderers to implement this feature.
Future versions
There can be no doubt that we will learn more about public transport tagging in the future. To allow for future revisions without defining new relation types, a revision tag is defined.
All relations defined here have a tag pt2_version=1 which may be and should be omitted. It should however be checked by programs, as the rules given here only apply for this version. Future versions may have different rules and will have different values for this tag.
Amendments to stops
Here are some amendments to the tagging of platforms and stop positions described in the Public Transport Proposal.
Platform nodes
To be able to map platform nodes with unknown properties, the tag public_transport=any_platform is added to the set of values.
This tag corresponds to highway=bus_stop and alike even in the case of nodes. For ways and areas it's the same as public_transport=platform.
Names
Example
The train station "Solingen Hbf" is associated with a bus station which is named "Hauptbahnhof". A name, which is not suitable for internet lookups as "Hauptbahnhof" is just the german word for "main station". Platform "1c" would be tagged:
pt2_subname=1c pt2_name=Hauptbahnhof pt2_groupname=Solingen Hauptbahnhof pt2_lookup=Hauptbahnhof, Solingen
Tags
pt2_subname A name as found on the splot which is used to distinguish different platforms/stop positions of a station. Normally this will be a number or a single upper case letter.
Classifying parts like "Platform" or "rail track" or "spår" are not part of the string. Their insertion and the language selection is at the renderers decision.
Special cases:
pt2_subname=? value is unknown, but there is one pt2_subname=- there is no subname pt2_subname omitted: unknown
Multiple subnames: If the tagged object is used for several elements (many railway platforms belong to two rail tracks), give the subnames separated by ";". Do not create a combined name but leave it to the renderers to combine the subnames and to add substrings like "platform", "rail track", "spår" or "Bussteig".
pt2_name A name as found on the spot which is common to the different platforms etc. of the station.
Multiple names: If the station has several names (like "Station" for the local bus service and "Fargo" for the train service), use the one which applies to the object to be tagged and add a common pt2_groupname.
pt2_name should not be omitted even if there is a relation serving a similar purpose.
pt2_groupname If a station is known under serveral names or several stations form one place for the passengers to change vehicles, the mapper should find a common name which ist easily understood by passengers and add it as pt2_groupname to each and every object having a pt2_name even if the names are equal. It should be omitted otherwise.
pt2_groupname should not be omitted even if there is a relation serving a similar purpose.
Example: The station in Hilden Süd (Germany) has two associated bus stops.
Train: pt2_name=Hilden Süd Bus: pt2_name=Hilden Süd S-Bahnhof Bus: pt2_name=Talstraße/Hilden Süd S-Bahnhof
They should be mapped with a common pt2_groupname="Hilden Süd" because this name is used by the passengers when they talk about changing vehicles.
pt2_lookup This name is tailored for use in internet lookups (and serves a purpose similar to ref_name).
If there are several internet services try to find a common value useable for all of them.
If this is impossible, use different tags named "pt2_lookup:*", where '*' is some unique substring of the URL of the service for which it should be used.
Programs should try to match any existing "pt2_lookup:*" to their list of URLs first and use "pt2_lookup" only if there is no match.
pt2_lookup should be omitted, if it would be equal to pt2_name.
Transition from old to new relation types
The old route relations (type=route, type=route_master, type=line) should not be deleted (as they are in use by programs). The PT2 relations have to be created as additional relations and for some time we will have duplicate information in the data base. There will however be no duplicates in the results derived from the data base. Programs which are not PT2 aware will not recognize the PT2 relations and programs being PT2 aware will obey the tag pt2_ignore=yes.
The tag pt2_ignore=yes should be recognized by all PT2 aware programs and it should lead to ignoring the corresponding relation completely.
The tag can also be used to avoid premature processing while a set of PT2 relations is under construction. Only as a last step, the tag should be moved to the old relations.
New route relations
Masters
type=pt2 pt2=master (Default: pt2_version=1)
Contains information about the route as as whole. It's purpose is very similar to the type=route_master relation described in the Public Traffic Proposal. But this relation is always present even if there is only one variant.
Variants always belong to exactly one of these relations.
Only variants may be members of this kind of relation.
The member sequence does not have any meaning.
All members have an empty role.
Tags
vehicle The vehicle kind(s) used.
Values are: train, subway, monorail, tram, trolley_bus, bus, taxi, aerialway, ferry
Routes traditionally marked with "light rail" or "light train" are marked with a vehicle kind of train here.
name A short string just enough to identify the service.
Use local language: ("Buss 80" instead of "Bus 80" in Sweden) In many cases, the name should be formed by appending the ref-value to the vehicle kind.
ref The reference "number" of the route as a whole.
retour_master_ref If the opposite direction has a different ref, it should be given here. Omit otherwise.
list_complete Indicates the completeness of the list of variants.
- complete No variants known to be missing
- incomplete some variants are missing
- fragmentary far from being complete including nothing at all
Remark: "list_complete" is the just completeness of the list and tells nothing about the completeness of it's members.
tidal_ferry=yes should be added, if the variant used by the ferry depends mainly on the water level.
There is a practically infinite amount of variants here and so we cannot include all of them. So do not include variants just because you have observed them. Only the principal ones should be included. Principal ones are determined in the following way:
Imagine the changes of the route as the water rises from very low to very high: Whenever a small change of the water level results in a big change of the route (as a way becomes usable, which didn't have enough deepth before) include this new route as a variant.
Remark: The principal routes cannot be marked with a water level value as different ships need different water levels for the same route.
Remark: To be able to find these principal routes, it is recommended to add as many tracks as possible to the OSM track database. It's important to have at least the year included in the tracks as routes in tidal waters often change due to sediment movement.
others The keys route, route_master and line indicate a different concept and should not be used. Other tags traditionally used in such relations (like network, operator, ...) may of course be used.
Variants
type=pt2 pt2=variant (Default: pt2_version=1)
Contains information belonging to one variant of one direction of the route. It's purpose is very similar to the type=route relation described in the Public Traffic Proposal.
Variants do not have variants, except for local ones. See minivar below.
Tags
var_name The name of the variant as it is displayed on the vehicle or on announcement displays. The name should allow a passenger being at the departure point to find the right vehicle immediately.
ref The reference "number" of the route. Same as in the master relation. (See also var_ref below).
description A short text describing the variant in contrast to the other variants. Don't include the ref number, to allow programs to make lists with and without ref numbers.
This text should be used when displaying a list of variants.
Examples for variants of a route:
description="Atown => Btown" description="Atown => Hospital => Btown" description="Atown => Btown => Ctown"
var_ref In some parts of the world, variants have reference numbers of their own which are visible to the passengers and useful for them. Do not use it for "expert only" numbers.
Example from Paris: ref=RER B with var_ref=RER B ICAR
follower_ref If the service is renamed during the tour, give the ref value of the following route here. Omit otherwise.
If the passengers have to leave the bus, it is not a renaming of the service but a completely new tour and "follower_ref" should not be used.
Variants differing only in this value are mapped as different variants.
tour_complete
The completeness of the list of ways mentioned
here. Do not count things which belong into referenced relations.
Values are:
- complete No parts are known to be missing
- incomplete some parts are missing
- fragmentary some (or no) parts are available. Not a useful overview.
If the key is missing, the information is unknown.
stops_complete The completeness of the list of stops mentioned here. For the values see "tour_complete".
per_week A rough estimation of the long termed arithmetical mean value.
Don't be too precise. Do not use the most frequent value or a somehow "normal" value.
Used by programs, where the "normal" and "extraordinary" variants are handled differently. The usage of this tag is strongly recommended, if the values of the different variants differ by more than a factor of 10.
hours Duration of the journey for point-to-point-connections (many ferries), omit otherwise. Use "." as a decimal point, where needed.
colour:used The colour of the route, if it is used by the people like a line number ("Switch to the red line at the next station"). Omit otherwise.
colour:official Official colour which is not well known to the passengers. Omit otherwise.
colour:* Colour preference for other purposes (renderers)
active_from, active_until Temporarily used variants are specified with a data range. Give the first and the last day as "YYYY-MMM-DD" using the first three letters of the english month name as "MMM".
Do not remove the replaced variant. It is up to the map creator programs to decide which of the variants should be used. (They may very well decide to ignore all variants having "active_*" and to to ignore the tags "inactive_*".)
The variant should be deleted when it is outdated.
inactive_from, inactive_until Temporarily unused variants are specified with a data range. Give the first and the last day as "YYYY-MMM-DD" using the first three letters of the english month name as "MMM".
These tags should be removed when they are outdated.
others=* The keys route, route_master and line indicate a different concept and should not be used here. Other tags traditionally used in such relations (like network, operator, ...) may of course be used.
Member sequence
Objects contributing to the stops of the route are sorted according to the sequence of stops during the journey and are placed together as the first group of members.
The ways contributing to the route of the transport vehicle are sorted according to the sequence of their use by the vehicle. If a way is used several times, it should be given that many times at the appropriate position in the sequence.
Members contributing to the vehicles route are always OSM ways. Even if there are areas in reality instead of ways (ocean ferries), a principal way must be given.
Member roles
forward and backward are not used. Remaining
ambiguities should be solved by splitting the loop.
The other roles of the members are:
haltvar
Used for minivar relations (see below) for the stops
contained there.
wayvar
Used for minivar relations (see below) for the vehicles route
ways contained there.
haltseg
Used for segment relations (see below) for the stops
contained there.
wayseg
Used for segment relations (see below) for the vehicles route
ways contained there.
empty
The tag for ways contributing to the route the
vehicle uses.
Note that using this role with a roundabout will be wrong in most cases (even if the roundabout is used completely). (see "part" below)
part
The role for unsplitted roundabouts indicating a partial
(sometimes even a complete)
use of that roundabout. Only the parts of the roundabout necessary to
connect the neighbour members of the relation belong to the route.
Splitting a roundabout is not necessary for anything described here. If it is necessary for other reasons, doing it correctly includes:
- removing members
- sorting members
- perhaps even doing additional splittings
Editors not supporting correct splitting will automatically create
partial roundabouts with the role part, which is plainly wrong
and easily recognized by programs.
part+
Used instead of "part" in the rather exotic case
where more than one complete turn in the roundabout is needed. (A bus stop
in the otherwise unused part of the roundabout)
Example: Carrefour du Golf, Saint Aubin, Dep. Essonne, France
halt
There is exactly one "halt" member for every stop of
the vehicles tour variant. The object referred to should contain the
name(s) of the halt. It approximates the start/stop positions of the
passengers pedestrial movements.
The "halt" entries are also used to find the sequence of potential stops and their names.
+halt
Additional objects belonging to the same stop of the vehicle as the
immediately preceding member as long as they contribute to pedestrian
routing from/to the place, where passengers enter or leave the
vehicle.
Normally the halt and +halt entries of a stop will give
the platform objects of that stop. If there are no mapped platforms, the
stop_position may serve as a surrogate.
OOS
"Out of sequence" members of any kind. Any object
belonging to the route but with an unknown position within the member
sequence. This role typically occurs only in the early stages of
mapping a route.
Renderers etc. will normally ignore these objects completely. The information is mainly for mappers. The role normally used for objects of this kind is omitted.
Segments
type=pt2 pt2=segment (Default: pt2_version=1)
Common parts of variants may be stored as segments, if the mapper thinks that it makes the relations more readable.
Remark: Segments add nothing to the expressive power of the relation system described here. Using segments may be an advantage or a disadvantage for the overview of the mapper. There is absolutely no duty to use segments.
Tags
Tags not mentioned here should not be used, except for informational ones directed to the mappers.
label Used as a name for the mappers convenience.
tour_complete The completeness of the list of ways mentioned here. The values are the same as in variant relations.
If the key is missing, the information is unknown.
stops_complete The completeness of the list of stops mentioned here. The values are the same as in variant relations.
If the key is missing, the information is unknown.
Members
The members are written as in a variant.
A segment should be interpretable after inclusion into the variant where it is used.
There is no recursion. Segments never contain segments or minivars.
Minivars
type=pt2 pt2=minivar (Default: pt2_version=1)
Variants of the route which do not introduce a different sequence of stations but just different platforms inside of a station are not stored as variants but as minivars.
Tags
Tags not mentioned here should not be used, except for informational ones directed to the mappers.
label Used as a name for the mappers convenience.
tour_complete The completeness of the list of ways mentioned here. The values are the same as in variant relations.
If the key is missing, the information is unknown.
Members
Every possibility is written as in a segment. The first member of each possibility gets a # prepended to it's role.
Every possibility of a minivar should be interpretable after inclusion into the variant where it is used (after removal of the #).
Renderers may choose to display no or just the first possibility of a minivar or limit the display of several possibilitys to high resultion maps.
Typical structure:
#halt platform A
way 1
way 2
way 3
#halt platform B
+halt platform B (another part of it)
way 4
way 5
way 6
#halt platform C
way 4
way 5
way 7
There is no recursion. Minivars never contain minivars or segments.
Zum Testen hier eine preset.xml. Das ist nur Bastelkram ... Nutzung auf eigene Gefahr. Nichts hochladen!:
<?xml version="1.0" encoding="UTF-8"?> <presets xmlns="http://josm.openstreetmap.de/tagging-preset-1.0"> <group name="PT2">
<item name="Halt"
name_template="² {pt2_name} ?{pt2_subname="-" '()' | pt2_subname="?" '(fehlt noch)' | pt2_subname '({pt2_subname})' | '(...)'}"
name_template_filter="pt2_name">
<label text="Namen:"/>
<text key="pt2_name" text="Haltestellenname" match="key!"/>
<text key="pt2_lookup" text="Suchname"/>
<combo key="pt2_subname"
text="B-Steig/Gleis"
delimiter=";"
values="-;?"
display_values="gibt es nicht; gibt es, ist aber unbekannt"
/>
<text key="pt2_groupname" text="ggf. übergeordneter Name"/>
<space />
<label text="abzulösende Angaben:"/>
<text key="name" text="name"/>
<text key="ref_name" text="ref_name"/>
<text key="ref" text="ref"/>
<text key="platform" text="platform"/>
<space />
<label text="evtl. zu ergänzende Angaben:"/>
<combo key="public_transport" text="public_transport-Angabe">
<list_entry
value="any_platform"
display_value="Ein-/Ausstiegsstelle"
short_description="Passagierposition aller Art"/>
<list_entry
value="platform"
display_value="Bahn-/Bussteig (Punkt=n.v.)"
short_description="Passagierposition. Bei Nodes: kein
B-Steig vorhanden"/>
<list_entry
value="stop_position"
display_value="Fahrzeugposition(auf dem Weg)"
short_description="Halteposition des Fahrzeugs (auf dem Weg)"/>
</combo>
<space />
<label text="weitere Angaben:"/>
<check key="bench" text="Bench"/>
<check key="shelter" text="Shelter"/>
<check key="tactile_paving" text="Blindenleitbelag"/>
<check key="covered" text="Covered"/>
<combo key="wheelchair"
text="Wheelchair"
values="yes,no,limited,only"/>
<text key="operator" text="Operator"/>
<text key="network" text="Network"/>
<combo key="railway"
text="railway-Angabe"
values="platform,halt,tram_stop,station"/>
<combo key="highway"
text="highway-Angabe"
values="platform,bus_stop,tram_stop,station"/>
<space />
<label text="weitere Angaben (nur für Fahrzeugpositionen):"/>
<check key="train" text="train" />
<check key="subway" text="subway" />
<check key="monorail" text="monorail" />
<check key="tram" text="tram" />
<check key="bus" text="bus" />
<check key="trolleybus" text="trolleybus" />
<check key="aerialway" text="aerialway" />
<check key="ferry" text="ferry" />
</item>
<item name="Master" type="relation"
name_template="PT2-Master ({name})"
name_template_filter="type=pt2 pt2=master">
<label text="Edit Route Master"/>
<key key="type" value="pt2" match="keyvalue"/>
<key key="pt2" value="master" match="keyvalue"/>
<combo key="vehicle"
text="Fahrzeuge"
values="train,subway,monorail,tram,bus,bus;taxi,trolley_bus,aerialway,ferry"/>
<text key="name" text="Kurzname(Fahrzeug Liniennummer)"/>
<text key="ref" text="Liniennummer"/>
<text key="retour_master_ref" text="verschiedene Liniennummer der Gegenrichtung"/>
<combo key="list_complete"
text="Vollständigkeit der Variantenliste"
values="complete,incomplete,fragmentary"
display_values="vermutlich vollständig,Stücke fehlen,
zuwenig für einen Überblick"
default="fragmentary"/>
<check key="tidal_ferry" text="tidenabhängige Fähre"
default="off"/>
<text key="operator" text="Operator"/>
<text key="network" text="Network"/>
<roles>
<role key="" text="Variante" type="relation" member_expression="pt2=variant"/>
<role key="ignore" text="Variante" type="relation" member_expression="pt2=variant"/>
</roles>
</item>
<item name="Variant" type="relation"
name_template="PT2-Variant ({ref}:{description})"
name_template_filter="type=pt2 pt2=variant">
<label text="Edit Route Variant"/>
<key key="type" value="pt2" match="keyvalue"/>
<key key="pt2" value="variant" match="keyvalue"/>
<text key="description" text="Variantenkurzbeschreibung"/>
<text key="var_name" text="Fahrzeugbeschriftung o.ä."/>
<text key="ref" text="Liniennummer"/>
<text key="var_ref" text="ggf. Variantennummer"/>
<text key="follower_ref" text="ggf. Folgeliniennummer"/>
<combo key="tour_complete"
text="Vollständigkeit des Fahrwegs"
values="complete,incomplete,fragmentary"
display_values="vermutlich vollständig,Stücke fehlen,zuwenig für einen Überblick"
default="fragmentary"/>
<combo key="stops_complete"
text="Vollständigkeit der Haltestellenliste"
values="complete,incomplete,fragmentary"
display_values="vermutlich vollständig,Stücke fehlen,zuwenig für einen Überblick"
default="fragmentary"/>
<text key="per_week" text="ggf. Fahrten/Woche"/>
<text key="hours" text="ggf. Fahrzeit"/>
<text key="operator" text="Operator"/>
<text key="network" text="Network"/>
<text key="active_from" text="als Umleitung ab (YYYY-MMM-DD)"/>
<text key="active_until" text="als Umleitung bis (YYYY-MMM-DD)"/>
<text key="inactive_from" text="gesperrt ab (YYYY-MMM-DD)"/>
<text key="inactive_until" text="gesperrt bis (YYYY-MMM-DD)"/>
<roles>
<role key="halt"
text="Halt"
member_expression="pt2_name|public_transport|railway=halt|railway=station|railway=tram_stop|highway=bus_stop"/>
<role key="+halt"
text="Halt"
member_expression="pt2_name|public_transport|railway=halt|railway=station|railway=tram_stop|highway=bus_stop"/>
<role key="haltvar"
text="halt parts of a local variant"
member_expression="pt2=minivar"/>
<role key="wayvar"
text="way parts of a local variant"
member_expression="pt2=minivar"/>
<role key="haltseg"
text="halt parts of a segment"
member_expression="pt2=segment"/>
<role key="wayseg"
text="way parts of a segment"
member_expression="pt2=segment"/>
<role key="" text="Fahrweg" type="way"/>
<role key="part" text="Fahrweg" type="closedway"
member_expression="junction=roundabout"/>
<role key="part+" text="Fahrweg" type="closedway"
member_expression="junction=roundabout"/>
<role key="OOS" text="Fahrweg"/>
</roles>
</item>
<item name="Minivar" type="relation"
name_template="PT2-Minivar ({label})"
name_template_filter="type=pt2 pt2=minivar">
<key key="type" value="pt2" match="keyvalue"/>
<key key="pt2" value="minivar" match="keyvalue"/>
<text key="label" text="interne Bezeichnung"/>
<combo key="tour_complete"
text="Vollständigkeit des Fahrwegs"
values="complete,incomplete,fragmentary"
display_values="vermutlich vollständig,Stücke fehlen,zuwenig für einen Überblick"
default="fragmentary"/>
<roles>
<role key="#halt" text="Halt" member_expression="pt2_name|public_transport|railway=halt|railway=tram_stop|highway=bus_stop"/>
<role key="+halt" text="Halt" member_expression="pt2_name|public_transport|railway=halt|railway=tram_stop|highway=bus_stop"/>
<role key="" text="Fahrweg" type="way"/>
<role key="part" text="Fahrweg" type="closedway"
member_expression="junction=roundabout"/>
<role key="part+" text="Fahrweg" type="closedway"
member_expression="junction=roundabout"/>
<role key="OOS" text="Fahrweg"/>
</roles>
</item>
<item name="Segment" type="relation"
name_template="PT2-Segment ({label})"
name_template_filter="type=pt2 pt2=segment">
<key key="type" value="pt2" match="keyvalue"/>
<key key="pt2" value="segment" match="keyvalue"/>
<text key="label" text="interne Bezeichnung"/>
<combo key="tour_complete"
text="Vollständigkeit des Fahrwegs"
values="complete,incomplete,fragmentary"
display_values="vermutlich vollständig,Stücke fehlen,zuwenig für einen Überblick"
default="fragmentary"/>
<combo key="stops_complete"
text="Vollständigkeit der Haltestellenliste"
values="complete,incomplete,fragmentary"
display_values="vermutlich vollständig,Stücke fehlen,zuwenig für einen Überblick"
default="fragmentary"/>
<roles>
<role key="halt" text="Halt" member_expression="pt2_name|public_transport|railway=halt|railway=tram_stop|highway=bus_stop"/>
<role key="+halt" text="Halt" member_expression="pt2_name|public_transport|railway=halt|railway=tram_stop|highway=bus_stop"/>
<role key="" text="Fahrweg" type="way"/>
<role key="part" text="Fahrweg" type="closedway"
member_expression="junction=roundabout"/>
<role key="part+" text="Fahrweg" type="closedway"
member_expression="junction=roundabout"/>
<role key="OOS" text="Fahrweg"/>
</roles>
</item>
</group> </presets>