Ja cool 
ich glaub muss gleich updaten 
Richtig, sie fallen auf, ob es daran liegt das es bessere QA und mehr PTv2 gibt oder mehr Menschen sich um Routen kĂŒmmern oder ob es ein neues Problem ist, weiĂ ich nicht.
+1
Uih, das klingt nach Aktionismus mit eher negativem Erfolg. Deckt sich aber zu meiner Beobachtung bei der eine Route mit Schleife komplett umsortiert wurde, obwohl nur ein Weg zerteilt wurde.
Ja, sorry, das ist ĂŒbertrieben und sollte auch nur das Problem von erfahrenen Benutzenden sein. Benachbarte Wege herunterzuladen funktioniert ja sehr zuverlĂ€ssig, wenn es erlaubt wird. Insgesamt hat JOSM da einige Fortschritte in dem letztem Jahr gemacht. Mal sehen wann die andere Editor-Software nachzieht.
Wenn ich allerdings eine durchschnittliche Ăberland-Buslinie mit ihren 20-30 Varianten bearbeite, kann ich nicht alles Runterladen. Von einem Abschnitt langer BundesstraĂen, auch wenn es nur zwei bis drei TMC-Segmente sind, ganz zu Schweigen. Mit diesen Problem habt allerdings andere Editor-Software noch mehr zu kĂ€mpfen oder sind fĂŒr solche Objekte nicht geeignet.
Ich kann mir nicht so recht vorstellen, wie man z.B. einen Weg trennen kann, ohne sich die Daten im entsprechenden Abschintt komplett zu laden. Das es geht, ist mir klar. Ich wĂŒrde das nur nicht machen wollen.
Ist Ăbung und das Verinnerlichen von Ctrl+Alt+D vor jedem Aufteilen bzw. Lösen von Linien und Verschieben von Punkten. Vor jeglichem Löschen/Verbinden sowieso. Ist mit dem ganzen Wegen und Haltestellen in einer PTv1 aber nicht weniger nur komplett unĂŒbersichtlich und ungenau.
Habe bisher keine RĂŒckmeldungen auf Fehler in Bezug auf Relationen erhalten, aber das mag ja nichts heiĂen. Vielleicht wurden sie gar nicht entdeckt oder ohne Kommentar verbessert.
Ich denke, dass das Beispiel zeigt, dass die Autosortierung bei PTv2 nie gemacht werden sollte. Einen klareren Fall kann eine Autosortierung kaum bekommen und trotzdem war die Reihenfolge vor der Autosortierung richtig und ist danach falsch.
Und wenn wir bei der Autosortierung auch noch die Haltestellenreihenfolge, Oneway-Angaben usw. einbeziehen, dann werden die Fahrwege an die anderen Mappingfehler angepasst, so dass die Fehler nicht mehr auffallen.
So eine Busrelation manuell sortieren, da braucht man einen 72 Zoll Bildschirm dafĂŒr.
Man kann die Relationsteile oder die Relationen bei denen man weiĂ dass es ein einfacher Fall ist, vom Editor sortieren lassen. Nur das automatische Sortieren ist falsch.
Ich bin mal ganz ketzerisch: Sind Busrelationen nicht reine Spielerei? Mir kommt das ein bischen vor wie bei der Modeleisenbahn. Man braucht sie nicht, aber man kann sich ĂŒber die Lösung von Problemen freuen, die man sonst nicht hĂ€tte.
Im Ernst: Ich kann mir keine Anwendung vorstellen, die ĂŒber das Rendern hinausgeht, ohne andere Datenquellen wie FahrplĂ€ne, Tarife etc. einzubinden. Wenn das aber eh nötig wĂ€re, dann sehe ich keinen Bedarf, sich um Reihenfolgen in den OSM Daten zu scheren. Und das soll bitte keine Aufforderung sein, jetzt auch noch FahrplĂ€ne und Tarife in eine PTv4.0 rein zu quetschen.
Fast wie eine Ehe? Gemeinsam Probleme lösen, die man alleine nicht hat?
Das scheint wohl fĂŒr die meisten der Hauptzweck zu sein, aber dafĂŒr brauche ich kein PTv2, da reicht eine unsortierte aber vollstĂ€ndige Liste aller Haltestellen und Wege aus.
Wie in #25 dieses Thread schon gesagt: Trufi hat/macht eine App. In wie weit die noch andere Quellen (in Nouakchott, Mauretanien gibt es noch keine Quellen) hinzuziehen könnte ich mal erfragen.
Schau mal bei JungleBus vorbei, die machen sowas mit interval, duration, âŠauf Basis von PTv2.
âŠja da muss man aber auch sagen das oft das Hauptziel dieser Aktionen ist mit Hilfe von OSM-Daten ein GTFS Datei zu erstellen⊠welche dann bei Google dann hochgeladen wird um ĂPNV-Routing auf Google Maps zu bekommen, weil der Lokale ĂPNV das nicht selbst macht.
Um dieses Ziel zu erreichen,⊠braucht es nicht umbedingt PTv2(machmal nur die platformen, highway=bus_stop)⊠bzw. nur eine Teilmenge, weil auf das Shape kann verzichtet werden⊠bzw. lĂ€sst sich ĂŒber routing erstellen 
GruĂ Miche
Oh, sorry, ich habe mich da nicht deutlich genug ausgedrĂŒckt. Bin immer von einer manuell angestoĂenen Autosortierung wie im Relations-Editor von JOSM ausgegangen. Eine Autosortierung ohne User-Interaktion, wie iD sie anscheinend macht, bringt bei Routen wohl eher Ărger.
Da lĂ€uft dann aber einiges schief und der Fehler ist schon davor. Wieso brauche ich ĂŒberhaupt eine Umordnung wenn vorher alles schon richtig war?
Hilfe Mama, der will mir mein Spielzeug wegnehmen.
Dachte Du hast Deinen Ărger mit PTv1. Wie soll ich denn folgende Linien auf Fehler ĂŒberprĂŒfen oder auch nur den Hauch einer Ahnung haben wo der Bus lang fĂ€hrt?
Das geht schon ganz gut mit PTv2. Braucht eigentlich nur ein Feintuning von interval und duration fĂŒr Wiederholungen bzw. einen optimierten Ersatz fĂŒr :conditional.
Super, dann steht da ja ĂŒberall OSM als Quelle mit Link. Sollte dies Angabe nicht auch in die GTFS-Zip-Datei, wenn die Shapes aus OSM kommen?
Die GTFS in meiner Gegend legen zwar OSM nahe, bei den Haltestellen habe ich aber meine Zweifel und die Shapes decken sich nicht mit den PTv1-Relationen. Um eine Aussage zu PTv2 machen zu können mĂŒssen die Shapes erst mal aktualisiert werden, was dauern kann.
FĂŒr anstĂ€ndiges Routing von Bussen braucht es viel Aufwand und hĂ€ufig sind die Daten unvollstĂ€ndig oder nicht ausreichend.
ja mĂŒsste dann so seinâŠ
braucht man nicht⊠das Ergebnis zĂ€hlt, kann man tricksen wie man will Hauptsache man hat fĂŒr jeden trip einen Shape 
Ich habe schon wieder vergessen, was der Unterschied zwischen PTv1 und PTv2 ist, aber v2 war - glaube ich - weniger schlecht geeignet fĂŒr das Relationsmodel. Wo der Bus lang fĂ€hrt sieht man doch, wenn man Deinen Links folgt. Vorausgesetzt, die Relationen sind korrekt.
Wie man das ĂŒberrpĂŒft? Falls GPX im Bus funktioniert, wĂ€re es einfach, sonst mĂŒsste man wohl dem Bus hinterherfahren und anschlieĂend fragen, ob der Fahrer immer diese Strecke fĂ€hrt?
âSiehtâ ist hier das richtige bzw. falsche Wort ⊠das ist Kartenbezogen.
Mit âsehenâ hat ein Programm, welches die genaue und richtige Strecke von A nach B wissen will, nicht viel zu tun.
-
PTv1 hat nur eine Relation fĂŒr eine Buslinie und diese nimmt alle Wege, Varianten, ⊠auf - daraus kann ein Programm nicht schlieĂen, welche Wege ein Bus konkret von A nach B nehmen wird - nur welche Wege im Laufe eines Jahres von dem Bus mal befahren werden.
-
PTv2 definiert fĂŒr jede Variante/Richtung eine eigene Relation, bei der die Reihenfolge der Haltestellen aber auch die Reihenfolge der befahrenen Wege korrekt sein muss (meinetwegen weil du mit eingeschaltetem GPS-GerĂ€t mitgefahren bist)
- was bei PTv2 auch nicht drin ist: an welchen Tagen zu welchen Uhrzeiten wird eine bestimmte Relation befahren
- das lÀsst sich aber durch interval, duration, ⊠auf PTv2 aufsatteln - in gewissen Grenzen (gell, skyper)
Ganz ehrlich: seit PTv2 bin ich raus aus dem ĂPNV-Mapping. AuĂer Haltestellen trage ich in diesem Bereich nichts mehr bei, und die sind auch nicht in irgendwelche Relationen eingebunden, sondern maximal standalone. Und wenn ich diesen thread so lese fĂŒhle ich mich bestĂ€tigt.
Und die Gefahr vor Augen, irgendwo was versehentlich kaputt zu machen, schrÀnkt mich auch in den weiteren Mapping-TÀtigkeiten zunehmend ein. Ich glaube, auf Dauer bekommt das dem Projekt nicht so gut, wenn immer alles komplizierter wird. Das schreckt neue Mapper zunehmend ab.
Keine Angst, keine Angst⊠Jeder macht Fehler oder ist vielleicht mit der Situation ĂŒberfordert.
Ich sag einmal so⊠Die StraĂen Daten gehen vor und wenn einer mit dem Relationen ĂŒberfordert ist dann soll das nicht verhindern z.b. den Kreisel einzuzeichnen. Dann ist es OK ein Loch in die Relationen hinein zu reiĂen.
Mir persönlich graust es schon weil in Poing ein neuer Kreisel geplant ist⊠Wo 13 Relationen aus der einen, 10 auf der anderen und 5 auf der letzten StraĂe sind 
GruĂ Miche
PTv1 ist praktisch gesehen die Buslinie wie man sie auf die Karte malen könnte. Wo der Bus nur in einer Himmelsrichtung durchfĂ€hrt malt man mit Pfeilen (Rolle âforwardâ oder âbackwardâ und wo der Bus vom StraĂenrand aus gesehen mal von links und mal von rechts kommt nimmt man Linien ohne Pfeile (âleere Rolleâ). Die Haltestellen sind ausnahmslos Nodes (Rolle egal). Die Reihenfolge der Angaben bedeutet nichts (aber man kann es ĂŒbersichtlicher oder weniger ĂŒbersichtlich machen). Es kommt nichts doppelt vor.
Bei einer Buslinie, die z.B. mal ĂŒber A-Dorf und mal dran vorbei fĂ€hrt und spĂ€ter dasselbe mit B-Dorf macht kann man aber dann nicht sehen, dass das immer abwechselnd passiert, das man also nicht ohne Umsteigen von A-Dorf nach B-Dorf kommt. Auch kann man keine Linien oder FlĂ€chen fĂŒr die Haltestellen eintragen und das ist besonders bei Bahnlinien sehr ungĂŒnstig, da niemand auf das Mappen von Bahnsteigen verzichten will.
Deshalb wurde PTv2 erfunden. Da bekommt jede Variante jeder Richtung eine eigene Relation und man kann die möglichen Verbindungen genau sehen. Da es nur eine Variante ist, sollte bei vollstÀndiger Erfassung immer der eine Weg aufhören wo der nÀchste anfÀngt und auch die Haltestellen gibt man in der Reihenfolge der RealitÀt an. Da kann man dann z.B. auch sehen, dass die nach XXX Hbf durchfahrende Variante der Zuglinie in YYY an einem anderen Bahnsteig hÀlt, der per Rollstuhl nur schlecht zugÀnglich ist.
PTv2 ist wahrscheinlich so fragil, weil es zu sehr im Grenzbereich des aktuellen Datenmodells liegt. Es gibt fĂŒr API 0.7 VorschlĂ€ge, den Relationsmitgliedern selbst nochmal eigene Tags zu verpassen. FĂŒr PTv2 wĂŒrde ich dort z.B. Eigenschaften wie ânur Einstiegâ oder ânur Ausstiegâ unterbringen, statt das irgendwie in die Rolle zu quetschen.
Die Sortiergeschichte der Relationsmember wĂ€re auch unnötig, wenn man z.B. den Zeitpunkt eines Stops durch HinzufĂŒgen eines Zeitstempels eindeutig macht, also âStop wird immer nach 00:37 Minuten gemessen ab Startzeitpunkt der Linie angefahrenâ. Wenn in einer Minute zwei Stops angefahren werden, reichen Minuten natĂŒrlich nicht mehr aus, aber ich denke, das Prinzip sollte klar sein. Fahrplan mit Abfahrtzeiten als Grundlage sollte hoffentlich ausreichen fĂŒr so etwas.
https://wiki.openstreetmap.org/wiki/API_v0.7#Tags_for_relation_members._Role_is_not_enough
Verstehe ich nicht ganz. WĂ€re das eine dritte Ebene zwischen âroleâ und den âtagsâ der Haltestelle.
Haltestellen sind u.U. Member von vielen Relationen, d.h. ânur Einstiegâ ist nicht die Eigenschaft einer Haltestelle an sich, sondern Eigenschaft dieser Haltestelle in einer bestimmten Buslinie (Relation). Selbiges gilt fĂŒr die Fahrzeiten zwischen zwei Stationen dieser Buslinie. Das entspricht ĂŒbrigens den trips und stop_times im GTFS-Modell (trip-spezifisch: Abfahrzeit an jeder Haltestelle statt Zeit bis zur nĂ€chsten).
Prinzipiell bin ich dafĂŒr, aber wo genau wird der Zeitstempel hinterlegt? Sicherlich nicht als zusĂ€tziches âtagâ am Node der Haltestelle - no way.