Haltestellen mit Echtzeit Fahrplanauskunft

Hmm nun ein paar ähnliche Anwendungen gibt es ja schon.
http://wiki.openstreetmap.org/wiki/List … _Transport
Ich würde mich an deiner Stelle mit den Transiki Leuten zusammentun um da etwas draus zu machen, dass auch genutzt wird.

viw wrote:

Aber an jeder Haltestelle den ganzen Fahrplan abtippern ist nicht machbar, insbesondere weil das 2* pro Jahr recht kurzfristig erledigt werden werden muss. Die VRS alleine hat über 6000(!) Haltestellen.

Es ist sicher nicht die Aufgabe von OpenStreetMap auch noch die Fahrplandaten aller Transportunternehmungen aufzunehmen, dafür ist OSM nicht gemacht. Aber es steht dir frei an einen Projekt mitzuarbeiten, das dafür gedacht ist. Siehe dazu http://wiki.openstreetmap.org/wiki/WissensWert. Bis zum 30.Nov. kannst du sogar noch dafür abstimmen, damit es Fördergelder von Wikimedia erhält.

Wyo

Hallo !i!

ich habe bereits ausführlich über das für und wieder diskutiert. Ich persönlich habe auch versucht zur transiki Mailinglist zu schreiben, aber ich werde mir nicht einen weiteren Mailaccount bei Google zu legen nur um auf der Liste schreiben zu können.
Außerdem halte ich dieses Projekt für zum Scheitern verurteilt, sollte es so aufgebaut werden wie OSM. Der Unterschied zwischen Geodaten und Fahrplandaten ist nämlich die Häufigkeit und der Aufwand mit welchem sie geändert werden können. Ich kann mir nicht vorstellen, das jemand ein Interesse hat, jedes Jahr neue Fahrpläne für den Fernverkehr einzupflegen. Ich sehe den Aufwand bei anderen Projekten. Dort ist man seit einem halben Jahr dabei Fahrplandaten des im Dezember endenden Fahrplanjahres einzupflegen. Der Nutzen für Fahrgäste wäre hier mehr als nur fraglich!
Einziger Weg aus meiner Sicht können hier Schnittstellen sein, damit diese Daten automatisiert übernommen werden können. Aber schon bei Verkehrsverbünden werden Daten kleinerer Unternehmen nur für Änderungen von mehr als 3 Tagen in die Fahrplandatenbank eingepflegt. Bei der DB ist die Aktualisierung für Fremdunternehmen noch seltener.
Außerdem gibt es in Deutschland bereits das Projekt Delfi (http://www.delfi.de/) Dies ist ein Forschungsprojekt, welches zur Aufgabe hat oder hatte verteilte Fahrplanauskünfte zu rechnen. Dieser Ansatz wurde gewählt, da man davon ausgehen kann das einzelne lokale Services wesentlich aktueller sind, als eine integrierte Datenbank.
Außerdem hat der VDV bereits die Schnittstellen für Deutschland definiert. Für Europaweite Auskünfte gibt es den Quasistandard Hafas der Firma Hacon. Besonders fortschrittlich ist außerdem die tschechische Republik. Hier gibt es die landesweite Auskunft aus einer Hand. Allerdings ist diese beim Verkehrsministerium angesiedelt.

So aber nun zu deinen Kartenbeispielen. Die zweite Karte zeigt Minsk. Sogar in Sibieren findet man hier ÖPNV, aber wenn man auf den relevanten Bereich in Dresden zoomt, ist es eine Mapnikkarte.
Die ÖPNV karte wird derzeit leider nicht aktualisiert. Im Prinzip ist sie dem gewünschten Ergebnis schon sehr nahe. Nur werden auch hier keine Echtzeitinformationen und oder Links zu den Fahrplananbietern angezeigt. Dafür sieht man aber schon welche Linie an dieser Haltestelle hält. Leider erkennt man nicht die Richtung und außerdem wird es schnell unübersichtlich, wenn man mehrere Linienvarianten einer Linie an der gleichen Haltestelle hat.

Du siehst der gesuchte Zweck ist bei keiner Karte erfüllt. Kann er aber auch nicht, weil es hierfür weder einen deutschland- geschweige denn einen Weltweiten Standard gibt. Aber bei OSM ist es immer so, dass man eine Karte braucht um den Nutzen zu erkennen. Also muss hier eine Karte her, welche genau das tut!

Ja stimmt, ich wollte nur anregen, dass es allen vielleicht mehr bringt, wenn du dich in ein bestehendes Projekt einbringst und das verbesserst, anstatt extra neu anzufangen.
Wie wäre es denn, wenn du die ÖPNVKarte aufgreifst?

Hallo !i!

diese Idee hatte ich auch schon. Deswegen habe ich auch Kontakt zu Melchior aufgenommen und er war so freundlich mir die Serverfiles zu schicken. Nur habe ich leider keine Ahnung was ich damit anfangen soll, bzw. wie ich am besten anfange damit einen Server zu füttern.
Noch besser gefällt mir im Prinzip der Openstreetbrowser. Denn hier ist das Konzept, dass man sich alles anzeigen lassen kann. Die Grundkarte ist relativ nakt, aber über Menüs lassen sich alle Features anzeigen und sogar anklicken.
So werden zu Straßen die Hausnummern aufgelistet und bei Einkaufsmöglichkeiten die einzelnen Geschäfte oder Kneipen. Am liebsten hätte ich eine All in one Lösung, die nur das gerade gewünschte zeigt. Allerdings kann ich mit diesem Anspruch keine lauffähige Karte erstellen. Ich habe sogar Mühe den Mapnik zum laufen zu bekommen. Daher war ich froh über eine virtuelle Maschine, bei dem alles bereits eingerichtet war.
Dazu wollte ich einfach einen neuen Layer einbauen und dann ...
Aber das ist sehr sehr aufwendig. Nachdem ich also die Öffnungszeiten Karte entdeckt habe dachte ich das es mit Openlayers schneller realisierbar sei, aber die Ansprüche sind eben doch sehr hoch. Jedenfalls wenn man nicht für jeden neuen Zweck neu anfangen möchte.
Andere Ideen die wir hier in Dresden hatten ist eine Karte, mit der man sich nicht nur alles aus der Datenbank anzeigen lassen kann, sondern auch gleich noch Zugriff auf Openstreetbugs und die anderen Qualitätssicherungstools hat.
Diese Funktion sollte eigentlich Openstreetmap.org oder .de liefern. Es gibt eine unendliche Sammlung von Karten und Tools. Aber für Außenstehende ist das weder nachvollziehbar noch erreichbar. Bei Google habe ich eine Anwendung maps.google.xxx von dort erreiche ich alels was mit der Karte zu tun hat. Geländeansichten, Sattelitenbilder, die Karte, Routenplaner, Streetview.

!i! wrote:

....
Wie wäre es denn, wenn du die ÖPNVKarte aufgreifst?

Den selbigen Gedanken hatte Markus nachdem er Melchior Moos kontaktierte.

Da die ÖPNVKarte momentan nicht weiter gepflegt wird hat sich Markus die Mühe gemacht und eine neue gemacht. Die ist seit Mittwoch online. Bitte nicht gleich los meckern, er hat nur beschränkte Hardware und alles ist noch nicht gerendert. Momentan werden jede Nacht die Zoomstufen 12-15 neu gerendert. Beim Rest schafft sein Rechner nur 7% der Fläche Deutschlands in einer Nacht zu rendern. Für konstruktive Kritik ist er aber dankbar.
Testet auch mal den + Knopf rechts oben.

Markus, hoffentlich geht jetzt dein Server nicht in die Knie.

http://openptmap.de/

st

Ich finde die für ein so frühes Stadium schon recht gut 🙂

@viw Genau das ist ja der Punkt, es steckt unglaublich viel Arbeit und auch KnowHow in so einer Karte, da wäre es einfach schade, wenn sich 3 Leute unabhängig von einander dran setzen und so an der Arbeitslast scheitern 🙁

Also diese Karte ist ausgezeichnet. Es fehlen allerdings noch Buslinien. Ich habe die Befürchtung, dass nicht alle Tags gerendert werden. nach dem ÖPNV Schema gibt es auch Relationen public_transport=line bzw. linevariant
Streng nach dem Shema müssten alle linevariant ohne angabe von ref auskommen, da diese in der übergordneten Relation mit line zu finden ist. Aber es stellt wohl ein großes Problem für das rendering dar, wenn nicht die Relationen direkt die Informationen enthalten. So war es zum Beispiel in der ÖPNV Karte nötig alle Relationen von linevariant zusätzlich entweder mit route oder line und dann einer ref zu versehen. der Openstreetbrowser hat ebenfalls Probleme damit.
Openstreetmap.org rendert auch keine Zugangsstellen, welche public_transport=platform getagt sind. Hier müssen immer noch highway=bs_stop, railway=tram_stop oder railway=platform dazu. Letzteres stellt Openstreetmap.org auf korrekt für Flächen und Multipolygone dar. Hieran scheitert Openstreetmap.de immer noch. Nachteil dieser Flächen: Straßen und Fußwege werden darüber gelegt. Egal in welchem Layer und ob bridged=yes.
Daher habe ich in Dresden angefangen Bahnsteige als Multipolygone zu erstellen. Dies ist auch recht sinnvoll für die Bezeichnung, da sich Mittelbahnsteige immer zwei Gleise teilen und es keine Unterscheidung wie in Tschechien zwischen Bahnsteig und Gleis gibt. (Ist aus Kundensicht auch unübersichtlicher Bahnsteig A mit Gleis 1 und 2.) Das Multipolygon hat den Vorteil, dass die Grenzen aus verschiedenen linienförmigen Objekten bestehen können. So sind die Bahnsteigkaten bei mir railway=platform mit name=*, da Openstreetmap.org eine ref=* nicht rendert und die sonstigen Grenzen sind und getagte Wege. Allenfalls an Treppenaufgängen sind diese Linien mit foot=yes getagt. Ob das dem Navi hilft weiß ich aber nicht. Das Multipolygon hat dann wieder railway=platform.
So stellt Openstreetmap.org zwei Bahnsteige auch über der Straße dar und malt Zwischenräume grau aus. Openstreetmap.de stellt nur die Bahnsteigkanten dar. http://www.openstreetmap.org/?lat=51.06 … 8&layers=M

!i! wrote:

@viw Genau das ist ja der Punkt, es steckt unglaublich viel Arbeit und auch KnowHow in so einer Karte, da wäre es einfach schade, wenn sich 3 Leute unabhängig von einander dran setzen und so an der Arbeitslast scheitern 🙁

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.

viw wrote:

Mir schwebt eher vor eine Haltestelle hervor zu heben. Je nach Verkehrsmittel mit einem anders farbigen H-Symbol. Das Popup ist dann mit einer Internetadresse verknüpft. Dahinter versteckt sich dann wieder ein Skript (diese sind schon fertig) welches dann andere Webseiten gefiltert darstellt. Da wäre http://reiseauskunft.bahn.de/bin/bhftaf … &start=yes oder http://www.vvo-online.de/de/fahrplan/ab … o/33000028

Interessant für mich ist eine Anwendung ähnlich wie diese: http://www.vvo-online.de/de/tourismus/s … index.aspx
Zoomt man hier weiter rein, werden die Haltestellen angezeigt und die nächsten Abfahrten an der Haltestelle. Leider ist für jede Haltestelle nur ein Punkt, so dass man nicht herausfindet wo jetzt welcher Zug, Bus oder Straßenbahn abfährt.
Um dem Verkehrsverbund zu zeigen, wie dies besser geht hatte ich mir gedacht einfach mal eine solche Karte zu erstellen. Leider klappt das alles noch nicht ganz wie gewünscht.

Als Vorarbeit ist es sicherlich noch erforderlich eine lokale OSM Datenbank aufzusetzen, da es erforderlich ist, zu jeder Haltestelle ersteinmal herauszufinden, welche Linie mit welcher/n Richtung/en dort verkehrt.

Ich hoffe das war jetzt soweit verständlich.

Sorry, ich bin wohl manchmal etwas schwer von Begriff :-(

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

Gruß Wolf

Netzwolf wrote:

Ich sprach von der *internen* Darstellung. Dass die nicht trivial einzugeben ist, ist mir klar.

Aber an jeder Haltestelle den ganzen Fahrplan abtippern ist nicht machbar, insbesondere weil das 2* pro Jahr recht kurzfristig erledigt werden werden muss. Die VRS alleine hat über 6000(!) Haltestellen.

Eben wegen dieser immer wieder notwendigen Aktualisierung halte ich es für schlau, die Fahrpläne unabhängig von den Haltestellen zu speichern, möglicherweise in Relationen (sofern man irgendwie vermeiden kann, von den "Erfindern" der Relationen dafür gelyncht zu werden), möglicherweise in einer getrennten DB, und daraus die Daten für die Haltestellen abzuleiten und automatisch einzutragen.

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,

Fabi2 wrote:

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.

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/os … lid=403521

Fabi2 wrote:

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...

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 :-)

Fabi2 wrote:

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.

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

Netzwolf wrote:

Sorry, ich bin wohl manchmal etwas schwer von Begriff :-(

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

Gruß Wolf

Also ich finde die Karte total Klasse, aber jetzt beginnt der Ärger. http://www.netzwolf.info/kartografie/os … ayers=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,

viw wrote:

Also ich finde die Karte total Klasse, aber jetzt beginnt der Ärger. http://www.netzwolf.info/kartografie/os … ayers=B00T
Die Haltestelle Ursulaplatz hat Haltestellen in zwei Richtungen. Aber die Anzeige ist für beide Richtungen mit den selben Abfahrten

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

viw wrote:

Der Stand so wie du ihn hast zeigt mir jetzt schon alle Haltestellenmasten an.

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.

viw wrote:

aber noch nicht die Abfahrten für den konkretten Mast. Dafür müsste man jetzt rausfiltern welche Richtungen an welchem Mast halten.

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

viw wrote:

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.

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.

Netzwolf wrote:

viw wrote:

Der Stand so wie du ihn hast zeigt mir jetzt schon alle Haltestellenmasten an.

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.

viw wrote:

aber noch nicht die Abfahrten für den konkretten Mast. Dafür müsste man jetzt rausfiltern welche Richtungen an welchem Mast halten.

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

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... ;-)

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.

viw wrote:

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.

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.

viw wrote:

Also ich würde ehrlich gesagt nicht die H-Tafeln als Stopposition wählen sondern die Mitte des Bahnsteiges.

So wird das aber im Moment soweit ich weis noch von den Eisenbahnern gemappt.

viw wrote:

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.

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.

viw wrote:

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.

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.

Netzwolf wrote:

Fabi2 wrote:

Das Oxomoa-Schema unterstützt ja bereits Relationen für Linienvarianten und die gesamte Linie (evtl. bestehend aus mehreren Linienvarianten), da braucht man also nur noch den Fahrplan zu intergrieren.

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.

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

Netzwolf wrote:

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

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,

viw wrote:

ich weiß nicht ob IBNR ausreicht.

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.

viw wrote:

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.

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.

viw wrote:

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.

Ich hab die Seite mal um das Auslesen der Relationen erweitert: http://www.netzwolf.info/kartografie/os … on=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.

viw wrote:

Achso und im Moment sind es bei dir auch nur die Bushaltestellen. Noch keine Bahnsteige wo die Züge zum jeweiligen Gleis angezeigt werden.

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

Fabi2 wrote:

Das Oxomoa-Schema unterstützt ja bereits Relationen für Linienvarianten und die gesamte Linie (evtl. bestehend aus mehreren Linienvarianten), da braucht man also nur noch den Fahrplan zu intergrieren.

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.

Fabi2 wrote:

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.

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.

Fabi2 wrote:

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)

