Haltestellen mit Echtzeit Fahrplanauskunft

Openstreetbrowser steht unter GPL als git zur Verfügung. Man müsste nur eben etwas mit dem Quellcode anfangen. Seit 2009 hat sich dort aber nichts mehr entwickelt. Auch die ÖPNV-Karte scheint gerade nicht weiter entwickelt zu werden, so dass es eigentlich kaum alternativen gibt.
Für mein dafürhalten ist es besser wenn eine Website wie openstreetmap.de einen Grundlayer zur verfügung stellt und weitere Projekte dann entweder auf diesem Server Objekte hervorheben können.
Im Prinzip macht Netzwolf mit den Öffnungszeiten nichts anderes. Hier werden einfach Objekte mit Markern hervorgehoben. Schöner wäre das vielleicht als Layer schon vom Server berechnet als Kacheln. Das Popup schickt dann nur noch eine Meldung mit seiner ID zurück und der Server generiert daraus die Antwort.
So stelle ich mir im übrigen auch die Echtzeitauskunft vor. Das Objekt meldet die ID an den Server, darauf wird in der Datenbank abgefragt welche Linien und Richtungen dort verkehren und es wird aus den genannten Seiten dann die Antwort extrahiert, so lange kein Dienst in der Lage ist bereits gefilterte Antworten zu liefern. Dies wird insbesondere Bei Ausrückefahrten schwierig, aber es ist hoffentlich zu 90% lösbar. Bei den Gleisangaben bei der DB gibt es keine Schwierigkeiten.
Wie gesagt die Skripte zu herausfiltern der Informationen hätte ich. Ob das dann legal ist, muss man mit den Datenliferanten klären, wenn wenigestens ein Beispielbahnhof mit allem ÖPNV fertig ist. Ansonsten kann man den Ansatz auch gleich fallen lassen.

Sorry, ich bin wohl manchmal etwas schwer von Begriff :frowning:

Möglicherweise schwebt Dir etwas in der Art vor http://www.netzwolf.info/kartografie/osm/bus_und_bahn/abfahrt?

Gruß Wolf

Das Oxomoa-Schema unterstützt ja bereits Relationen für Linienvariaenten und die gesamte Linie (evtl. bestehend aus mehreren Linienvarianten), da braucht man also nur noch den Fahrplan zu intergrieren.
Das Problem ist eher, das der type=* der Relationen unterscheidlich gehandhabt wird, um die alten Haltestellen mit integrieren zu können. Ein anderes Problem ist, das die orginale Definition der stop_area_group so nicht zu benutrzen ist, da sie zu sehr mit Blick auf die reinen Datenbank-ErsatzGIS-Fahrplanauskunftskrücken wie HAFAS erstellt wurde, welche die Umsteigebeziehungen und Zeiten mangels fehlender Verortung der Haltestellen als Zeiten mit in der Datenbank speichern müssen. Außerdem rechtfertigt ein anderer Haltestellenname nicht mehr den Einsatz der stop_area_group-Relation, weil die Haltestelle ist ja, wie der Name sagt, eine ganz andere, das sie räumlich nur 50m neben Haltestelle x liegt und man da deshalb gut umsteigen kann, , bekommt ja jeder Router leicht aus den Geokoordinaten heraus. Transiki wollte wohl auch wieder Umsteigezeiten erfassen…

Die “Erfinder” der Relationen werden sich sicher erst recht über meine Subrelationen von anderen Relationen, freuen, wobei die Subrelationen nicht immer Objekte enthalten. Leider lassen sich aber auf andere Weise Baumstrukturen in OSM nicht (gut) darstellen. Aber das macht ja die Linienrelation auch schon…

Für die interen Darstellung (wo auch immer, weil in der OSM-DB müssen die Daten wegen der Wartung, ja leicht menschenverifizierbar sein), ist dein Vorschlag natürlich völlig in Ordnung. Die Fahrpläne sollte man auch leicht auf diesabled stellen können bzw. sollte man den Gültigkeitszeitraum angeben können (ist aber leider nicht immer möglich), denn die Wahrscheinlichkeit das Ferienfahrplan Osterferien sich nicht sehr von Ferienfahrplan Sommerferien für die gleiche Linienvariante unterscheidet ist aus meiner Sicht recht hoch.

