Hallo,
hier stand mal eine Beschreibung für eine OSRM-basierte Erstellung von OSM-Relationen. Der Proof of Concept wird nicht mehr weiterverfolgt, das Video ist dem Neujahrsputz zum Opfer gefallen.
Eine rudimentäre Beschreibung der damaligen OSRM-Patches ist hier zu finden. Im Browser wurde einfach eine neue Relation aus allen von OSRM zurückgelieferten Wegen erstellt. Folgender Changeset wurde im Video angelegt.
Don’t panic, das Leben geht weiter 
Und du willst das umsetzen?
Was ist, wenn nicht alle zur Route dazugehörigen Wege eingezeichnet ist bzw. für bestimmte Gebiete nicht bekannt ist, wie die Route verläuft? Dann wird das nichts mit deinem Routing-Ansatz, außer man kann mehrere Start- und Endpunkte angeben. Genauso, wenn neue Wege dazu kommen, dann kann es plötzlich ganz andere kürzeste Wege geben und die bisher eingetragenen Via-Punkte reichen nicht aus und führen zu einer anderen Streckenführung.
Nunja…das dürfte ein ganz schönes Monster werden. Denn dem Router ist idR. nicht bekannt, auf welcher Way-ID er gerade routet, denn er arbeitet mit einer angepassten Geometrie/Datenbasis.
Reverse-Routing dürfte auch recht aufwändig sein. Eher würde man wahrscheinlich an jeder Abzweigung einen Via-Knoten setzen. Das ist schon schwer genug. Solltest du mit BaseCamp von Garmin arbeiten, kannst du dir da mal die Funktion Track in Route umwandeln anschauen…dann siehst du was ich meine.
Fazit: Als Eingabemöglichkeit für neue Relationen, deren Wegenetz komplett vorhanden ist könnte das durchaus etwas werden. Ob sich sowas für diese Spezialfälle lohnt ist eine andere Frage…Ich glaube mit den derzeitigen josm-Mitteln geht das besser. (Download entlang gpx-File, dann Wege selektieren und mit shift-w zusammenhängende Wege markieren)
Zur BaseCamp-Funktion: Ich bekomme da bei Tracks von rund 200km 1000 Zwischenziele im Automatik-Modus. Selbst wenn man mit einem besseren Algorithmus das evtl. auf die Hälfte oder 1/4 drücken könnte…für längere Relationen läuft das vor den Baum. Damit möchte keiner Arbeiten, zumindest ich nicht.
Zum Splitten von Wegen: Wie gesagt, ein normaler Router weiß nicht, auf welchen Way-IDs er routet, schon gar nichts über die Node-IDs. Die Infos muss er erstmal bekommen. Dann kann er Prüfen, ob er schneiden muss, dann den Kreuzungsnode ermitteln und dann schneiden. Dabei dann natürlich keinen schaden anrichten (was auch nicht trivial ist). Wie du siehst, ich bin da sehr skeptisch, ob da mit vertretbarem Programmieraufwand und Rechenpower was Anfänger freundlicheres raus kommt.
Nabend allerseits,
also ich finde die Idee wirklich gut! Hätte man auch mal früher drauf kommen können 
Vorschlag von mir:
Wie wäre es, wenn man die z.B. Busroute sich mit dem Tool “zusammenklicken” kann, und sie dann “auf deinem Server” abspeichern kann. Diese Route wird dann z.B. als WMS-Hintergrund ausgeliefert und man kann sie per JOSM/Potlatch einbinden und in OSM einarbeiten…
Ist glaube ist vom Aufwand geringer und es könnte sich z.B. “jeder” dran machen, ohne sich vorher groß in OSM einzuarbeiten.
Problem bei deinem Vorschlag:
Es muss einen “Depp” geben, der dann die Route in die OSM-Daten einpflegt. Sonderlich spaßig ist das nicht, sodass man das unbedingt jeden Tag mehrfach haben will.
Ok, es gibt aber auch “Deppen” die Tag für Tag von Luftbilder Wälder abzeichnen 
Ich versteh schon was du meinst und ich hoffe du verstehst mich nicht falsch, aber ich finde es wäre “erstmal” die “einfachste” Möglichkeit und es wird ja auch niemand gezwungen die Routen dann einzutragen
Besonders auf dem “flachen Land” könnte ich mir vorstellen, das es eine einfache und schnelle Möglichkeit ist, besonders den ÖPNV, vorran zubringen. es könnten auch die einzelnen Haltestellen eingetragen werden. Und so verbessert es sich immer weiter.
Außerdem wären dann diese “bösen” automatischen Änderungen auch nicht gegeben.
Nochmal kurz zurück zu den “Deppen”:
Irgendwann ist auch mal so ein Depp angefangen und hat einen gpx-Track “abgetickert” und schwupps war eine weitere Straße in OpenStreetMap
Ich sag ja nicht, dass es nicht geht, sondern nur, dass es nicht trivial ist. Man wird einen Router umprogrammieren müssen. Da halte ich die Idee von jman schon sinnvoller, sollten sich genug “Deppen” finden, die daran Spaß haben gpx-Tracks in Relationen zu packen. Im geringen Maße könnte ich mir das durchaus Vorstellen einen gpx-Track in eine Relation zu verwandeln.
Ich weiß nicht ob es schon ein gutes HowTo für Einsteiger gibt, wie man eine Routen-Relation mit aktuellen Mitteln fix erstellt. Aber das sehe ich erstmal als realistischere Ziele.
Deine Idee über den Router ist an sich ja nicht schlecht. Nutze ich bspw. auch um meine Radstrecke zu planen. Aber sobald da mehr raus kommen soll, als ein gpx-Track, etc. steigt der Rechenaufwand deutlich an und die Probleme werden auch nicht kleiner.
Sieht ja schon recht vielversprechend aus. Um es universell einsetzbar zu machen, müsste man den Router so einstellen, dass er auf allen Wegen gleichberechtigt routet.
Zum Kreisverkehr sag ich besser nichts, dass gibt nur unnötige Diskussionen
Beim Schneiden fällt mir noch ein, dass man da auch die vorhandenen Relation berücksichtigen muss, in denen der Weg schon steckt und das je nach Relationstyp korrekt verwursten.
Ich glaube, da bist du etwas am OSM-Ziel vorbeigeschossen.
Routen im OSM-Sinn sind Wegstrecken, die in irgend einer Form in der realen Welt existieren (Buslinien, Wanderrouten, etablierte Rad-Touren (rund um den …), Flüsse, … und in dieser Form auch real gekennzeichnet sind (z.B. durch Schilder)
Was du hier machst, ist einen Weg zu markieren, der irgendwie - von dir durchaus beeinflusst - von A nach B führt. Route im Sinne von Wegfindung.
Ich bin der Meinung, dass solche personalisieren “Routen” nichts aber auch garnichts in OSM zu suchen haben.
“Eigene” Strecken sollten auch in eine “eigene” DB. So wird es auch von den professionalen Portalen gemacht.
Mittels dieser Technik allerdings z.B. eine reale Busroute zu generieren, erscheint mir zu aufwändig; die klicke ich mir lieber im Editor meiner Wahl zusammen.
Gruss
Walter
ok, dann ist das Demo-Video allerdings sehr ungünstig gewählt.
Ansonsten gilt für mich immer noch “Mittels dieser Technik allerdings z.B. eine reale Busroute zu generieren, erscheint mir zu aufwändig; die klicke ich mir lieber im Editor meiner Wahl zusammen.”
Gruss
Walter
was mir noch einfiel: was machst du, wenn eine Straße an einer Kreuzung nicht aufgebrochen ist, weil bis jetzt keine Notwendigkeit dafür bestand? Editor aufrufen, aufbrechen, hochladen, 1 Woche warten, weitermachen?
duck&weg
Der Ansatz, ein existierendes Tool zur Visualisierung und interaktiven Bearbeitung von Routen-Relationen zu verwenden, ist richtig clever. Ich hoffe, da wird was draus! Gerade weil die bedienung einfach ist, ermuntert das zum Routenmappen. Ich habe auch schon einige Buslinien gemappt - von Hand zu Fuß macht das nicht wirklich Spaß, ständig muß man irgendwelche Wege auftrennen, das könnte einem ruhig jemand abnehmen.
Gruß,
Zecke
Wow, nicht schlecht!
Ich hatte anfänglich so meine bedenken, was das “direkte, halbautomatische Eintragen” von Relationen anging. Aber wenn ich das sehe und es “nur” ein halber Tag arbeit war, dann sind meine Bedenken weggewischt! Weiter so, ich bin echt gespannt es selber mal auszuprobieren…
Noch etwas zu den Haltestellen bei den Busrelationen:
Könnte man es nicht einrichten, dass
a) bereits vorhandene Haltestellen direkt in die Relation eingebunden werden
b) noch nicht erfasste Haltestellen auch “erfasst” werden können
Ich gehe mal davon aus, dass in der fertigen Variante die key/value-Tageingabe für die Relation noch hinzugefügt werden.
Echt super arbeit!!!
Noch eine Anmerkung: Evtl. sollte man einen Router erstmal soweit verändern, dass er die Erwartungen erfüllen kann (alle Wege gleich bewertet) und dann schauen, wie einfach das ganze dann bei richtigen Routen ist. Wenn es sich dann noch als sinnvoll herausstellt, könnte man dann an die Details wie Schneiden etc. gehen.
Als proof of concept reicht das doch erstmal. Es sieht jedenfalls vielversprechend aus 
Knackpunkt wird wohl das Splitten werden…
Ich finde eine solche einfache Technik zur Erzeugung von Realtion einfach toll.
Ich habe die bisherigen Werkzeuge in JOSM für die Erstellung / Bearbeitung von Relationen (leider) noch nicht durchschaut. Daher habe ich mir auch nie Gedanken darüber gemacht, ob ich hierfür Daten erfassen kann (z.B. Buslinien). Denn ich habe auch nicht die Muse, mich durch eine Vielzahl verstreuter Dokumentationen zu arbeiten, um dies machen zu können (in dieser Zeit erfasse ich lieber Daten für OSM).
Aus meiner Sicht ist der Ansatz eines solch einfachen Tools sehr hilfreich, um die Anzahl der Erfasser von Daten erheblich zu erhöhen.
Ich denke, dass viele Anwender (wie auch ich) nicht immer die Lust, Zeit und Motivation zum Erlernen komplexer Tools haben. Viele werden sich gerne mit einfachen (wenn auch beschränkten) Werkzeugen zufrieden geben, wenn diese einfach (be)nutzt werden können.
Wenn ich überlege, was ich von JOSM nutze, so ist dies bestimmt nur ein Bruchteil der Features. Hier greift sicher das Pareto-Prinzip: Mit 20% aller Funktionen lassen sich 80% aller notwendigen Arbeiten ausführen.
Oder anders formuliert: Haben wir ein komplexes Tool, das alles kann (allerdings auch entsprechende Anforderungen an die Einarbeitung stellt) ? Oder stellen wir mehrere Tools bereit, die nur wenig können, sich aber (einzeln) leicht erlernen und nutzen lassen ?
Übrigens möchte ich an dieser Stelle auch Danke sagen an all die Leute, die im Hintergrund die Werkzeuge schaffen, damit die Vielzahl der Mapper wie ich auch in der Lage sind, Daten einzupflegen.
Es sind (seltene) Fälle möglich, wo ein automatisches Splitten wie in JOSM zu falschen Resultaten führt. Dazu gehören Tags für Anzahlen an Ways, ein Beispiel wäre eine Treppe mit step_count. Und potentiell alle unbekannten Tags und Relationstypen.
Oft vorkommen wird so etwas bestimmt nicht. Aber während es im JOSM ist dann eigentlich immer noch die Verantwortung des Mappers ist, darauf zu achten, hat der Nutzer beim Splitten im Hintergrund keine Chance mehr, Probleme dieser Art zu bemerken.