Eine Relation je Segment halte ich für übertrieben. Die Linie 576 hat bereits in EINER Richtung 15(!) Segmente: http://www.netzwolf.info/kartografie/os … lid=403521
Das gäbe 30 Teilrelationen, wobei einzelne Relationen nur 1 Haltestelle enthalten.

Fabi2 wrote:

Relation 2 (pro Linenvariante):
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)

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.

Fabi2 wrote:

Netzwolf wrote:

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

Siehe mein Erweiterungsversuch für das Oxomoa-Schemma oben, den hab ich gerad e 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.

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

Fabi2 wrote:

Netzwolf wrote:

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

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.

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).

Fabi2 wrote:

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.

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.

Fabi2 wrote:

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... ;-)

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,

viw wrote:

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 taktilen 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.

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

Netzwolf wrote:

Nahmd,

viw wrote:

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 taktilen 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.

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.

Netzwolf wrote:

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:
Gruß WOof

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.

Netzwolf wrote:

Ich hab die Seite mal um das Auslesen der Relationen erweitert: http://www.netzwolf.info/kartografie/os … on=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.Gruß WOof

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,

viw wrote:

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.

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.

viw wrote:

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.

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.

viw wrote:

Netzwolf wrote:

Ich hab die Seite mal um das Auslesen der Relationen erweitert:

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.

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.

