You are not logged in.

#1 2010-11-27 10:39:50

viw
Member
Registered: 2010-05-15
Posts: 2,623

Haltestellen mit Echtzeit Fahrplanauskunft

nach dem wir nun schon in einem anderen Thread darüber diskutiert haben, ist es an der Zeit hier jetzt einen eigenen zu eröffnen.

Netzwolf wrote:

Nahmd,

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.

Gruß Wolf

Also mal ehrlich. Ich möchte weder Transiki vorwegnehmen oder sonst irgendwie nicht aktualisierbare Fahrplandaten in Datenbanken schütten.

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.

Offline

#2 2010-11-27 11:04:47

!i!
Member
Registered: 2009-11-28
Posts: 3,311
Website

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


privater Account von KVLA-HRO-Mei

Offline

#3 2010-11-27 11:35:21

wyo
Member
From: Thalwil
Registered: 2010-08-04
Posts: 667
Website

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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

Offline

#4 2010-11-27 11:49:57

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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!

Offline

#5 2010-11-27 13:04:48

!i!
Member
Registered: 2009-11-28
Posts: 3,311
Website

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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?


privater Account von KVLA-HRO-Mei

Offline

#6 2010-11-27 13:59:06

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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.

Offline

#7 2010-11-27 14:06:03

san terra
Member
Registered: 2010-05-13
Posts: 132

Re: Haltestellen mit Echtzeit Fahrplanauskunft

!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

Last edited by san terra (2010-11-27 14:07:28)


Wer sagt: hier herrscht Freiheit, der lügt, denn Freiheit herrscht nicht. (Erich Fried)

Offline

#8 2010-11-27 14:50:19

!i!
Member
Registered: 2009-11-28
Posts: 3,311
Website

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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

@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 sad


privater Account von KVLA-HRO-Mei

Offline

#9 2010-11-27 15:07:05

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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

Offline

#10 2010-11-27 15:19:47

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Haltestellen mit Echtzeit Fahrplanauskunft

!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 sad

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.

Offline

#11 2010-11-27 15:52:20

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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

Offline

#12 2010-11-27 16:52:52

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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.

Last edited by Fabi2 (2010-11-27 17:17:40)


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#13 2010-11-27 17:31:05

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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

Offline

#14 2010-11-27 18:37:17

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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.

Offline

#15 2010-11-27 18:57:33

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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

Offline

#16 2010-11-27 19:09:00

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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.

Last edited by viw (2010-11-27 19:10:48)

Offline

#17 2010-11-27 19:43:05

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#18 2010-11-27 20:37:30

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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.

Offline

#19 2010-11-27 21:24:09

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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.


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#20 2010-11-27 22:01:27

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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.

Last edited by Fabi2 (2010-11-27 22:22:50)


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#21 2010-11-27 22:13:12

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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

Offline

#22 2010-11-27 22:50:10

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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

Offline

#23 2010-11-27 23:10:54

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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

Last edited by Netzwolf (2010-11-27 23:12:55)

Offline

#24 2010-11-27 23:21:18

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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

Offline

#25 2010-11-28 10:05:39

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Haltestellen mit Echtzeit Fahrplanauskunft

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.

Last edited by viw (2010-11-28 10:07:30)

Offline

Board footer

Powered by FluxBB