Erstens hätte man dann keine Vereinfachung für die vielen Nutzer anderer Editoren. Die Vereinfachung für die JOSM nutzenden Profis, denen dann aber inbesondere in den ländlichen Regionen die Ortskenntnis fehlen dürfte, ist wohl weniger wichtig, als eine Vereinfachung für die vielen Mapper vor Ort.
Eine weitere Schwierigkeit wäre, dass der Editor ggf. nicht alle Daten geladen hat, die zum Routing erforderlich sind. Insbesonder bei langen Routen dürfte es eventuell auch nicht möglich sein, diese Daten zu laden.
Es würde jedem Editor natürlich offenstehen, die Bot-Funktionen so weit wie möglich direkt zu implementieren und somit einen zusätzlichen Edit durch den Bot überflüssig zu machen.
Wieso man die Mechanical Edit Policy hier offenbar beliebig ignorieren kann, wenn man seinen Bot als Editor bezeichnet, ist mir ohnehin unverständlich.
Und wie viele von den vielen Nutzern anderer Editoren kümmern sich wohl um ÖPNV-Relationen? Klar, Potlatch hat dreimal so viele Nutzer wie JOSM, aber mit JOSM werden dreimal so viele Daten bearbeitet. Der Großteil der Potlatch-Nutzer sind Klein- und Kleinstmapper, von denen viele nicht einmal wissen dürften, daß es sowas wie ÖPNV in OSM gibt. Der aufsteigende Stern am OSM-Editorenhimmel, iD, liegt zwar nach Nutzern gleichauf mit JOSM - versteckt Relationen vor diesen aber gleich völlig. Alle weiteren Editoren kann man gleich vernachlässigen, deren Nutzerzahl ist jeweils mindestens einen Faktor 10 kleiner als die von JOSM; und mit einem Editor auf dem Mobiltelefon möchte man auch wirklich keine Routenrelationen bearbeiten.
Weil sie auf sorgfältige Bearbeitungen unter Einsatz von Editor und Plugins schlicht keine Anwendung findet:
Die vorgeschlagene Bot-Lösung zielt keinesfalls primär auf die Ersterstellung ab. Für die Nutzer einfacher Editoren soll sie zwar eine gewisse Vereinfachung der Ersterstellung bringen, für JOSM Nutzer sehe ich den Hauptvorteil in der Pflege.
Die Expansion durch den Bot ist nur temporär bis zum nächsten Routing. Dazu wird die Auto-Rolle verwendet.
Nur wenn der Mapper diese manuell entfernt, würde die Expansion permanent. Deshalb sollte der Mapper dies nur in wirklich nötigen Fällen machen. Insbesondere wenn autoroute=template verwendet wird, kann man es vermutlich zumeist vollständig bei der Auto-Rolle belassen.
Der Bot würde vorhandene Auto-Member ignorieren und bei erfolgreichem Routingversuch durch neuberechnete Auto-Member erseten. Geht eine Route durch Probleme mit Auto-Membern kaputt, kann der Bot die Route selbständig reparieren.
Die meisten Sachen hat Oli-Wan ja schon kommentiert (danke, Oli), aber zwei Kommentare noch von mir:
Wäre das eine Möglichkeit für ein proof-of-concept. Wenn man hinterher einen Bot auf die Datenbank loslassen will, sollte man das ganze ja wohl mal getestet haben, und dafür würde sich das vielleicht anbeiten. Zumal es AFAIR schon ein Routing-Plugin für JOSM gibt, das mit etwas Glück für diesen Zweck erweitert werden könnte.
Sicher kann ich nicht einfach halb Deutschland lokal in meinen JOSM laden dafür. Die meisten Buslinien decken aber zumindest nicht so viel Fläche ab und bei Bahnlinien kann ich mich vielleicht auf das Nachladen von railway Objekten beschränken, so dass ich das grundsätzlich für denkbar halte.
… und falls jetzt jemand ein Gegenbeispiel präsentiert: man kann ja immer noch abschnittsweise arbeiten: Die bisher vorhandene Route samt ihrer Mitglieder komplett laden, dazu nur die für den nächsten Abschnitt benötigte Umgebung. Oder mit der Bereinigen-Funktion Platz im Editor(speicher) schaffen (Landflächen, Gebäude usw. weg).
Das dürfte dann aber doppelten Entwicklungs- und Testaufwand bedeuten. Den Bot kann man bei Bedarf auch ohne die normale Datenbank testen.
Man sollte sich also wohl besser vorab für die Plugin oder die Botvariante entscheiden. Ich denke, für eine Plugin-Variante würde man das Konzept auch noch speziell darauf anpassen.
Die entscheidende Frage ist, ob man wirklich nur JOSM unterstützen muss, weil sich die anderen Editoren ohnehin nicht eignen.
Routen als zusätzliche OSM-Wege zu zeichnen, könnte die Erstellung insbesondere bei einfachen Editoren vereinfachen.
Mit einem für die überlagerten Linien optimierten Editor, solllte dies auch bearbeitbar sein. Solange aber auch nur ein nichtoptimierter Editor gebräuchlich ist, würden dessen Zerstörungen die Wartbarkeit katastrophal werden lassen.
Dennoch könnte man solche Wege als temporäre Eingabelösung insbesondere für einfache Editoren nutzen.
Wird ein solcher Weg gezeichnet und mit Rolle add einer Routenrelation hinzugefügt, so könnte ein Bot die überlagerten Straßenelemente heraussuchen, bei Bedarf splitten und der Relation hinzufügen. Den OSM-Weg würde der Bot anschließend löschen.
Ich denke wenn es hilft, dann sollte man die “neuen” Wege als temporäre Eingabehilfe verwenden. Das geht wieder entweder als Plugin oder mit dem Bot. Der Bot wäre die universellere Lösung, da alle Editoren davon profitieren, aber er verdoppelt eben auch das Datenvolumen. Als Plugin hat man als Bearbeiter immer schon das fertige Ergebnis vor Augen und kann vor dem Hochladen noch eingreifen. Außerdem trägt man selbst die Verantwortung und nicht nur der Ersteller Betreiber des Bots.
Das Plugin für die Wegumwandlung ist vielleicht auch für andere Relationen interessant. (Wanderwege und Co)
Nur mal so am Rande: ist die tatsächlich gefahrene Route wirklich relevant? Üblicherweise kann man sowieso nur an Haltestellen ein- und aussteigen, ob zwischen diesen beiden Punkten jetzt Route A oder Route B gefahren wird ist für den Busreisenden wahrscheinlich eher nebensächlich.
Ja, z.B. weil man mit dieser über die aktuelle Position des Fahrzeugs Fahrplanabweichungen besser ermitteln kann als nur mit bestimmten Messpunkten (=Haltestellen).
Es kommt immer darauf an wofür man die Daten verwenden möchte. Wenn man nur wissen möchte wie man von A nach B kommt reicht dein Ansatz sicherlich aus. Aber schon wenn ich an einer Strecke stehe und mich frage welchen Bus habe ich gesehen? Oder mit welchem Bus kann ich an dieser Sehenswürdigkeit vorbei fahren.
Aber auch andere Dinge könnte eine Rolle spielen. Welche Straßen sind jetzt besonders ruhig? Oder wo ist mit Verkehrsbehinderungen zu rechnen? ÖV ist ja oft Pulkführer.
Oder wenn Linien es ermöglichen, dass einen der Busfahrer irgendwo auf der Strecke rauslässt. Bei uns vielleicht nicht so üblich, im Rest der Welt solls das aber geben
Schon um die Linie zu rendern,braucht man den Fahrweg. Direkte Linien zwischen den Halststellen würden auf der Karte sehr unschön aussehen, sofern es sich nicht nur um einem schematischen Netzplan handelt.
Weitere Anwendung: Wo wird wegen des Busverkehrs im Winter der Schnee zuerst geräumt?
Für völlig übertrieben halte ich allerdings die mehrfache Fahrwegerfassung für alle Varianten einschließlich verkürzter Fahrten. Beim Erstellen ist dies durch Kopieren der Relation kein Problem und vermutlich eher einfacher als bei anderen Lösungen, bei der Pflege rächt es sich dann gewaltig und beim Erstellen ebenso, wenn man mit den Varianten nicht solange wartet, bis die Hauptlinie wirklich komplett ist.
Bei Bot basierten Routing würde man die Pflegeprobleme durch die Varianten deutlich reduzieren. Mapper könnten bei der Bearbeitung von Straßen die Routenzugehörigkeit von Wegen mit “auto”-Rolle einfach ignorieren, da der Bot die Probleme gleich wieder fixen würde.
Die Routing-Plugin-Lösung könnte dies nicht bieten, hätte aber klare Vorteile beim gezielten Bearbeiten der Routen-Relationen. Da dann aber die Beseitigung von Problemen nicht ohne zutun eines Mappers möglich ist,
sollten wir einen Weg finden, die redundante Fahrwegerfassung wegen Varianten zu beseitigen oder zumindest zu reduzieren.
Ich denke, dass dies zumindest soweit kompatibel möglich ist, dass vorhandene Daten weiterhin gültig bleiben. Da die Preferenz für das Routing hier eher bei einer Plugin-Lösung zu liegen scheint, werde ich in Kürze ein Konzept zur Redundanzvermeidung in einem neuen Thread zur Diskussion stellen.
Die diskutierten Varianten (Editor-Plugin, Bot, nur Haltestellen) unterscheiden sich hauptsächlich darin, wann das automatische Routing stattfindet.
Die resultierende Karte würde (fast) identisch ausfallen.
Dafür reichen die bisherigen Daten kaum aus. Ein einmal täglich verkehrender Bus ist meist nicht von einer Hauptstrecke im 10 Minuten-Takt unterscheidbar.
Eine verkürzte Fahrtstrecke mag noch verzichtbar sein. Bei den typischen Überlandstrecken werden oft Streckenteile ausgelassen oder alternativ bedient. Wenn man dort nur einige Varianten erfasst, fehlen auch Elemente in der ÖPNV-Karte.
Wenn wir ein Datenmodell festlegen, das mehrere Streckenvarianten zusammenfasst, verzichten wir auf die Möglichkeiten, die eine Ergänzung von Betriebszeiten, Fahrthäufigkeit oder eine Liste der Startzeiten bietet (Fußgängerrouting, Karten mit Fahrtdichtedarstellung).
Eine Haltepunkt-basierte Lösung wäre noch einfacher. Der Mapper würde bei der Bearbeitung von Straßen die Buslinien gar nicht sehen und könnte sich um die verbliebenen Relationen kümmern. Es würden auch temporär keine ungültigen Daten in der Datenbank stehen.
Wie soll man die Varianten reduzieren? Durch Weglassen von Nebenvarianten oder durch Zusammenfassen mehrerer Varianten in einer (nicht mehr geordneten) Relation?
Ich finde es auch unschön, dass die Mapper damit in verschiedene Klassen geteilt werden. Mapper mit einfachen Editoren würden Straßen verbessern und Buslinien dabei (teilweise) zerstören, andere müssten daraus wieder gültige Daten machen.
Meines Erachtens wäre ein Datenmodell mit deutlich verringerter Komplexität (nur Haltestellen, in Ausnahmefällen via-Punkte) aber mit allen Varianten die bessere Alternative.