viw wrote:

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.

Das hellgrau ist nur zur Anzeige der internen Abläufe. In einer "echten" Anwendung würden diese Zeilen unterdrückt.

viw wrote:

Die Idee mit den Segmenten für eine Linie ist zwar nicht schlecht, aber sie macht die Auswertung und Erstellung noch schwieriger.

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.

viw wrote:

Auch glaube ich nicht, dass du dadurch die Anzahl der Relationen reduzieren kannst, sondern lediglich die Menge der Daten in der Relation.

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.

viw wrote:

die Auswertbarkeit für den Renderer leidet.

Die Auswertbarkeit leidet nicht:
http://www.openstreetmap.org/browse/relation/403521
http://www.netzwolf.info/kartografie/op … ?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.06 … 8&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.

viw wrote:

...
IBNR taggen ist kein Problem. ...

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,

viw wrote:

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.06 … 8&layers=M

IBNR taggen ist kein Problem. Gerne werde ich auch die relationen auflösen und nach deinen Vorgaben neu taggen.

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 :-)

viw wrote:

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.

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,

EvanE wrote:

viw wrote:

...
IBNR taggen ist kein Problem. ...

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.

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,

errt wrote:

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.

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.

EvanE wrote:

Die IBNR stammen ja wohl von HAFAS und/oder DB?
Damit unterliegen sie mit großer Wahrscheinlichkeit dem Urheber- und/oder dem Datenbank-Schutz.

