Re: Zerteilte Kreisverkehre

Hi,

erwin6330 wrote:

Da ja bekanntlich Kreisverkehre in Österreich und Deutschland immer links rum gefahren werden...

Das hat nichts mit dem Problem zu tun. Die Fahrtrichtung ergibt sich aus den OSM-Daten und nicht aus der Länderzugehörigkeit des Kreisverkehrs.

Da ja bekanntlich Kreisverkehre in Österreich und Deutschland immer links rum gefahren werden, kannst Du an diesem Ausschnitt ... genau erkennen, von wo nach wo der Bus bzw. das Verkehrsmittel fährt, heißt er kommt von Süden und fährt dann Richtung Nord-Westen!

Diese Begründung ist unsinnig. Selbst wenn man garnichts über die Richtung des Kreisverkehrs wüsste, könnte man das sehen.

Es hat übrigens auch nie jemand bezweifelt, dass man beim Aufteilen der Kreisverkehre die Fahrtabfolge erkennen kann. Es ging um die Frage, ob man es ohne das Aufteilen der Kreisverkehre erkennen kann.

Wäre bei einem nichtgeteilten und einer unsortierten Relation-route nicht möglich.

Redest Du jetzt von geteilten Routen oder geteilten Kreisverkehren? Bei nicht geteilten Routen stimmt es (alle Varianten und Richtungen in einer Relation) ... aber es ging doch um geteilte Kreisverkehre.

Und wenn man seine Routen sauber erstellt...

Da muss ich mir jetzt was von der Seele reden.

Zu einer sauberen Erstellung gehört zunächst einmal, miteinander inkompatible Schemata nicht einfach zu vermischen und genau das sehe in dem genannten Beispiel.

Ich kenne drei Schemata (oder Schemafamilien) für die Darstellung von
Buslinien (Vorsicht: Vereinfachung):

1.: Die klassische Buslinie (type=route, route=bus, kein route_master):
- eine Relation für alle Richtungen und Varianten
- Roles "forward", "backward" und "" für die Fahrwege.
- Die Role "" an "Ways" steht für "bidirektional"
- Wege treten nicht mehrfach auf
- Die Reihenfolgen des Durchfahrens der Wege ist nicht immer erkennbar
- Von jeder Straße ist aber bekannt, ob sie von irgendwelchen Bussen dieser
Linie in beiden Richtungen, nur in OSM-Richtung des "Way" oder nur gegen
die OSM-Richtung des "Way" durchfahren wird. Ob das auf dem Hin- oder
Rückweg der Linie passiert ist im Allgemeinen unbekannt.
- Von den Haltestellen ist bekannt, ob sie auf dem Hin- oder Rückweg oder
beiden bedient werden. Es ist aber i.A. nicht bekannt, in welcher Richtung
sie angefahren werden.

2.: Die Line Relation (type=line, line=bus, kein Route_Master):
- eine Relation pro Variante/Richtung
- Die Reihenfolge der Wege gibt die Fahrtstrecke an und Wege treten so oft
auf, wie sie durchfahren werden.
- Die Roles "forward" und "backward" treten nicht auf.
- "" hat nicht die Bedeutung bidirektional. Sie wird für alle
Fahrstreckenelemente benutzt.
- Die Haltestellen werden wie in der klassischen Buslinie mit Roles versehen.

3.: Das Public-Traffic-Schema (type=route, route=bus, from=..., to=...,
name hat festen Aufbau mit ":" und "=>", Mutterrelation existiert und
hat type=route_master, route_master=bus, name hat festen Aufbau ohne ":"
und "=>")
- eine Relation pro Variante/Richtung
- Die Reihenfolge der Wege gibt die Fahrtstrecke an und Wege treten so oft
auf, wie sie durchfahren werden.
- Die Roles "forward" und "backward" treten nicht auf.
- "" hat nicht die Bedeutung bidirektional.
- Die Haltestellen werden mit "stop" oder "platform" getaggt. Im Gegensatz
zu den beiden anderen Schemata werden die Wartezonen ("platforms") nie
mit der Role "stop" versehen. Die Role "stop" hat also eine andere
(engere) Bedeutung als in den beiden anderen. Als "platform" sind alle
Arten von OSM-Objekten möglich (Node, Way als Linie, Way als Area, Relation
als Area)

Wenn diese Schemata vermischt werden, dann ist unklar welche Bedeutung die
Role "" für "Ways" hat und es ist unklar, welche Bedeutung die Role "stop"
für Haltestellen hat. Der "Schreiber" hat eine bestimmte Bedeutung
im Sinn und der "Leser/Auswerter" kann nicht mehr ermitteln, was es war. Die
Role wird so für alle Routen entwertet und das ist schlimm.

Weide