Sparsamkeitsgebot Way-Splits

Mittlerweile scheint das “Sparsamkeitsgebot” auch auf “Thread-Splits” übergegriffen zu haben. Wenn die verschiedenen Diskussionsstränge zu etwas führen sollen, würde ich empfehlen, diese in eigene Threads auszulagern.

Ich glaube nicht, dass sich durch Stützpunkte für Routen etwas verbessert. Wenn ich an die regional rudimentäre Waldwege-Erfassung denke, dann ist es gut denkbar, dass plötzlich eine Route “selbstständig” auf einen kürzeren - aber erst frisch gemappten - Weg verlagert, weil niemand dran gedacht hat, noch einen Stützpunkt auf den “richtigen” Weg zu setzen. Ganz abgesehen von der Frage, ob man sich bei Bus-Routen darauf verlassen kann, dass die Stützpunkte gelöscht werden, wenn der Bus in Zukunft eine andere Route nimmt.

Ich bin aber voll bei abrensch, wenn er anprangert, dass manche Mapper Durchlässe als “Brücken” mappen. Und ich halte es auch in vielen Fällen für vertretbar, Maxspeed-Sektionen dort zu setzen, wo ohnehin schon ein Bruch ist, zum Beispiel an einer Kreuzung, statt 20 Meter weiter, wo das Schild steht.

Lücken in Routenrelationen fände ich nicht so prickelnd. Wenn ein Wanderweg eine Bundesstraße mit fünf Metern Versatz quert, muss man das sicher nicht abbilden, sondern dann kann der Weg “geradeaus” queren. Aber bei 20 oder 30 Metern ist es schon hilfreich zu wissen, ob es links oder rechts weitergeht.

Könnte man nicht einfach nur die Routen als GPX Dateien irgendwo anders ablegen und dann in der Relation einen Link darauf?
Dann können QA Tools prüfen, on die GPX Route so überhaupt befahrbar ist und wer mag kann dann reparieren. Die meisten Anwender wollen doch letzlich so eine GPX Datei.

Dann hast du Links auf zich verschiedene Server. Die sind mal down, löschen ihre Daten, usw.
Und wenn irgendwas an den OSM-Daten geändert wird, sind die GPX-Dateien automatisch veraltet und werden wohl eher nicht automatisiert aktualisiert.

Bei 5 Metern würde ich außerorts dafür die Straße nicht extra splitten sondern die Geschwindigkeitsbegrenzung dort anfagen lassen, wo die Brücke anfängt.

Ich habe schon viele Brücken entfernt und durch culvert ersetzt. Aber nicht aus Datensparsamkeit sondern weil es tatsächlich keine Brücken waren. Auch manche Unterführung eines Feldwegs oder einer Nebenstraße unter einer Fernstraße hindurch hat sich für mich eher als Tunnel dargestellt (z.B. weil es zwischen Unterführung und Fernstraße noch eine Schicht Erde gibt)

Das wäre der Abschied von OSM als der universellen Geo-Informations-Datenbank. Das wäre genau die Methode, wie Komoot, Alltrais oder Outdooractive arbeiten. Eine Methode, die für die Zwecke, für die Komoot und Konsorten gedacht sind, auch passt. Aber wir reden hier in OSM von “on-the-Ground” ausgeschilderten Wanderrouten, da ist wirkt sich jeder Änderung einer Straße direkt auf den Routenverlauf aus.

Ich habe aber bereits an anderer Stelle mal angeregt, ob die Entwicklung nicht in Richtung verschiedener Ebenen gehen müsste, die man beim Editieren wahlweise ein- und ausblenden kann. Ich stelle mir dass dann so vor, dass dann eine Wanderroute quasi eine mit der Straße verklebte durchgängige Linie wäre. Die Straßelinie müsste dann für die Route nicht aufgesplittet werden. Und ebenso entfiele auch bei der Wanderroute diese Zerstückelung in viele kleine Abschnitte. Ob das technisch umsetzbar wäre - keine Ahnung.

Aber ich habe mich sehr erschrocken, als ich mir mal die Gegend um den Kölner Dom im Editor angeschaut habe - das ist inzwischen so komplex, wer soll dort noch durchsteigen?

