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?
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.
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.
Na klasse, aber bei diesen tollen Regeln, haben die bestimmt auch keine elektronische Fahrplanauskunft oder?
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.
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/Proposed_features/Public_Transport und die Spec: http://wiki.openstreetmap.org/wiki/%C3%96PNV_Schema.
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
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.
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.