Könnte sich die jemand mit etwas mehr Erfahrung in ÖPNV bitte noch mal anschauen? Dann wird sie auf der OpenPTmap gleich richtig gerendert http://www.openstreetmap.org/relation/6567241
Ich bin mir mit dem, was ich geschrieben habe, sehr sicher. Such einfach mal ein wenig im Forum (ggf. über Google, das ist schneller), oder warte bis andere ÖPNV-Experten sich melden.
Roland Olbricht sagte mal sinngemäß über Sketchline: Nachdem alles kreuz und quer gemappt wird und man am Tagging nicht unterscheiden könne, welches Schema bei der Relation anzuwenden sei, hat er die Weiterentwicklung von Sketchline eingestellt.
Also ich habe die Knoten nun noch einmal an den Anfang gestellt und trotz Wartens zeigt sketchline nur den Fehler an. Und ich sehe einfach nicht, was ich anders gemacht habe gegenüber den existierenden Routen …
mal angenommen Du kannst Nakaners Bemerkungen (teilweise) ignorieren - und die Ausgabe der Buslinie 28 deutet darauf hin (Edit: und sieht zumindest ok aus) -, dann
solltest Du noch einmal genau hinschauen:
Bei der Route 28 sind die stop vor der platform (wie gemäß der PTv2-Definition),
bei Deiner Route 34 sind die platform vor den stop!
(Nur Vermutung aus den Ergebnissen):
Deshalb findet Sketchline (nur) den ersten stop, da dahinter eine platform folgt, die nicht zu dem stop passt => Abbruch.
Lt. Meldung “At most one stop found” wurden also entweder kein Stop oder nur 1 Stop in der Relation gefunden. Könnte also sein, dass die route_master=bus-Relation hier massiv Verwirrung bei der Auswertung stiftet.
wir haben im Moment keine einfach zu benutzenden Hilfsmittel, die einem “richtig” oder “falsch” an einer ÖPV-Route melden. (Es gibt “putr”, aber das ist nicht einfach zu benutzen und bezieht sich nicht auf eine Linie sondern auf eine ganze Gegend. Siehe http://gafte.de/)).
Ich sehe im Moment folgende Probleme:
Die Namen fehlen: “Bus 34” bzw. “Bus 34: Holbeinplatz => Industriestraße” bzw. “Bus 34: Industriestraße => Doberaner Platz” (oder doch “Holbeinplatz” und das “to” ist falsch.)
Ein Angabenpärchen zu einem Halt muss zuerst den “stop” und direkt danach die “platform” gleichen Namens haben. Sonst sind es zwei Halte.
Gemappte “stop” oder “platform” dürfen nicht in der Route entfallen. Man kann also nicht “einer reicht doch” argumentieren. Man muss sie nicht mappen, aber gemappte müssen in die Routen. Sonst kann man in der Datenbank nicht von dem Haltestellenobjekt aus die Buslinien finden.
“Stadtwerke” ist stadteinwärts doppelt.
Bei der Haltestelle “Marienehe” muss der Serviceway in drei Teile geteilt werden. Das erste Stück wird zweimal durchfahren und muss daher zweimal in die Route. Danach ist der Rest des Weges in sich geschlossen und die Nutzungsrichtung kann nicht mehr aus der Reihenfolge der Wege ermittelt werden. Deshalb muss die Schleife auch noch irgendwo aufgetrennt werden. Aus der Reihenfolge, in der die beiden Teile angegeben werden, ergibt sich dann die Durchfahrrichtung der Schleife.
Die “platform” der Haltestelle “Industriestraße” ist doppelt gemappt. Ich nehme mal an, dass es da nur einen Steig gibt. Der Node sollte daher weg. Sein Tag “highway=bus_stop” sollte dann an die “stop_position” wandern, denn für dieses Tag kommen nur Nodes in Frage. Die beiden wheelchair-Tags widersprechen einander allerdings … Eigentlich sollte sollte sich das wheelchair nur auf den Steig beziehen und nicht auf üblicherweise auftretende oder nicht auftretende Probleme beim Einsteigen, aber das ist m.W. strittig.
Stadtauswärts fährt der Bus extra einen Umweg über “Marienehe” … hält da aber nicht.
ich hab mir letztlich für Aachen mal die Mühe genacht, alle grundlegenden Erkenntnisse über das Mappen von Bussen zusammen zu tragen und eine Anleitung zu erstellen.
Vieleicht kannst du dich daran etwas orientieren:
Generell ist das ÖPNV mapping sehr komplex und schwer zu durchschauen. Dazu kommen viele kaputte Relationen und falsche Tags, auch die Auswertungsprogramme kommen bei der Komplexität nicht wirklich hinterher. Dazu die jahrelange Diskussion über eine neue einheitliche Taggingmethode, die soweit ich weiß nicht wirklich vorran kommt.
Das ist leider der Grund, warum selbst viele erfahrene Mapper hier aussteigen und das Feld anderen überlassen, von daher ist jeder, der sich dafür engagiert sehr willkommen!
wenn man nur noch die beiden Relationen 6567240 und 6571814 berücksichtigt, wird die Meldung “At most one stop found” nicht mehr ausgegeben.
Erst durch die Relationen 6567241 und 6563154, die selbst nur auf andere Relationen verweisen und keine Stops enthalten, entstehen die Probleme.
Heute werden die relevanten Relationen über ref und network selektiert. Dadurch wird auch der Beifang mit eingesammelt, der hier Probleme macht. Dummerweise lässt sich die Query aktuell ansonsten nicht von außen beeinflussen. Ich habe das direkt auf dem Server Schritt für Schritt durchgespielt und die Query manuell angepasst.
Die Relation 6567240 war von type=trollybus, die Andere richtigerweise vom type=bus
Die selbe Relation hatte zudem “from=Doberaner Platz” anstatt “from=Holbeinplatz” (Hab mich noch verschrieben “HoHlbeinplatz”)
Die Relation 6563154 war wohl ursprünglich anstatt 1. geplant und geisterte mit den entsprechenden (richtigen) route;ref;from und to in der Gegend herum, ohne aber zur Route-Master zu gehören; stattdessen hatte sie selber die obige Route als einziges Member mit drin.
Eins von den Sachen wars.
Weides Anmerkungen (Stops, Wege splitten) habe ich gleich mal mit gemacht.
Ach so: Ich finde, dass das Line-Diagramm für PTv2 doch recht gut funktioniert.
@Nakaner Doch klar lesen ich / habe ich gelesen was du geschrieben hattest. Allerdings schienst du bei mir überlesen zu haben, das eine andere als PTv2 getaggte Linie ohne Probleme dargestellt wurde. Von daher erschien mir deine Vermutung nicht so ganz stichhaltig
@GeorgFausB Hatte ich nicht so ganz nachvollziehen können. (Aber wurde ja nun gelöst s.o.)
@Weide@hsimpson Danke für die Erläuterung/Einordnung! Leider erscheint auch mir die Komplexität gegenüber dem älteren Oxomoa-Schema doch signifikant gestiegen. Schade, denn schon damals haben sich ja kaum Leute an die Routengetraut
@mmd Ich bin nicht sicher ob ich (aktuell) bereits den bug genug verstehe. Würdest du das übernehmen wollen? (Ansonsten probiere ich es mal nächste Woche)
@Hubert87 Danke dir für den fix Der Teufel steckt wie immer im Detail, umso besser, wenn jemand mit Ortskenntnis und dem richtigen Blick da weiterhelfen kann!
Bist du dir da wirklich sicher?