Daher wäre meine Vision, dass man in solchen Fällen verschiedene Ebenen wahlweise ausblenden könnte. Das kann man zwar mit einzelnen Objekten bereits, doch das Problem sind die miteinander verbundenen Objekte. Wenn man z.B. Eisenbahnlinien ausblendete, würde man diese auch verändern, wenn man eine Straße, die diese Eisenbahnlinie kreuzt, mit verschieben. Der iD-Editor verweigert dann auch konsequenterweise jegliches Verschieben von Punkten, die zu Objekten gehören, die ausgeblendet sind. Es müsste also möglich sein, die Straße zu verändern, ohne dabei die Routenlinie in die Finger zu bekommen, diese müsste sich aber wie bei verklebten Linien mitändern, wenn man den Straßenverlauf korrigiert.

Warum verschiedene Server? Warum nicht den OSM Server? Wir sprechen hier doch (auch) über ein API 0.7.
Im Moment sind die Daten automatisch “kaputt”, wenn jemand mit den falschen Tools oder Methoden die OSM Daten verändert. Automatisch korrigiert werden sie dann auch nicht. Im besten Fall bemerkt jemand den Fehler und weiss auch noch, wie die Route eigentlich aussehen sollte bzw. wie er das (sehr mühsam) rausfindet.
Das jetzige Model ist ja oft genug nicht mal dazu in der Lage, die GPX Datei zu liefern, weil Reihenfolgen unklar sind bzw. die Interpretation irgendwelcher Rollen.

Das wäre mal richtig cool, Routenrelationen nur anhand von Haltestellen und Stützpunkten zu definieren! Eine riesige Fehlerquelle (“XY hat aus Unwissenheit meine Routenrelation kaputt gemacht!”) für dessen Überwachung viele Tools entwickelt wurden und einige Leute viel Zeit reinstecken würde einfach so verschwinden!

Dafuer hast du dann die neue Fehlerquelle: XY hat den Stuetzpunkt geloescht oder verschoben oder YZ hat einen zusaetzlichen Weg hinzugefuegt oder einen entfernt oder ein Maxspeed geaendert oder ein falsches bus=no gesetzt… Wenn das Routen-routing dann umschlaegt viel Spass bei der Fehlersuche. :wink:

Wen hast Du den hier zitiert ? :roll_eyes:
Über fehlende Quellenangaben sind ja schon auch Minister gestolpert. :laughing: :laughing:

Solidarität ist so eine Sache die auf Gegenseitigkeit und auf Werte basiert. Bei deinen Beispielen gibt es in den meisten Kulturen einen Konsens, was schützenswert seinen sollte. Das Leben. In OSM gibt es aber keinen solchen Werte-Konsens. Daher ist es schwer Solidarität einzufordern. Was wir haben ist ein “Minimalkonsens” = On-the-ground.

Das Problem liegt meiner Erfahrung nach aber nicht darin, dass der Rad-routen-Mapper oder der Spur-Mapper aktiv deine Fernstraße zerstören sondern darin, das man bei gesplitteten Wegen schneller mal bei einer Fernstraßenanpassung ein Segment vergisst. Aus meiner Sicht also eher ein Problem, was ein Editor lösen sollte.

Im Prinzip braucht es ein Datenmodell, was Geometrie und Eigenschaften der Geometrie trennt. Im Prinzip alle Eigenschaften in eine Art Relation verbannen, bei die man flexibel mit Geometrie-Elementen verbinden kann. Quasi wie wir es bei Multipolygonen bereits haben. Dann auch für Multi-“Wege”, wo man sagen kann, gilt für den Weg 123 von Knoten 3 bis Ende und für Weg 456 komplett und für Weg 789 von Anfang bis Knoten 4. Von Montags bis Mittwochs außer Feiertag und nur bei Nässe.

Das ganze in Kombination mit einem WYSIWYG-Editor, wo sich der Mapper mit dem Datenmodell nicht rum plagen muss.

Vielleicht kriegt man dann ja auch Fahrbahnen wieder mit Geh- und Radwegen etc. zusammen …

