Nahmd,
Dann haben wir zwei Möglichkeiten:
(1) eine einfachere Repräsentation wählen:
Das hab ich nicht geschafft. Braucht einen klügeren Kopf als mich. Wie wärs?
(2) auf die Abbildung von Routen-Alternativen verzichten.
Wenn man schon die nicht darstellen kann, braucht man sich über weitergehende Projekte wie z.B. “ungefähre” Abfahrtspläne keine Gedanken mehr zu machen. Das wäre schade.
Und jetzt?
Gruß Wolf
Leider kann ich dir momentan mit einer einfacheren Darstellung nicht weiterhelfen, da ich noch nicht einmal verstehe, was du da überhaupt darstellst 
Also ich würde vorschlagen das wir uns eng an das Oxomoa Shema halten.
Daraus folgen dann jede Linienvariante hat eine Relation. Mitglieder sind von Anfang bis Ende alle befahrenen Ways und alle Haltestellen. (ich habe an der Stelle immer die Masten genommen) Außerdem bekommt jeder Way eine Rolle für die Richtung. Die ÖPNV-Karte war so intelligent, wenn zwei Relationen in entgegengesetzter Richtung gefahren sind, dass dieser Way dann Richtungslos dargestellt wurde.
Außerdem sollen Linienvarianten nicht als alternativ gekennzeichnet werden, wenn es sich um eine weitere Hauptroute handelt. In Dresden wäre das bei der 66 der Fall. Die fährt einmal von Coschütz nach Nickern und einmal von Mokritz nach Lokwitz. Diese Linienvarianten wechseln alle 10 Minuten. Alternative Linienvarianten nach meinem Verständnis wären für Stichfahrten von Rufbussen oder Varianten die nur 1-2 Fahrten am Tag betreffen, wenn die Linie sonst vielleicht 10 mal am Tag auf der anderen Route fährt.
Die Linienvarianten sind dann gekennzeichnet mit Start und Ziel Haltestelle. (from to) Für die ÖPNV Karte benötigen sie ferner das Verkehrsmittel und Liniennummer (route=bus|tram|ligthrail|rail und ref=) Dann stecken sie in einer Überrelation in der wieder Linie Verkehrsmittel und Operator sind. Damit ist das Shema relativ übersichtlich.
Auswerten würde ich es wie folgt:
-Anfrage vom Node mit seiner OSM ID
-Abfrage ob Node rail oder lightrail yes haben (wenn ja Gleisnummer und IBNR abfragen) sonst
-Auswertung in welchen Linienvarianten ist dieser Node Mitglied.
-Daraus ergibt sich dann eine Tabelle Linie + Ziel
-Abfragen des Namens (beim VVO ist der Abfahrtsmonitor nur über eine Haltestellen ID möglich)
-Auswertung des Abfahrtsmonitors und verwerfen aller nicht vorhandener Linien-Ziel-Kombinationen
Rückgabe ist dann entweder die Auswertung des Abfahrtsmonitors (Echtzeit für Bus und Straßenbahn [gekennzeichnet mit ""]) oder die IBNR Auskunft der DB (Echtzeit für die meisten Züge) nach der Gleisreferenz gefiltert.
Die VVO Referenznummern hätte ich gerne vom VVO. Aber dafür muss ich ihm ersteinmal zeigen wie das System funktionieren soll.
Das “frei verfügbar” hast Du selbst hinein interpretiert, auf der Seite konnte ich hierzu nichts finden. Die Dateien sind ohne technische Beschränkung herunter ladbar, ob sie dadurch frei sind oder der Betreiber der Webseite hier nur die Urheberrechte nicht so genau angegeben hat, ist nicht ersichtlich. Die Fotos sind als geschützt gekennzeichnet, zu den anderen Daten habe ich nichts gefunden.
Gerade bei den Urheberrechten (bei uns auch unter dem Begriff Lizenz diskutiert) sollte auf jeden Fall Klarheit bestehen.
Wenn Du Deinem Rechtskundigen vertraust - OK. Ich teile jedoch die Bedenken von EvanE.
-trekki
Nahmd,
Damit sind die ersten Haltestellen nach dem Busbahnhof Siegburg Mitglied von 200-300(!) Relationen. Bei einer Änderung der Strecke müssen alle Relationen aktualisiert werden.
Dieses Konzept ist zum Scheitern verurteilt. Ich werde mich nicht daran beteiligen.
Gruß Wolf
Nahmd,
“Frei verfügbar” ist nicht juristisch gemeint, sondern heißt nur, dass jeder die komplette Liste herunterladen kann.
Und das offensichtlich noch niemand dagegen vorgegangen ist. Und das bei einer deutschen Domein mit Inhaberangabe,
die von Wikipedia verlinkt, also nicht etwa ein Geheimtipp ist.
Die Wahrscheinlichkeit ist hoch, dass niemand was dagegen hat.
Aber natürlich ist das keine Garantie. Rechtssicherheit schafft wie immer erst ein höchstrichterliches Urteil.
Dann schließe ich mich an und teile die Bedenken jetzt auch.
Bleibt die Frage: sind geteilte Bedenken halbe Bedenken oder doppelte Bedenken?
Gruß Wolf
Nahmd,
Frisch (na ja, nicht ganz) in diesem Thread: http://forum.openstreetmap.org/viewtopic.php?pid=121224#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
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,
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.
Nein. Weil ich eben NICHT für jede Variation eine Relation einführe.
Nein. Weil ich eben NICHT für jede Variation eine Relation einführe.
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/osm/bus_und_bahn/fahrplan?relid=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 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 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/openlayers/network?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,
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
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
… und ich denke mal, keine allzugroße Anzahl Mapper wird dieses Schema verstehen und anwenden.
KISS – keep it short and simple
Gruß,
ajoessen
Moin,
Wenige Postings vorher: http://forum.openstreetmap.org/viewtopic.php?pid=121528#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,
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?
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?