Netzwolf wrote:

Ich habe zu dem Thema einen Rechtskundigen™ befragt, ... 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

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,

viw wrote:

Also ich würde vorschlagen das wir uns eng an das Oxomoa Shema halten.
Daraus folgen dann jede Linienvariante hat eine Relation.

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,

trekki wrote:

Das "frei verfügbar" hast Du selbst hinein interpretiert,

"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.

trekki wrote:

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

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

Nahmd,

errt wrote:

Leider kann ich dir momentan mit einer einfacheren Darstellung nicht weiterhelfen, da ich noch nicht einmal verstehe, was du da überhaupt darstellst 😉

Frisch (na ja, nicht ganz) in diesem Thread: http://forum.openstreetmap.org/viewtopi … 24#p121224

Gruß Wolf

Hi,

Wolfs Haltestellenkarte mit Echtzeitfahrplanauskunft ist ein Quantensprung im Vergleich zu den anderen ÖPNV-Karten im OSM-Umfeld!

Was ich mich gerade frage, ob es möglich wäre, in der derselbigen auch noch den Routenverlauf einer angeclickten Linie, die im Popup einer Haltestelle erscheint, anzeigen zu lassen?

Ciao,
Frank

Netzwolf wrote:

Nahmd,

viw wrote:

Also ich würde vorschlagen das wir uns eng an das Oxomoa Shema halten.
Daraus folgen dann jede Linienvariante hat eine Relation.

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

Also so ganz verstehe ich dein Problem nicht. Wenn es am Busbahnhof Siegburg 200-300 verschiedene Linienvarianten gibt, dann gibt es auch so bei dir 200-300 Relationen. Wenn es sich bei deinen Teilstücken nur um einen Weg oder unwesentlich mehr als diesen handelt, weil ja Linien beginnen oder enden, dann ist der Aufwand doch der Gleiche oder? Lösche ich den Weg ist die Relation weg und ich muss in 200-300 die neue Relation einpflegen. Möchte ich das nicht erstelle ich den neuen Weg nehme den in die Relation auf und lösche dann den alten Weg.
Genauso kann ich aber auch den alten Weg teilen und zum neuen Weg umbauen und so bleibt er ebenfalls Member aller Relationen. Der Nachteil dieser vielen Relationen entsteht durch die vielen Linienvarianten und diesen hast du immer. Nach deinem Modell genauso wie nach dem Oxomoa Schema.

Nahmd,

viw wrote:

Also so ganz verstehe ich dein Problem nicht. Wenn es am Busbahnhof Siegburg 200-300 verschiedene Linienvarianten gibt, dann gibt es auch so bei dir 200-300 Relationen.

Falsch.

Ich sperre alle Variationen in eine Relation. Der 576 hat zwei Relation - eine für stadteinwärts, und eine für stadtauswärts. (Übrigens schade, dass wir in Deutschland noch nicht einmal einen Namen für dieses Merkmal haben – in Japan hat jeder Bus neben der Linie das Zeichen für "Aufwärts" oder für "Abwärts" stehen). Und weil eine Haltestelle normalerweise nur von der stadtau oder von der stadtein-Linie berührt wird (es gibt da seltene Ausnahmen - der 576 hat eine Haltestelle, die er in beiden Richtungen anfährt), taucht an jeder Haltestelle jede Linie einmal auf.

Wenn an einer Haltestelle 10 Linien vorbeikommen, ist die natürlich an 10 Relationen beteiligt - das ist ok und auch jedem Bearbeiter sofort einsichtig: der 510 hält hier - also ist diese Haltestelle in der 510-Relation.

Nun laufen alle (ungefähr 15 je Richtung) Variationen des 576 auf den ersten Dutzend Haltestellen parallel. Würde ich je Variation eine eigene Relation einführen, wäre jede dieser Haltestellen in jeder dieser 15 Relationen - also in der Relation "576V1", in der Relation "576V2" usw. – und das für *jede* Linie. Und Mitgliedschaft in 100 Relationen finde ich minderspaßig.