Einen wichtigen Einschub finde ich die überproportionalen Zusatztags für Seitenweg, aber das gehört wohl in einen eigenen Thread.
Kreisverkehre habe ich aber genau deswegen schon öfter aufgeteilt, egal ob als eigenes Objekt vorhanden oder nicht, da es oft Kreisverkehre gibt, die nur auf einer Seite Rad- und Fußweg haben. Häufig bedeutet das auch wieder die Ein- bzw. Ausfahrtarme auch noch zu Teilen. Letzters gilt auch für etliche *_link.

Segment-Relation werden meiner Ansicht zu unrecht abgeschrieben und sie finden sich eigentlich schon in den Daten, oder wie würdet Ihr eine Superroute beschreiben. Ich sehe darin nichts anderes nur mit anderen Bezeichnungen.
Bei Wander- und Fahrrad-Routen ist ein ähnliches Tagging erst neulich mit einem Proposal bestätigt worden, wonach Varianten, Abkürzungen und Verbindungen auch in eigene Relation kommen.
Beim PTv2 fehlt mir bisher allerdings dies Option und so habe ich eben 40 Varianten einer Linie anstatt im optimalen Fall nur jeweils ein Segment in jede Richtung für diese Linie.

Das Stichwort heißt multilinestring Relation und es gibt schon ein Proposal, sehe aber nicht, das es hier was hilft, da es um das Zusammenführen von Eigenschaften aus verschiedenen Objekten geht. Habe eventuell auch nicht ganz verstanden wie, Du Dir das vorstellst. Brauche ich dann eine Relation für den Straßennamen und die Klassifizierung eine weiter Relation für maxspeed zusätzliche Relation für Spurtagging und so weiter? Das klingt nach API 1.0, aber ich lasse mich gerne Überraschen.

Wenn ich es richtig verstanden habe, ist für Validator gerade ein Plugin geplant, was fehlende Merkmale auf kurzen Teilstücken monieren soll.
Mit Filter und Strg+W oder auch den zusätzlichen “Selection” Werkzeugen von utilsplugin2 ist auch schon jetzt die Auswahl von aufeinander folgenden Linien möglich.
Eventuell könnte in JOSM die Such-Funktion nach Objekten mit identischen Merkmalen verbessert werden, da sie bei mir iM nur für ein Merkmal funktioniert.

Ja, im Prinzip so in der Art wie du es beschreibst. Das tut aber nur, wenn man nicht mehr ala josm in den puren Daten arbeitet, sondern. Ich gebe dir aber recht, dass es eher nicht API 0.7, aber es löst das ganze “wahllose” Aufteilen von Geometrie, die an sich nicht nötig ist. Gleichzeitig kann man die Eigenschaften separiert und kann sie in “Layern” anzeigen. Einzig wenn ich an der Geometrie was anpassen, muss ich (oder der Editor im Hintergrund) alle “Layer” haben.

Viele Sachen sind davon irgendwie vorhanden. Nur halt in einer Form ala: Rumdoktern an den Symptomen, nicht korrigieren des Problems.

Ein erster Schritt für API 0.7 könnte ja sein, dass man Relationen aus Teilwegen zusammensetzen kann und nicht nur komplette Wege. Daran kann man probieren, was möglich ist.

Dann könnten Editoren nachziehen. Nicht der Auswerter könnte Routing nutzen, sondern der Editor und damit den Mapper unterstützen. Bspw. ich will eine Radroute eintragen wähle Startpunkt und Zielpunkt und solange Zwischenpunkte, bis das Ergebnis passt. Der Editor trägt mir dann die Route mit Teilwegen ein. Quasi Win-Win. Der Mapper vergisst keine Segmente, er muss keine Wege dafür splitten und der Auswerter hat statische Daten der Route zur Darstellung.

Nur als Hinweis: ihr erfindet gerade neu, was im Oktober 2007 abgeschafft wurde (segments).

Wenn jemand ne Node löscht und dabei eine punktbasierte Routenrelation schrottet ist das nicht viel anders als wenn jemand ne Node löscht, die Teil eines 2-nodigen Ways ist, der widerrum Teil einer wegbasierten Routenrelation ist… Im Übrigen gibt es mit Enforcement Restrictions bereits Relationen, die Nodes als Member (from/to) haben - und damit Erfahrungen, wie sich nodebasierte Busrouten im Editor anfühlen könnten (Tip: JOSM warnt wenn man diese Nodes löscht) und, indirekt, wie häufig solche im Vergleich zu wegbasierten Routen kaputt gehen.