Aus meiner Sicht sollte OSM nicht unbedingt ein Ersatz für die versäßliche Fahrplanauskunft der Anbieter sein, sondern eine besser-als nichts-Fahrplanauskunft. Mir reicht da pro Linienvariante schon die erste und letzte Fahrt und die mittlere Taktzeit mit Standardabweichung, um zu wissen, ob ich da überhaupt noch weg komme. Da ist auch egal, ob bei gleichem Takt, die Zeiten geringfügig verschoben wurden, weil mal gerade ein Fahrplanupdate die Zeiten um 8 Minuten verschoben hat. Ich kann damit immer noch halbwegs verläßlich meien Weiterfahrt planen, wenn ich unterwegs im Busch bin und keinen Internetzugang habe.

Aus meiner Sicht ist es nicht sinnvoll, die Fahrplandaten von den Linienvarianten zu trennen. Wenn man das vor hat, braucht man sowieso wieder eine eindeutige Haltestellen-ID pro Einzelhaltestelle um den passenden Fahrplan in der exterenen datenbank zu finden. Leider sind ja da die vorhandenen Systeme wie IBNR etc. auch nicht durchgängig anwendbar, bzw. konkurrieren mehrere Nummerierungssysteme, sofern sie die Haltestelle überhaupt abdecken.

Nahmd,

Yepp. Und ich habe bereits alle Buslinien von und nach Siegburg und Hennef nach Schema erfasst.

Einige Buslinien (insbesondere der 576 und der 577) haben eine überraschend große Anzahl von Routenalternativen. Ich habe mir da mal die Mühe gemacht, die Buslinien je Richtung in eine minimale Anzahl von “Segmente” zu teilen, so dass jede Haltestelle und jedes Wegstück exakt einem Segment zugeordnet ist, jedes Segment von einer Alternative vollständig oder gar nicht durchlaufen wird, und jede Routenalternative durch eine eindeutige Folge von Segmenten dargestellt wird.

An dieser Stelle habe ich das Schema erweitert:

  • die Rollenangabe für die Wege um die Segmentnummer (mit “:” abgetrennt)
  • die Rollenangabe für die Haltestellen um Segmentnummer und einen Minutenoffset gegenüber dem Beginn des Segments
  • für jede Routenalternative ein Attribut an der Relation, das die Segmente dieser Alternative auflistet

Damit ist die Linie mit allen Alternativen eindeutig beschrieben.

Eine Beispielrelation sieht dann so aus: http://www.openstreetmap.org/browse/relation/403521

Ich habe den Unfug dann noch weiter getrieben und zu jeder Alternative gespeichert, an welchen Tagen zu welchen Uhrzeiten ein Bus auf der Linie startet, und mit welchem Minutenoffset er den Beginn jedes Segments erreicht. Ich weiß selbst, dass diese Information jeweils nur bis zum nächsten Fahrplanwechsel gültig bleibt, sich also nicht auf Dauer pflegen lässt. Dazu bitte keine Diskussion.

Ich habs nur gemacht, um einmal das rein aus den Daten der Relation zu erzeugen: http://www.netzwolf.info/kartografie/osm/bus_und_bahn/fahrplan?relid=403521

Ich habe übrigens auch in Siegburg und Hennef die Busse an den richtigen Busstopps halten lassen. Die Service-Wege an den Busbahnhöfen in beiden Städten sehen sehr spaßig aus :slight_smile:

Ich habe die Fahrplandaten in die Linienvarianten integriert. Das Format ist grauslich, da alles mit der berühmten “heißen Nadel” gestrickt.