Aus diesem Grund hab ich ja gegrübelt, wie man alle Alternativen unter einen Hut bringt, und bin dabei auf die Lösung mit den Segmente und den Kursen definiert als Folge von Segmenten gestoßen. Da ich aber die Segmentzugehörigkeit nur in der "role" angeben kann ……… den Rest hatten wir schon.

viw wrote:

Wenn es sich bei deinen Teilstücken nur um einen Weg oder unwesentlich mehr als diesen handelt, weil ja Linien beginnen oder enden, dann ist der Aufwand doch der Gleiche oder? Lösche ich den Weg ist die Relation weg und ich muss in 200-300 die neue Relation einpflegen.

Nein. Weil ich eben NICHT für jede Variation eine Relation einführe.

viw wrote:

Genauso kann ich aber auch den alten Weg teilen und zum neuen Weg umbauen und so bleibt er ebenfalls Member aller Relationen. Der Nachteil dieser vielen Relationen entsteht durch die vielen Linienvarianten und diesen hast du immer.

Nein. Weil ich eben NICHT für jede Variation eine Relation einführe.

viw wrote:

Nach deinem Modell genauso wie nach dem Oxomoa Schema.

Nein. Weil ich eben NICHT für jede Variation eine Relation einführe.

Das Oxomoa-Schema ist von der Realität überfordert und muss erweitert werden.
Wenn irgendwelche Nasen nicht in der Lage sind, eine Zeile (das muss man wohl gross schreiben: *EINE* *EINZIGE* *ZEILE*) Code in eine Software einzufügen und die Weiterentwicklung eines ganzen Themenbereiches dadurch blockiert wird, ist auch das minderspaßig.

Bevor das segmentierte Tagging-Schema verurteilt wird, SCHAUT ES EUCH DOCH BITTE ERST EINMAL AN!

Also hier eine Anleitung :

(1) Druck Dir den Fahrplan aus: http://www.netzwolf.info/kartografie/os … lid=403521

Du siehst links die Haltestellennamen, dann die Fahrten, und rechts die IBNR verlinkt mit der Abfahrtstafel der DB und der Node-Id verlinkt mit JOSM-Remote, sowie das zugeordnete Segment und die Position im Segment. Nimm eine Stift und mal überall da eine Linie quer über das Papier, an der rechts der Segmentbuchstabe wechselt.

(2) Unter dem Fahrplan ist die zugehörige Relation bei OSM verlinkt, lade die in den Browser und druck sie am besten aus. Kein Panik wegen der "kurs:"-Attribute, die erkläre ich später.

(3) Schau Dir im Fahrplan die Fahrten an: die überspringen Haltestellen und enden auch früher. Du siehst aber auch, dass die Fahrten nur an Segmentegrenzen beginnen oder enden und Segmentgrenzen auch nur da sind, wo eine Fahrt endet oder beginnt → die Anzahl der Segmente ist minimal.

(4) Wähle eine Fahrt aus und färbe die mit einem Markerstift ein. Schau Dir an, welche Segmente diese Fahrt durchläuft und schreibe die Segmentkennungen (=1 Buchstabe nebeneinander). Ich nehme als Beispiel die 13:20 (S=nur an Schultagen). Die läuft über "a", überspringt b, läuft über "c" und "d", springt wieder und läuft dann über "h". Das ist also die Variante "acdh". Jede Variante ist eindeutig durch eine solche Buchstabenfolge gekennzeichnet.

(5) Jetzt guck Dir die "kurs*"-Attribute der Relation an: die Werte beginnen alle mit einer von Zahlen unterbrochenen Buchstabenfolge. Die Buchstaben geben die Variante an. Du wirst sehen, dass es die gleiche Buchstabenfolge mit unterschiedlichen eingefügten Zahlen gibt – das sind Untervarianten mit unterschiedlichem Timing. Wenn man das Timing mit berücksichtigt, hat man 28(!) verschiedene Untervarianten. Die Zahlen werden für die Zeiten im Fahrplan gebraucht – wenn Du nur wissen willst OB Du irgendwohin kommst und nicht wann, brauchst Du die nicht.

(6) Jetzt geht es auf die Suche nach dem richtigen Kurseintrag (Hinweis noch: die Kursnamen nach dem kurs: sind willkürlich gewählt): und siehe da wir finden nur den Kurs GH1.

Ich hoffe, dass die Struktur damit klar ist. Aber es geht weiter:

(7) Wenn Du den Ausdruck des Fahrplans (erste, vorletzte und letzte Spalte) und der Relation nebeneinander legst, verstehst Du wahrscheinlich sofort die Bedeutung der Rollennamen an den Haltestellen-Nodes.

(8) Wenn Du den Zeitabstand zwischen zwei Haltestellen aus dem gleichen Segment im Fahrplan (z.B. gleich Siegburg-Bahnhof (a0000) und Markt (a0003) anschaust, verstehst Du die Bedeutung der Zahl nach der Segmentangabe, als 0 und 3.

(9) Der 13:20er fährt durch die Segmente a-c-d-h. Im Kurs steht "a23c……". Jetzt schau Dir die Zeit an der ersten Haltestelle von Segment a und der ersten Haltestelle in Segment c an…

Das als kurze Einführung. BTW: Der Trivialfall von einer Variante mit fixem Timing ist natürlich enthalten: dann hat man nur das Segment a, und die Zahlen nach dem "a" in den Haltestellen-Roles geben die relative Zeit seit Beginn der Fahrt an. Hat man nur ein Segment, braucht es den Kennbuchstaben nicht. Braucht man die relativen Zeiten nicht oder will sie nicht erfassen, kann man da auch 1..N vergeben… und siehe da, wir haben die "stop_I"-Notation :-)