geht schon :wink: Stützpunkte gibt es halt noch nicht… nicht definiert/abgestimmt/beschlossen :confused:

https://www.openstreetmap.org/relation/11105612

Tool:

https://greymiche.lima-city.de/ptv2_platform_to_rte/index.html?relation=11105612

ergibt:

http://brouter.de/brouter-web/#map=15/48.3139/11.9000/osm-mapnik-german_style&lonlats=11.899769,48.297435;11.900347,48.295196;11.891447,48.29799;11.863863,48.32432;11.874713,48.342008;11.89078,48.358713;11.820052,48.374943;11.819542,48.386242;11.824239,48.386379;11.837266,48.386165;11.869489,48.407798;11.877726,48.411677;11.880435,48.41296&profile=car-eco

Problem sind halt noch fehlendes Bus-Profil für Router… und Stützpunkte bzw. Via Punkte sind bisher nicht vorgesehen in Ptv2

Gruß Miche

Bei bus-routen stelle ich mir sowas praktikabel vor, wenn der verlauf nicht 100%ig ist, ist es kein Beinbruch. Aber bei den anderen Routen-Relationen wirds schnell blöd. Wenn der einfache Wanderweg auf einmal über den Klettersteig geht, nur weil irgendwo was im richtigen Weg kaputt ist. Oder die Bundesstraße durch den Ort geht oder die Radroute plötzlich ihren verlauf ändert, nur weil ich irgendwo ein surface=cobblestone ergänzt habe.

Mich würde interessieren, wie die Idee ist, das routing global korrekt hin zu bekommen. Theoretisch brauchst du eigentlich einen dummen router, der alles ignoriert an Eigenchaften und immer das kürzeste nimmt. Alles andere dann per Stützpunkte.

Das Problem wird sein, dass du eigentlich nie genug Stützpunkte hast, außer du setzt alle zehn Meter einen. Wird mal irgendein kürzerer Weg zwischen den Stützpunkten A und B neu angelegt, schon wird die Wanderroute falsch angezeigt. Man kann von einem Newbie, der nur in bester Absicht einen neu erstellten Fußweg einträgt, unmöglich erwarten, die Umgebung nach Wanderrouten abzusuchen, die irrtümlich darüber geroutet werden könnten, und gegebenenfalls neue Routingpunkte in die Relationen einzubauen, um das zu verhindern.

Hallo Simon, ist aus meiner Sicht jetzt erstmal kein wirkliches Argument. OSM in 2007 und in 2021 kannst du nun wahrlich nicht vergleichen was die Datendichte an geht.

Aber wie gesagt: Mein eigentlicher Punkt ist, dass das Problem nicht daher kommt, dass Objekte zerstückelt werden, sondern dass Menschen beim Editieren fehler machen, Dinge übersehen und man besser da ansetzt, die Fehler zu verhindern. Unser Datenmodel kann (fast) alles abdecken, was man so brauchen kann.

Nur mit zunehmendem Detailreichtum sind aktuelle Editoren für den Gelegenheitsmapper nicht mehr trivial zu bedienen, weil er Sachen beachten muss, von denen er keine Ahnung hat. Bspw. in jOSM muss ich erst manuel die Geometrie erstellen oder anpassen=splitten. Alternativ könnte man statt dem manuellen splitten auch ein simples routing haben. Route von Node A über B und C nach Node D und definiere die Oberfläche als gravel. Intern würde jOSM alle nötigen Daten vom Server laden, dann an meinem Startpunkt A einen Node einfügen und den Weg teilen, inkl. aller Anpassungen, gleiches beim Endweg mit dem Endpunkt D. Entlang der Route trägt er überall surface=gravel ein. Ist irgendwo schon surface=concrete definiert gibts eine Rückfrage.

Der Mapper kommt also nicht mehr mit den Daten in Berührung und kann Fehler wie kurze Wegegmente undefiniert lassen nicht mehr machen. Gleichzeitig muss sich auch nicht jeder Auswerter einen Eigenen Router basteln.