Leider sind die Relationsmember mit erweiterten Rollenangabe von der ÖPNV-Karte nicht angezeigt worden, da die Rollen nicht zu den “kanonischen” gehören, und meine Bitte, die Rollennamen einfach am ersten “:” zu splitten und nur den ersten Teil auszuwerten ( name.split(‘:’)[0] in JavaScript, (split(‘:’,$name)[0] in perl, also nicht wirklich aufwendig) wurde nicht erfüllt. Deshalb habe ich meine Arbeit abgebrochen, und deshalb gibt es auch keine Doku zu Projekt und Format.

Gruß Wolf

Also ich finde die Karte total Klasse, aber jetzt beginnt der Ärger. http://www.netzwolf.info/kartografie/osm/bus_und_bahn/abfahrt?zoom=17&lat=50.81244&lon=7.16524&layers=B00T
Die Haltestelle Ursulaplatz hat Haltestellen in zwei Richtungen. Aber die Anzeige ist für beide Richtungen mit den selben Abfahrten. Der Stand so wie du ihn hast zeigt mir jetzt schon alle Haltestellenmasten an, aber noch nicht die Abfahrten für den konkretten Mast. Dafür müsste man jetzt rausfiltern welche Richtungen an welchem Mast halten. Aber im Prinzip entspricht das genau in die Richtung meiner Vorstellungen.
Ich nehme an du machst das ganz über die IBNR und die Website der DB.

Nahmd,

Ja. Diese Version benutzt ausschließlich die IBNR, um die Informationen zu beschaffen.

Ich habe die Buslinien von und zu den Busbahnhöfen Siegburg und Hennef in Relationen erfasst mit allen Haltestellen inklusive der IBNR, und bei den zuletzt erfassten auch mit den Masten (habe ich früher nicht notiert). DAS ist die eigentliche Arbeit.

Das ist bereits in den Relationen erfasst. Nur werte ich die für diese Karte nicht aus.

Ja. Leider sind nur sehr wenig Haltestellen mit IBNR erfasst.
Wobei: das könnte mal jemand mit einem Robot erledigen. Denn das IBNR-Verzwichnis gibts (zumindest für DE) zum Download.

Gruß Wolf

Hallo Wolf,

ich weiß nicht ob IBNR ausreicht. Wenn ich mir zum Beispiel den Bf Neustadt ansehe, dann sind dort 8 Masten für den ÖPNV 10 Gleise (zwei vorübergehen ungenutzt) und weitere zwei Masten einer weiteren Haltestelle. Die haben natürlich alle die gleiche IBNR. Auch kann der VVO mit der IBNR nicht viel anfangen. Dort ist aber die Echtzeitinformation abzurufen. Die Fahrplandaten bekomme ich auch bei der DB. Wobei hier dann auch wieder gerechnet werden muss. Abfahrzeit + Verspätung. Wenn man die genaue Verspätung haben möchte wird es etwas komplizierter. Denn dann muss man für jeden einzelnen Zug die Details aufrufen. erst hier verrät die DB seit neustem wieder die minutengenaue Verspätung. Aber diese Details kann man ja noch aus dem Weg räumen. Denn das wichtigste für jede HST ein Popup mit einem eigenen Inhalt ist ja bereits gemacht. Jetzt braucht es noch die Datenbank welche die restlichen Daten beisteuert.
Achso und im Moment sind es bei dir auch nur die Bushaltestellen. Noch keine Bahnsteige wo die Züge zum jeweiligen Gleis angezeigt werden.

Es sind ja leider nicht nur die Masten, sondern auch noch die unterschiedlichen Haltepunkte zu erfassen, zumindest bei den (Eisen-/Stadt-)Bahnen. Zuerst wären da die Kurzügen die halten ja meist an einem Haltepunkt in Fahrtrichtung vor dem üblichen Haltepunkt. Selbst wenn man die Zusammenfaßt, hat sich die Bahn noch solche tollen Sachen wie geteilte Züge, die zuerst gemeinsam und ab Bahnhof x dann pro Halbzug in verschiweden Richtungen fahren, ausgedacht. Zudem ist beim Bus mit Haltetasche auch nicht ganz klar, wo man den Haltepunkt denn nun genau hinsetzen soll. Auf jeden Fall brauchen wir die Haltepunkte auch noch, selbst wenn man schon standardmäßig jedes H-Schild (platform) erfaßt hat. Man muß als Mapper ja schließlich auch immer etwas vor haben… :wink:

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:

  1. 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.
  2. 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 :wink: ). 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)