Also ich habe noch keine Ahnung wo der gewöhnliche Haltepunkt getagt werden soll. Es gibt da sehr viele Möglichkeiten. Nach der Grafik im Wiki müsste man bei Bussen die Mitte der der Bustasche nehmen.
Allerdings ist es für das routing Möglicherweise sinnvoller bei Bussen die erste Tür zu wählen. Hier sind in Dresden zum Beispiel die taktielen Steine für Sehbehinderte. Rollstuhlfahrer und Kinderwagen müssen aber in die zweite Tür. Auch das ist nicht wirklich die Mitte des Busses. Bei Straßenbahnen und Zügen sieht es noch schlimmer aus.
Also ich würde ehrlich gesagt nicht die H-Tafeln als Stopposition wählen sondern die Mitte des Bahnsteiges. Bei der S-Bahn in Berlin ist es immer das Ziel so zu halten, dass der Weg zum Ausgang möglichst kurz ist. Das ist meistens in der Mitte des Bahnsteiges. Bei uns in Dresden gibt es auch gelegentlich H-Tafeln, aber die haben mit dem Halt des Zuges nur wenig gemeinsam. Oft fehlen sie ganz.
Die Zugangsstelle tagge bei Bus und Straßenbahn tagge ich immer dort wo das Haltestellenschild steht. Da werden dann auch die Infos über Papierkorb und Unterstand hinzgefügt, obwohl die räumlich verschieden sein können.
Die Anzeige würde ich so wählen das am Haltestellenschild bzw. in der Bahnsteigmitte das Popup aufgeht mit der Anzeige der jeweiligen Abfahrten. Wo genau die Spitze ist, wird sich in den meisten Fällen dann schon ergeben. Auch eine Flügelung des Zuges würde ich eher in die Hand des Reisenden und der Auskunft auf dem Bahnsteig legen. Die Dinge sind eben flexibel und nicht zweifelsfrei nachvollziehbar.
Zum Schluss soll noch ersichtlich sein an welcher Stelle jeder einzelne Kurswagen zum stehen kommt. Ich denke dafür müssten wir die Wagenstandsanzeiger kopieren. Das ist doch eher illusorisch.
Ich wäre da auch für die Spitze des Gefährtes als Haltepunkt in Analogie zu den H-Tafeln, die zumindest ja z.B. bei der Berliner S-Bahn den Haltepunkt vorschreiben. Soweit ich weis habe ich das auch bei den Bushaltestellen überwiegend so gelöst. Zum Teil habe ich auch schon die “platform” als Weg eingezeichnet. Bei Bustaschen ist sie ja eindeutig vorgegebn und bei Fußweghaltestellen nimmt man die übliche Gefährtlänge.
So wird das aber im Moment soweit ich weis noch von den Eisenbahnern gemappt.
Ja, bzw. eben als Weg eintragen, wenn das ein Betsandteil eines Fußweges ist, dann hat bei mir das highway=bus_stop pech gehabt, das man da noch aus Kompatibilitätgründen hinzufügen könnte. Zusatzfeatures wie bin=, bench= etc. klebe ich auch an die platform.
Nein, cih wollte nicht den Wagenstandanzeigen kopieren, aber wie will man vernüftig die Routen berechnen und darstellen, wenn man es mit zwei Halbzügen zu tun hat und nur einen Punkt in die Bahnsteigmitte setzt? Wie sich die behindertengerechten Eingänge und welcher Wagentyp befindet ist aus meiner Sicht im Moment auch übers Ziel hinaus geschossen.
Die Idee ist gut, für mich nicht sehr eingängig, insbesondere der Fahrplan. Ich hoffe mal ich hab es richtig verstanden. Die Idee die Strecke in die minimale Segmentzahl zu splitten komplett nachvollziehbar, das sehe dann für das erweitere Oxomoa-Scheme in etwa so aus:
Relation 1 (pro Segment):
type=public_transport
public_transport=segment
stop_offset=1,3,10-5,14 (Abfahrtszeiten-Aufenthaltszeit in Minuten relativ zum Segmentanfang)
Mitglieder: alle angefahrenen public_transport=stop_position (+ evtl. die zugehörige public_transport=platform)
Relation 2 (pro Linenvariante):
type=public_transport
public_transport=variant
departure_times=* (sinnvolles Format für die Abfahrtszeiten)
exceptions=* (Format für die ganzen Datenumsausnamen (wie “fährt nicht am x”) für dieses Linenvariante)
Mitglieder: alle angefahrenen Segment-Relationen
Relation 3: (Gesamtlinie):
Mitgleider: alle betreffenden public_transport=variant-Relationen
public_transport=variant und public_transport=linie gibt es schon, da braucht man nur noch eine Erweiterung für die Segmente
Siehe mein Erweiterungsversuch für das Oxomoa-Schemma oben, den hab ich gerade mal so aus dem Stehgreif zusammengezimmert. Da braucht die ÖPNV-Karte auch nichts zu separieren und das Ganze ist hoffentlich wenigen fehlerträchtig als die “:”-Schtreibweise von dir.
Nahmd,
Dann halt IBNR und Gleisnummer:
444652.2
Ich hatte mal die Idee einer von der IBNR unabhängigen Id für Haltestellen: eine hierarchischer Namensraum (damit man in unterschiedlichen Gebieten arbeiten kann ohne Risiko von Namenskollisionen), ähnlich wie beim DNS, nur umgekehrt geschrieben. Also beginnend mit dem Land, dann landesabhängig weiter. Für Deutschland als nächstes die Gemeindekennziffer und dann der Haltestellenname in einer kanonikalisierten Form. Gleisnummern und Bussteignummern oder selbstgemachte Kennungen (z.B. die grobe Richtung) kann man mit “:” oder “.” anhängen. Das sah dann etwa so aus:
de.57213552.hauptstrasse:s
Einige “meiner” Bushaltestellen sind noch nach diesem Schema beschriftet. Ich hab die Idee aber wieder aufgeben.
Nun irgendwie muss man die Daten zusammenführen. Und ich denke, es spricht nichts dagegen, Haltestellen&Co sowohl mit der IBNR als auch mit einer Id des lokalen Verbundes zu kennzeichnen – sofern die Id des verbundes sich nicht mit jedem Fahrplan ändert.
Ich hab die Seite mal um das Auslesen der Relationen erweitert: http://www.netzwolf.info/kartografie/osm/bus_und_bahn/abfahrt?zoom=18&lat=50.79352&lon=7.20472
Die Anzeige schaut jetzt so aus:
- Node gehört zu einer Relation → nur die Verbindungen werden angezeigt, die auch zu einer Relation gehören. Gehört diese Node zur Relation der Verbindung, Anzeige in Bold, ansonsten Anzeige in Hellgrau.
- Node gehört zu keiner Relation → nur Verbindungen werden angezeigt, die NICHT zu einer Relation gehören (in italic).
Aber Achtung! Ich habe häufig nur die Haltepositionen(=rote Punkte) den Relationen zugeordnet und NICHT die Haltestellen (H-Schild). An diesen Stellen zeigt das Haltestellenschild dann den Typ 2 an, obwohl Typ 1 angezeigt werden könnte. Das ist aber ein Tagging-Problem und hat nichts mit der Auswertung zu tun.
Guck Dir mal den Busbahnhof Siegburg an und fahr da auf die roten Punkte: da werden exakt die Busse angezeigt, die an diesem Punkt halten (denk Dir die hellgrauen Einträge einfach weg).
Gruß Wolf
Nahmd
Das Problem dabei: wenn man jede Variation als eine eigene Relation speichert und die zur Strecke gehörden Ways Haltestellen aufnimmt, sind die Ways dann Member in sehr vielen Relationen. Auf der Strecke, die den Siegburger Busbahnhof verlässt, wird wohl eine dreistellige Zahl(!) von Variationen zusammenkommen. Deshalb habe ich die Segmente eingeführt, um das überschaubar zu halten.
Wobei der Teufel da im Detail steckt - nämlich in welches Segment eine Haltestelle kommt: endet eine Alternative da, gehört sie zum "vorherigen Segment, startet da eine Route, gehört sie zum folgenden Segment, und wenn sowohl eine Alternative beginnt als auch eine Alternative endet, bildet die Haltestelle alleine ein Segment. Das lässt sich aber volautomatisch erzeugen, wenn man woher auch immer alle Routenalternativen in einer Datei hat. Hehe, das wäre eine Aufgabe für das Treffen bei der VRS irgendwann im Dezember, denen die Fahrplandaten aus der Nase zu ziehen.
Eine Relation je Segment halte ich für übertrieben. Die Linie 576 hat bereits in EINER Richtung 15(!) Segmente: http://www.netzwolf.info/kartografie/osm/bus_und_bahn/fahrplan?relid=403521
Das gäbe 30 Teilrelationen, wobei einzelne Relationen nur 1 Haltestelle enthalten.
Zu den Ausnahmen: da habe ich vereinfacht und nur Wochentag, Sa, So, und Schulferien unterschieden.
Die VRS alleine hat eine dreistellige Anzahl von Bedingungen, bundesweit dürften es eine vierstellige Zahl sein.
Da gibt es so schöne Dinge wie “außer an Markttagen in Kleinkleckersdorf”.
Weiterhin habe ich auch bei den “relativen” Zeiten in den Segmenten vereinfacht, denn die Fahrten einer Linienalternative müssen nicht alle das gleiche Timing haben:
meine beliebten Beispiele 576 und 577 fahren durch die Siegburger Innenstadt, und die vorausschauenden Planer lassen dem Bus zu den Hauptverkehrszeiten mehr Zeit. Ich habe für jedes Segment die schnellste vorkommende Fahrt benutzt und “synchronisiere” am Beginn jedes Segmentes (das ist auch der Fehler dieser Codierung - ich sollte nicht am Ende eines Segments die zusätzliche Zeit zugeben, sondern die Segmente “dehnen” – aber das nur am Rande).
Wenn ich die unterschiedlichen Fahrzeiten berücksichtigen würde, wäre ich locker bei der doppelten Anzahl Varianten. :-/
Noch eine Anmerkung: wie ich schon in einem vorherigen Posting sagte, habe ich das als “Proof of concept” gebaut und glaube nicht, dass man diese Daten auf einem aktuellen Stand halten kann.
Da die ÖPNV-Karte bei der Auswertung der Relationen ohnehin die Rollen prüfen muss, wäre es ein Klacks, die Prüfung auf das erste Subfeld der Rolle anwenden. Das ist exakt eine Zeile Code. Aber wenn die Nasen nicht wollen, wollen sie halt nicht.
Die Version mit 30 Teilrelationen für eine Richtung halte ich für schwieriger zu pflegen als eine Einzelrelation. Und sehen wir mal von den “kurs”-Einträgen ab (die Einträge sind so aufwendig, weil sie den kompletten Fahrplan enthalten), halte ich die Memberliste – zumindest wenn man sie nach den Roles sortiert – für recht übersichtlich. Aber egal was man macht: die Aufgabenstellung ist komplex, und ein naiver Anfänger wird die Eingabe nicht hinbekommen.
Gruß Wolf
Mich interessiert nur die Linienführung und (bedingt) der Fahrplan. Daher reicht mir als Granularität Bahnsteig, Bussteig oder Straßenseite des Mastes (nicht aber die mit einer IBNR gekennzeichnete abstrakte Haltestelle).
Hihi, der CNL CGN→MUC wird unterwegs irgendwo geteilt und dann mit einem anderen Zugteil zusammengefügt.
Ich weiß nicht, wie das in einer DB gespeichert ist, nehme aber einfach mal an, dass jeder Zugteil getrennt gespeichert ist mit einer Zusatzangabe, dass von A bis B die Züge X und Y eine Einheit bilden. Mit einer Bedingung drauf, dass die auf diesem Abschnitt exakt gleiche Stopps und gleiches Timing haben müssen.
Die Position des Haltepunktes ist außerhalb der Genauigkeit meines GPSr. Ich hab mal mit einem Eisenbahner gesprochen, der sich um die Kölner Bahnhöfe verdient gemacht hat: der legt den Haltepunkt in die Mitte des Bahnsteigs, alldieweil es auch bidirektional befahrene Gleise gibt (Beispiele sind das Überholgleis in Leverkusen und Richtungsänderungen in Kopfbahnhöfen, aber auch beim ICE in Köln), und er da nicht zwei Haltepunkte setzen will.
Die exakte Position der einzelnen Wagen kann man in JP eintragen, wo die Position der Türen auf dem Bahnsteig markiert sind – in verschiedenen Farben für verschiedenen Typen von Zügeni – und die Züge auch präzise da halten. In DE ist eine gewisse – ähh – “Unschärfe” zu beobachten, sei es, weil es keine Haltetafel gibt, sei es, weil der Lokführer die nicht ernstnimmt. Vom “der ICE 555 nach XXX verkehrt heite in umgekehrter Wagenreihung” ganz zu schweigen.
Ich halte es auf jeden Fall für wichtiger, erst einmal alle Haltestellen irgendwie zu erfassen. Alleine die VRS hat über 6000 davon.
Gruß Wolf
Nahmd,
Ist es wirklich sinnvoll, mit hohem Aufwand eine Genauigkeit zu erreichen, die dann höher ist als die Anhaltegenauigkeit der Verkehrsmittel? Damit ist doch niemandem gedient. Dazu kommt dann noch, dass manch schlafmütziger Busfahrer nicht selbständig die hintere Tür für einen Kinderwagen öffnet, sondern dass man zuerst sich vorne bemerkbar machen und dann nach hinten laufen muss.
Viel wichtiger erscheint mir, durchgehend alle Haltestellen mit den Angaben zu taggen, ob es einen Leitbelag gibt und ob der Zugang rollstuhlgerecht ist. Das sind die Informationen, die eine Routing-Engine braucht.
Der “Endanflug” wird ja doch optisch oder taktil erfolgen.
Gruß WOof
Hallo Wolf du hast natürlich recht. Das die Zugangsstelle wichtiger ist. Ich persönlich habe auch noch nicht erkannt wozu diese Stopposition dienen soll. Nur wenn man genauer ins Shema schaut, stellt man fest, dass sie dort möglicherweise aus Kompatibilitätsgründen zu finden ist. Denn nicht jede Stopposition hat nachher eine Haltestellentsche zur Folge, wie es grafisch dargestellt wurde. Insbesondere nicht bei Straßenbahnen.
Diese Idee finde ich nicht gut. Warum sollten wir eine neue Struktur schaffen die keiner Pflegen kann? Jeder Knoten hat eine eindeutige ID. Es ist also eher an uns diese IDs in einem weiteren Schritt mit den anderen Daten zu verbinden.
Diese Karte ist für Busse einfach genial. Nun sieht man aber deutlich das Problem, wenn man Stoppositionen als Member aufnimmt und nicht die Zugangsstelle. Denn viele Haltestellen teilen sich die Stopposition, so dass dann keine Unterscheidung in die Richtung mehr möglich ist.
Für Bahnhöfe könnte man diese Karte noch erweitern.
Das habe ich mir so vorgestellt: an jeder Bahnsteig Mitte einen Punkt an dem die Gleisspezifischen Angaben stehen und dann den Knoten amenity=train_station dann alle Züge.
Die Idee mit dem hellgrau finde ich auch sehr gut. Allerdings weiß ich nicht so genau ob es bei vielen Abfahrten vielleicht doch eher unübersichtlich wird.
Die Idee mit den Segmenten für eine Linie ist zwar nicht schlecht, aber sie macht die Auswertung und Erstellung noch schwieriger.
Auch glaube ich nicht, dass du dadurch die Anzahl der Relationen reduzieren kannst, sondern lediglich die Menge der Daten in der Relation. Im Sinne der Übersichtlichkeit ist dies aber vielleicht nicht sinnvoll, da sonst die Bearbeitbarkeit und vor allem die Auswertbarkeit für den Renderer leidet.
Moin,
Ich hab die “stop_position” deshalb ausgiebig genutzt, weil sie auf dem Way liegt. Wenn man also die Komponenten einer Strecke zusammensucht, braucht man keine Näherungssuche, sondern alle Haltepunkte sind Nodes einer der Ways, die zu der Relation gehören. Das ist eine triviale Anfrage, während die Haltestellenschilder und Häuschen neben der Straße stehen und nur über eine Entfernungssuche aufzuspüren sind.
Die interne OSM-Id aber sollte man NIE NIE NIE NIE NIE NIE niemals nutzen, um etwas externes anzubinden.
Zum einen ist die ist nicht langfristig konstant. Wie oft hat jeder von uns schon Konstrukte umgebaut, neue Knoten angelegt, Tags umkopiert. Ein Beispiel aus meiner Arbeit: wenn ein (Wander-)Wegweiser auf einer Kreuzung stehen, stelle ich ihn daneben. Also neue Node angelegt und Attribute verschoben. Und schon hat das abstrakte Objekt “Wegweiser” eine neue interne Id. Wenn der Wegweiser aber eine Kennung hat (wie die Fahrradwegweiser in NRW oder die Wegweiser des Rheinsteigs) und die in einem Attribut hinterlegt ist, bleibt diese unbeeinflusst.
Zum zweiten ist die Node-Id auf einem zu geringen Abstraktionslevel. Was heute noch mit einer Node ausgedrückt wird, sind morgen bereits mehrere Nodes (Aus einem Haltestellenschild auf der Straße werden zwei Haltestellenschilder neben der Straße und zwei Haltepunkte auf der Straße) und übermorgen eine Relation.
Die textuelle Id hatte ich konzipiert als eine problemlos dezentral in Echtzeit zu pflegende Alternative zur IBNR (die nur zentral zu pflegen ist). Aber wie gesagt: ich habe zwar hunderte Haltestellen damit getagged, bin dann aber auf die IBNR umgestiegen und habe die Idee fallen lassen.
Richtig.
Das liegt am vereinfachten Tagging. Denn zumeist liegen die Stopppositionen auf unterschiedlichen Fahrbahnen, bei einem genauen Tagging wären das also zwei getrennte Punkte.
Als gedankliches Modell für die Bus-Relationen hab ich ein Bussymbol, das den Ways der Relationen entlang sich bewegt und an den Stopp-Positionen kurz Pause macht (hehe, vielleicht baue ich das mal 
). Aus dieser Sicht erscheint mir richtig, die Stopp-Positionen in die Relation aufzunehmen, die Haltestellenschilder aber nicht (der Bus hüpft nicht mal kurz zum Haltestellenschild), sondern Haltestellenschilder und Stopppositionen “lokal” einander zuzuordnen, sei es über eine gemeinsame “PlatformId”, sei es über eine Relation. Das Fußgängerrouting führt zum Haltestellenschild, und das ÖPNV-Subsystem übernimmt an der Stoppposition.
Das hellgrau ist nur zur Anzeige der internen Abläufe. In einer “echten” Anwendung würden diese Zeilen unterdrückt.
Wenn man die Routenvariationen explizit erfassen will, geht das nicht unter einer bestimmten Mindestkomplexität. Das in dem Modell gefundene “alternative” für eine Alternativ-Route ist nicht praxisgerecht: beim 576er gibt es nicht die Hauptroute, sondern ein Dutzend gleichberechtigter unterschiedlicher Routen.
Ich benutze zur Zeit 1 Relation je Hauptfahrrichtung. Macht zusammen 2.
Sperre ich jedes Segment in eine eigene Relation, werden daraus 30.
Ein Aufteilung von Relationen ist dann sinnvoll, wenn Einzelkomponenten von verschiedenen Menschen gepflegt werden können und sollen. Eine segmentierte Busroute aber muss als Ganzes gepflegt werden.
Und: ja, das kann nur ein mit Relationen Erfahrener übernehmen.
Die Auswertbarkeit leidet nicht:
http://www.openstreetmap.org/browse/relation/403521
http://www.netzwolf.info/kartografie/openlayers/relation?id=403521
Eine Relation enthält ein Role-Feld je Member. Ich will da die Segmentierung speichern. Die ÖPNV-Leute wollen da auf korrekte Tags achten, um das Rendern von Unfug zu vermeiden. Es gibt aber nur dieses eine Feld. Also muss man sich arrangieren.
Ich bin dazu bereit: ich “klebe” nicht an dem “:” und bin gerne bereit, das Tagging an die Wünsche der ÖPNV-Leute anzupassen. Alternative wäre ein “;” wie bei den Werten zu Tags. Nur rühren sich die ÖPNVer nicht. Und wenn das aufwendige exakte Tagging dazu führt, dass die Ways nicht mehr angezeigt werden …
Übrigens: das Aufteilen in eine Relation je Segment (wohlgemerkt nicht mein Vorschlag) löst das ÖPNV-Problem immer noch nicht: denn zu den Haltestellen-Nodes will ich nicht nur das Segment speichern (das würde sich in dieser Version erübrigen), sondern auch die relative Zeit – und schon bin ich wieder beim gleichen Konflikt.
Kann vielleicht einfach mal jemand die ÖPNV-Leute mit einer Tüte Gummibären bestechen (das funktioniert zumindest bei mir immer) – oder wahlweise einmal heftigst in den Hintern treten?
Gruß Wolf
So sehr ich es gut finde, ÖPNV genauer in OSM darzustellen: Das scheint mir zu kryptisch. Tags sollten wann immer möglich menschenlesbar und auch dann verständlich sein, wenn man nicht vorher intensiv Wikiseiten zum Thema gewälzt hat.
Hallo Wolf,
ich hatte ja schon gesagt das ich die Auswertung in deiner Karte große Klasse finde. Jetzt würde ich das gerne in Dresden am Bf. Neustadt umsetzen, um dem Verkehrsverbund mal ein Beispiel zu liefern.
Dabei geht es um diesen Bereich: http://www.openstreetmap.org/?lat=51.065773&lon=13.740799&zoom=18&layers=M
IBNR taggen ist kein Problem. Gerne werde ich auch die relationen auflösen und nach deinen Vorgaben neu taggen. Aber wenn man die Straßenbahn sieht, ist die Stopposition für beide Richtungen gleich. Nur das Haltestellenschild steht eben daneben.
Mit den Fahrspuren, das ist noch ein anderes Thema. Da hatte ich breits Diskussionen mit dem Programmierer des lanetools.
Wirklich kein Problem?
Die IBNR stammen ja wohl von HAFAS und/oder DB?
Damit unterliegen sie mit großer Wahrscheinlichkeit dem Urheber- und/oder dem Datenbank-Schutz.
Nur mal so nebenbei bemerkt.
Edbert (EvanE)
Nahmd,
Ich nehme an, es geht um die Anzeige des Abfahrtsplan für eine Stopposition/Haltestelle einzelne, der sich auf die nur da abfahrenden Linien beschränkt, also die Bold/gray Popups.
Ich bin so vorgegangen:
(1) Auswahl der Routen, die an dem Projekt teilnehmen. Das war in Siegburg/Hennef kein Problem, weil ich die an meinem Projekt beteiligten Buslinienrelationen in eine Sammelrelation aufgenommen habe. Da reicht aber auch eine Liste.
(2) Aus jeder Routen-Relation bestimme ich, welche Endhaltestelle von welcher anderen Haltestellen erreichbar ist. Das ist der “Knackpunkt”.
Ich bin die “Kurse” (=geordnete Folge von Segmenten) durchgegangen und habe für jeden Kurs die Segmente zusammengefügt: das ergibt ein Array von Knoten, deren letzter die Endhaltestelle ist, die von allen anderen Knoten erreichbar ist. Das für alle Kurse zusammengeworfen und man weiss, von welchem Knoten aus welche Endhaltestellen erreichbar sind.
Du brauchst aber auf keinen Fall mein Segmentierungsschema nachzubauen. Wenn Du eine relativ einfache Struktur hast, kannst Du auch einfach den Node der Zielhaltestelle nach hinten sortieren und die ganze Relation als einen Kurs betrachten. Immer den Ball flach halten … 
(3) Zu den Endhaltestellenknoten wird die IBNR bestimmt. Jetzt weiss ich zu jeder Node, die in einer der Relationen vorkommt, welche Ziele (durch IBNR gekennzeichnet) erreichbar sind.
Das war die Vorbereitung.
Jetzt zur Nutzung, jemand klickt auf eine Haltestelle in der Karte:
(1) Die Applikation fragt beim Server an: “was weißt du zu dieser Node und dieser (Start)-IBNR”.
(2) Der Server erkundigt sich seinerseits nach den aktuellen Abfahrtszeiten für die gegebene Start-IBNR.
Er bekommt eine Liste von Verbindungen mit Uhrzeit, Liniennummer, Zielhaltestelle und (!wichtig!) Ziel-IBNR.
(3) Der Server gleicht jeden der Einträge mit seiner Liste ab: taucht die Node-Id in der Liste gar nicht auf, ist sie nicht Bestandteil einer meiner Relationen, und ich markiere den als “weiß nicht”; ist die Kombination (Node, Ziel-IBNR) in der im Vorbereitungsschritt gewonnenen Liste enthalten, dann markiere ich als “passt!”, ansonsten als “passt nicht”.
(4) Diese Liste wird an die Applikation zurückgemeldet und in das Popup eingebaut: “Passt” wird dabei zu bold, “passt nicht” zu hellgrau, und “weiß nicht” zu italic. Aber das kann man ändern
Wein ein Knoten zu mehreren gehört, dann “passt” er natürlich zu allen Verbindungen, die an einem der Endpunkte einer der Relationen enden. Das ist unvermeidlich. Du kannst aber die Haltestellenschilder auch einer Relation zuordnen, und zwar immer nur der “richtigen”. Dann zeigt das Popup auf dem Haltepunkt alle Fahrten, das Popup auf dem Haltestellenschild nur die in der passenden Richtung.
Aber noch ein Hinweis: dieser “Join” über die IBNR der Zielhaltestelle ist nicht perfekt. Dazu zwei Beispiele aus der Realität:
(1) Von A nach B fährt sowohl der Zug als auch der Bus. Sowohl an A als auch an B haben Busbahnhof und Bahnhof die gleiche IBNR. Buslinie und Zug sind per Relation erfasst. Wenn ich jetzt auf den Bussteig bai A gehe, zeigt das Popup da auch die Zugverbindungen - denn als Ziel ist die IBNR von B, und die stimmt ja auch für den Bus.
Um dieses Problem zu umgehen, muss man die im Schritt 2 der Auswertung bezogene Liniennummer mit der Liniennummer der Relation abgleichen, also wenn da RE 999 gemeldet wird und meine Relation “Bus 666”, kann das offensichtlich nicht passen. Da es aber für die Linien keine standardisierte Bezeichnung wie für die Hst gibt, ist der Abgleich eine Herausforderung.
(2) Das zweite Beispiel ist noch viel übler: Ringstrecken. In Siegburg/Hennef gibt es den Bus 510. Dessen Kernstrecke verläuft zwischen Hennef und Siegburg. Manche Variationen laufen über Siegburg weiter bis Seligenthal. Wieder eine andere Variation läuft über Seligenthal hinaus weiter bis – Tusch! – Hennef.
Wenn das Ziel einer Fahrt “Hennef” ist, dann weiß ich nicht, ob ich diese Fahrt am Linken oder rechten Haltestellenschild anzeigen soll. Das Problem stellt sich 1:1 in der Realität: hätte der Bus keine physikalische Vorzugsrichtung und wäre kugelförmig, wüsste ich nicht, in welche Richtung er fährt.
Um diese Fälle abzudecken, kann man die (unvollständige) Liste der “via”-Haltestellen nutzen, die bei der Abfrage in Schritt 2 anfällt. Damit kann ich recht genau auswählen, zu welchen Relationen eine Verbindung passt, und damit, ob sie an einer bestimmten Haltestelle angezeigt werden soll. Dazu brauche ich aber im Vorbereitungsschritt genaue Angaben zu den Streckenalternativen aus den Routen-Relationen - womit wir wieder bei den Segmenten wären.
Gruß Wolf
Nahmd,
Ich habe zu dem Thema einen Rechtskundigen™ befragt, und der meinte, eine Zahl aus einem Verzeichnis irgendwo anzupappen sei genau so erlaubt, wie ich sogar den Namen einer Stadt (ein höchstgeschütztes Gut) auf die Karte pinseln darf. Die Zuordnungsliste an sich könnte jemand als Datenbank geschützt sehen, wobei er aber nicht davon ausginge, dass das vor Gericht Bestand hätte. Aber – natürlich – der Disclaimer: das sein natürlich nur eine private Meinungsäußerung, entscheidend sei, was der Richter der letzten Instanz sagt 
Ich habe jedenfalls diese Meinung und die seit langer Zeit frei verfügbare der Liste (http://www.michaeldittrich.de/ibnr/) als Anlass genommen, auf die IBNR umzusteigen und die Idee einer OSM-lokalen Id zu verwerfen.
Gruß Wolf
Nahmd,
Dann haben wir zwei Möglichkeiten:
(1) eine einfachere Repräsentation wählen:
Das hab ich nicht geschafft. Braucht einen klügeren Kopf als mich. Wie wärs?
(2) auf die Abbildung von Routen-Alternativen verzichten.
Wenn man schon die nicht darstellen kann, braucht man sich über weitergehende Projekte wie z.B. “ungefähre” Abfahrtspläne keine Gedanken mehr zu machen. Das wäre schade.
Und jetzt?
Gruß Wolf
Leider kann ich dir momentan mit einer einfacheren Darstellung nicht weiterhelfen, da ich noch nicht einmal verstehe, was du da überhaupt darstellst 
Also ich würde vorschlagen das wir uns eng an das Oxomoa Shema halten.
Daraus folgen dann jede Linienvariante hat eine Relation. Mitglieder sind von Anfang bis Ende alle befahrenen Ways und alle Haltestellen. (ich habe an der Stelle immer die Masten genommen) Außerdem bekommt jeder Way eine Rolle für die Richtung. Die ÖPNV-Karte war so intelligent, wenn zwei Relationen in entgegengesetzter Richtung gefahren sind, dass dieser Way dann Richtungslos dargestellt wurde.
Außerdem sollen Linienvarianten nicht als alternativ gekennzeichnet werden, wenn es sich um eine weitere Hauptroute handelt. In Dresden wäre das bei der 66 der Fall. Die fährt einmal von Coschütz nach Nickern und einmal von Mokritz nach Lokwitz. Diese Linienvarianten wechseln alle 10 Minuten. Alternative Linienvarianten nach meinem Verständnis wären für Stichfahrten von Rufbussen oder Varianten die nur 1-2 Fahrten am Tag betreffen, wenn die Linie sonst vielleicht 10 mal am Tag auf der anderen Route fährt.
Die Linienvarianten sind dann gekennzeichnet mit Start und Ziel Haltestelle. (from to) Für die ÖPNV Karte benötigen sie ferner das Verkehrsmittel und Liniennummer (route=bus|tram|ligthrail|rail und ref=) Dann stecken sie in einer Überrelation in der wieder Linie Verkehrsmittel und Operator sind. Damit ist das Shema relativ übersichtlich.
Auswerten würde ich es wie folgt:
-Anfrage vom Node mit seiner OSM ID
-Abfrage ob Node rail oder lightrail yes haben (wenn ja Gleisnummer und IBNR abfragen) sonst
-Auswertung in welchen Linienvarianten ist dieser Node Mitglied.
-Daraus ergibt sich dann eine Tabelle Linie + Ziel
-Abfragen des Namens (beim VVO ist der Abfahrtsmonitor nur über eine Haltestellen ID möglich)
-Auswertung des Abfahrtsmonitors und verwerfen aller nicht vorhandener Linien-Ziel-Kombinationen
Rückgabe ist dann entweder die Auswertung des Abfahrtsmonitors (Echtzeit für Bus und Straßenbahn [gekennzeichnet mit ""]) oder die IBNR Auskunft der DB (Echtzeit für die meisten Züge) nach der Gleisreferenz gefiltert.
Die VVO Referenznummern hätte ich gerne vom VVO. Aber dafür muss ich ihm ersteinmal zeigen wie das System funktionieren soll.
Das “frei verfügbar” hast Du selbst hinein interpretiert, auf der Seite konnte ich hierzu nichts finden. Die Dateien sind ohne technische Beschränkung herunter ladbar, ob sie dadurch frei sind oder der Betreiber der Webseite hier nur die Urheberrechte nicht so genau angegeben hat, ist nicht ersichtlich. Die Fotos sind als geschützt gekennzeichnet, zu den anderen Daten habe ich nichts gefunden.
Gerade bei den Urheberrechten (bei uns auch unter dem Begriff Lizenz diskutiert) sollte auf jeden Fall Klarheit bestehen.
Wenn Du Deinem Rechtskundigen vertraust - OK. Ich teile jedoch die Bedenken von EvanE.
-trekki
Nahmd,
Damit sind die ersten Haltestellen nach dem Busbahnhof Siegburg Mitglied von 200-300(!) Relationen. Bei einer Änderung der Strecke müssen alle Relationen aktualisiert werden.
Dieses Konzept ist zum Scheitern verurteilt. Ich werde mich nicht daran beteiligen.
Gruß Wolf
Nahmd,
“Frei verfügbar” ist nicht juristisch gemeint, sondern heißt nur, dass jeder die komplette Liste herunterladen kann.
Und das offensichtlich noch niemand dagegen vorgegangen ist. Und das bei einer deutschen Domein mit Inhaberangabe,
die von Wikipedia verlinkt, also nicht etwa ein Geheimtipp ist.
Die Wahrscheinlichkeit ist hoch, dass niemand was dagegen hat.
Aber natürlich ist das keine Garantie. Rechtssicherheit schafft wie immer erst ein höchstrichterliches Urteil.
Dann schließe ich mich an und teile die Bedenken jetzt auch.
Bleibt die Frage: sind geteilte Bedenken halbe Bedenken oder doppelte Bedenken?
Gruß Wolf