(10) Noch eine kurze Anmerkung zu den Zahlenfolgen in den Kursen nach der wem ersten Wort, das die Segmente auflistet: das ist eine sehr kompakte Darstellung der Abfahrtszeiten: HHMM[x] Abfahrt zu diesem Zeitpunkt an Tagen des Typs "x" (kein x=täglich, w=Werktag, a=Samstag, u=Sonntag, s=Schultag, h=Ferientag); HHMM-hhmm/HMM[x] Abfahrten zwischen HHMM und hhmm im Abstand HMM an Tagen des Typs "x". Das war aber nur eine Spielerei von mir – das könnte man nur dann pflegen, wenn man die Daten in einer maschinell lesbaren Form bekäme und per Robot einspielte – händisch ist das illusorisch. Und natürlich würde ich sie dann als "service_times" einpflegen.

Was sichtbar geworden sein sollte:

bunte Striche in die Karte malen ist eine vergleichsweise einfache Übung (http://www.netzwolf.info/kartografie/op … ?id=411879). Der nächste Schritt ist ein großer. Sogar ein sehr großer.

ÖPNV ist nicht trivial.

Ich danke fürs Zuhören.

Wolf

Moin moin,

kellerma wrote:

Was ich mich gerade frage, ob es möglich wäre, in der derselbigen auch noch den Routenverlauf einer angeclickten Linie, die im Popup einer Haltestelle erscheint, anzeigen zu lassen?

Prinzipiell ja. Da aber Varianten der gleichen Linien das gleiche Ziel haben können (unterschiedliche Strecken, die sich aber wieder treffen), braucht es Zusatzinformationen.

Folgendes habe ich zur Verfügung:
→ meine Node-Id: darüber kann ich prinzipiell alle Routenrelationen erreichen, die über meinen Punkt laufen.
→ ein IBNR-Tag an der Node: damit kann ich Verkehrinformationen abrufen (ob ich das darf, ist noch eine ungelöste Frage). Da bekomme ich eine Liste von Verbindungen, die aus Abfahrtszeit, Liniennamen und Ziel-IBNR bestehen. Im Fall von Variationen mit gleichem Ziel reichen alle diese Informationen nicht, um die richtige Relation heraus zu suchen. Ergo auch keine gezeichnete Route.

Aber: bei der DB kann man (ob man darf?) zu einem Eintrag einer Abfahrtauskunft auch eine Liste aller Haltestellen der Route abgreifen. Damit kann man recht einfach die passende Route heraus suchen.

Hätte ich die Routen mit Zeiten erfasst wie im Vorposting beschrieben (was aber wie gesagt nicht wartbar ist), könnte ich natürlich die gesamte Abfahrtstafel der Haltestelle selbst erstellen und wüsste auch für jede Fahrt den weiteren Fahrtverlauf. Das ist aber unrealistisch. Vielleicht ist es möglich, einzelne Verkehrsverbünde oder meinethalben einzelne Verkehrsbetrieb dazu zu bringen, ihre Daten herauszugeben und/ober eine API für solche Anfragen bereitzustellen. Damit könnte man einiges an Mehrwert erzeugen. Und das könnte auch, wenn es herum spricht und angenommen wird, ein Selbstläufer werden.

Aber fangen wir klein an: (1) feststellen, ob wir die IBNR bedenkenlos nutzen können und (2) soviel Haltestellen wie möglich damit taggen.
Allein damit ist schon viel machbar.

Gruß Wolf

Netzwolf wrote:

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

Und du bist dir sicher, dass diese Daten cc-by-sa-lizensiert sind?

Nicht alles, was man online findet, darf auch in unsere Datenbank.

Gruß,
ajoessen

Netzwolf wrote:

Was sichtbar geworden sein sollte:

bunte Striche in die Karte malen ist eine vergleichsweise einfache Übung (http://www.netzwolf.info/kartografie/op … ?id=411879). Der nächste Schritt ist ein großer. Sogar ein sehr großer.

... und ich denke mal, keine allzugroße Anzahl Mapper wird dieses Schema verstehen und anwenden.

KISS -- keep it short and simple

Gruß,
ajoessen

Moin,

ajoessen wrote:

Netzwolf wrote:

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.

Und du bist dir sicher, dass diese Daten cc-by-sa-lizensiert sind?

Nicht alles, was man online findet, darf auch in unsere Datenbank.

Wenige Postings vorher: http://forum.openstreetmap.org/viewtopi … 28#p121528

Und: nein, ich bin mir nicht sicher, ob die Daten cc-by-sa-lizensiert sind.
Ich bin mir noch nicht einmal sicher, ob die überhaupt eine Lizenz brauchen.

Gruß Wolf

Nahmd,

ajoessen wrote:

Netzwolf wrote:

Was sichtbar geworden sein sollte:
bunte Striche in die Karte malen ist eine vergleichsweise einfache Übung (http://www.netzwolf.info/kartografie/op … ?id=411879). Der nächste Schritt ist ein großer. Sogar ein sehr großer.

... und ich denke mal, keine allzugroße Anzahl Mapper wird dieses Schema verstehen und anwenden.

Du hast meine Anleitung einmal nachvollzogen?

Du hast die Hinweise darauf gelesen, wo Infos enthalten sind, die nur für einen weitergehenden Schritt gebraucht werden?

Du hast eine einfachere Darstellung?

ajoessen wrote:

KISS -- keep it short and simple

Sprüche klopfen kann ich auch:

Alles so einfach wie möglich – aber nicht einfacher! (Einstein)

Gruß Wolf

Hallo Wolf,

ich verurteile dein Schema doch gar nicht! Vielmehr entspricht es dem was eine moderne Datenbank in einem Fahrplanprogramm ausmacht. Dort gibt es für jede Variante eine Streckenfolge und verschiedene Fahrzeitprofile und gegebenenfalls noch fahrtspezifische Fahrzeiten.
Was du hier in der Relation mit dem Kurs machst, ist nichts anderes als eine weitere versteckte Relation für jeden Kurs. Denn du fasst hier einfach Segmente in einer bestimmten Reihenfolge zusammen.
Das heißt bei dir gibt es Segmente die eine Relation bilden. Das wäre die erste Relation, welche im schlimmsten Fall nur eine Strecke betrifft. Dann gibt es bei dir eine Linienvariante (Kurs) welche eine Zusammenfassung der einzelnen Segmente darstellt. Du machst die Zusammenfassung nicht in einer Relation für die Linienvariante, sondern in einem Feld in dem du die Namen (Member) in der richtigen Reihenfolge aufschreibst. Diese Kurse(Linienvarianten) werden dann in einer Richtung(bei dir als Linienvariante) zusammengefasst. Diese beiden Richtungen sind wiederum in einer Relation der Linie zusammengehalten.
Das Oxomoa-Schema ist nicht derartig stark gegliedert. Hier werden einfach für jeden deiner Kurse eine Relation angelegt, in dem jeder Weg und jede Haltestelle Mitglied ist. Diese Linienvarianten werden dann in einer Relation zusammengefasst, welche dann jeder Linienvariante als Rolle die Richtung hin oder zurück zuweist.
Warum dies unübersichtlicher sein oder ein Mehraufwand darstellt, weiß ich aber nicht.
Kurz: Oxomoa: eine Relation je Fahrtweg von Anfang bis Ende. Diese Relationen werden in der Linienrelation zusammengehalten.
Schema der Segemente: eine Relation je Segment. Die benötigten Segemente werden über Kurse zusammengefügt. (man kann hier auch eine Relation für jeden Kurs machen) Diese sind dann in der Relation für die Richtung einer jeden Linie gespeichert. Diese wiederum gehört dann mit der Gegenrichtung in eine Linienrelation.

Ich hoffe ich habe dein Schema soweit verstanden. Sollte ich etwas falsch interpretiert haben, bitte ich um einen Hinweis.

Ich sehe das auch so. Alles, was dein Schema tut, ist Informationen, die Beziehungen ("Relationen") darstellen, in ein Tag zu packen. Das spart zwar Platz in der Relationsliste und sicher auch Aufwand beim Bearbeiten, aber etwas völlig anderes ist es nicht. Und es nutzt Attribute zweckentfremdet. Ich denke, wenn Relationen immer "normaler" werden und die Relationseditoren sich verbessern, sollten wir hoffentlich kein Problem mehr mit 200 Linien-Relationen an einer Haltestelle haben. Denn ich sehe eine Entwicklung hin zu mehr Relationen, siehe z.B. Fahrspuren- bzw. "straßenbegleitende Wege"-Problem. Wir müssen uns von Node, Way und Attribut als Basis lösen - die meisten Dinge in der Realität sind Beziehungen und die Grundform, diese darzustellen, ist die Relation.

Hi,

hier in der Metropolregion Nuernberg sind wir in der gluecklichen Lage,
dass uns der VGN alle Daten auf seiner webseite zur Verfuegung stellt.

Da Fahrplaene abtippen doof ist, kenn jemand proggies, welche Tabellen in PDFs direkt und strukturiert auslesen kann, d. h. ohne Umweg einscannen/OCR?

Grazie.

Ciao,
Frank

Hallo,

das Omnipage wäre in der Lage jedenfalls bei bestimmten Pdfs daraus eine XLS Tabelle bzw. eine CSV zu erstellen. Ob das allerdings auch bei der VAG klappt ist fraglich.
Dann wäre noch interessant was du damit vor hast. Möchtest du damit die Linienvarianten bauen oder gar ganze Fahrpläne einlesen wie unser Wolf das probehalber getan hat?

Hallo Wolf,

was passiert eigentlich mit deinem Schema, wenn jetzt eine neue Haltestelle hinzukommt?

Oder auch, wenn sich der Weg einer oder mehrerer Alternativen verändert? Da gibt es bei dir mindestens genauso viel Arbeit wie bei einem mit Relationen arbeitenden Modell.

Netzwolf wrote:

ÖPNV ist nicht trivial.

Full ACK!

Danke für die Formatdoku, bis zu den Segmenten und Minutenoffsets des Segments bin ich ja noch gekommen, aber das war es dann auch...!

Jedenfalls ist mir beim länger drüber Naachdbneken aufgeggangen, das man auch ohne die Sprunglücken, mit Relationen da wirklich nicht weiter kommt, zumindest nicht ohne das das unüberschaubare und umständliche Ausmaße annimmt. Jede Haltestellenauslassung ist dann noch nen neue Linenvarianten auf an für sich der gleichen Strecke... viel Spaß beim mappen der Lineinvarianten und Segmente mit Relationen!
Gut das Format ist im Moment nicht gerade leicht verständlich, aber unter 1000 Relationen für z.B. 5 solchen Linen die für die passende Lieneinvariante und die passenden Segmente zu dfinden wird auch nicht gerade einfach, außerdem darf man abgesehen von der umständlichen Bedienung etliche Daten redundant eingeben.

Netzwolf wrote:

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".

Na klasse, aber bei diesen tollen Regeln, haben die bestimmt auch keine elektronische Fahrplanauskunft oder?

Netzwolf wrote:

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.

Ja, die Daten aktuell zu halten, so daß sie als Ersatz für die richtige Fahrplanauskunft dienen können, halte ich auch nahezu unmöglich, einfach auf grund der menge und Komplexität des/der ÖPNV-Modelle.
Deshalb wollte ich ja auch die besser-als-Nicts-Fahrplanauskunft haben: die arbeitet im wesentlichen nur mit den Durchfahrtszeiten, der ersten und der letzten Fahrt und den Taktzeiten, weil im Mittel warte ich dann pro Umsteigen die halbe Taktzeit auf den Anschluß und wenn ich oft genug umgestiegen bin, nährt sich das die Fahrzeit immer mehr der Realität an. ;-) Nee, das Ziel ist da: überhaupt noch ankommen, nicht unbedingt in getunter Optimalzeit. Außerdem kann zusätzlich in Berlin z.B. kann und wurde für eine S-Bahn Station 3 min und für eine U-Bahn-Station 2 Minuten Fahrzeit angenommen werden, damit rechne ich auch heute noch überschkläglich die ungefähre Fahrzeit aus. Wenn man solche Erfahrungwerte aus den Verbünden hat, brauchte man nicht mal mehr undebingt noch die Haltestellenoffsetzeiten, wobei man in Berlin mittels Ampelmainpulationen nach hift, um auf ungefähr kostante Fahrzeiten (die gibts inzwischen zwar nicht mehr, der Grund ist aber das kaputt sparen der Verkehrsinfrastruktur) zu kommen.

Netzwolf wrote:

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.

Naja, manche Leute schaffen ja auch nicht mal zu verstehen, das die stop_area beim Oxomoa-Schema die Gesamtmenge alle gleichbenannten Teilhaltestellen (bestehend aus platform + stop_position) ist. Siehe http://wiki.openstreetmap.org/wiki/Prop … _Transport und die Spec: http://wiki.openstreetmap.org/wiki/%C3%96PNV_Schema.

Fabi2 wrote:

Deshalb wollte ich ja auch die besser-als-Nicts-Fahrplanauskunft haben: die arbeitet im wesentlichen nur mit den Durchfahrtszeiten, der ersten und der letzten Fahrt und den Taktzeiten, weil im Mittel warte ich dann pro Umsteigen die halbe Taktzeit

jaja, in der Großstadt/Ruhrgebiet.
Bei uns auf dem Land wartest Du nach 07:30 Uhr, wenn die Schüler & Pendler weg sind, erst mal 3 bis 4 Stunden, bis der
nächste Bus aus Kleinstadt wieder kommt. Nix "halbe Taktzeit" 😉

Ciao,
Frank

viw wrote:

Hallo Wolf,

was passiert eigentlich mit deinem Schema, wenn jetzt eine neue Haltestelle hinzukommt?

kommt drauf an 😉
Wir nehmen mal an für die Busroute 576 wird an der Abzweigung "An den Tongruben" eine Bushalte errichtet.
Dann änderst Du das Segmant 'a' dahingehend ab, dass Du einen member
Knoten An den Tongruben (12345678) als stop:a:09
in der Relation hinzufügst.

Dauert es durch die neue Haltestation länger, muss der Rest des Segments auch mit angepasst werden,
ditto die kurs*, falls die mitbenutzt werden.

Ciao,
Frank

Eine Änderung am Ende eines Segmentes ist mir zu trivial. Wenn die Haltestelle im Segment dazukommt, vielleicht noch in einem längeren, fängt man an alles neu zu nummerieren.
in eine Relation wird einfach der Member eingefügt fertig. Und wenn sich durch die Neue Haltestelle noch neue Segmente Bilden wird es sicher nicht einfacher, als alle Relationen anzupassen.
Also wenn man hier die Ballungsräume betrachtet, dann gibt es nur wenige Linienvarianten je Richtung. Im Regionalverkehr ist dies zweifels ohne anders.
Für eine grafische Darstellung reicht es auch aus alle Ways und Nodes in eine Relation des Types route zu stecken. Dabei gehen aber dann die Information des/r Fahrziels/e verloren. Damit wäre eine Auswertung nach Haltestellensäule nicht mehr möglich, sondern nur noch nach Stoparea. das wiederum bekommt der Verbund bei uns auch alleine hin, so dass ich ihn nicht mit einem Mehrwert überzeugen könnte.

kellerma wrote:

jaja, in der Großstadt/Ruhrgebiet.
Bei uns auf dem Land wartest Du nach 07:30 Uhr, wenn die Schüler & Pendler weg sind, erst mal 3 bis 4 Stunden, bis der
nächste Bus aus Kleinstadt wieder kommt. Nix "halbe Taktzeit" 😉

Doch halbe Taktzeit, aber ich hatte natürlich vorrausgesetzt, das der Takt im betrachtetem Zeitraum konstant ist. Bei einem 4 Srunden Takt würde ich da also im Normalfall erst mal 2h stehen und wenn ich Kann, da dann auch nur im Norfall langfahren und auf Strecken/Verkehrsmittel mit engerem Takt ausweichen, sofern es sich bei denen nicht gerade um die Karawane der Schnirkelschneken handelt. ;-)

Ich habe noch ein Beispiel gefunden, wo dieses Schema nicht vorteilhaft ist.
Wenn es Expressbusse gibt, welche zwar die gleiche Liniennummer besitzen, aber nicht alle Haltestellen bedienen. Hier wird die Zahl der Segmente drastisch erhöht. Obwohl der Spaß in 4 Linienvarianten abgehandelt sein könnte.