Sparsamkeitsgebot Way-Splits

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.

Zufällig grad gesehen:

https://www.openstreetmap.org/#map=19/49.98411/10.84033

schön viele Labels, was? Kommt daher, dass der Weg jedesmal aufgesplittet ist, wenn sich der Straßenbelag am Gehsteig ändert. Führt umgekehrt dann dazu, dass auf https://www.openstreetmap.org/#map=17/49.98489/10.84023 keines der Zipfelchen mehr lang genug ist, um den Straßennamen einzutragen, dann gibts halt keinen mehr.

(Einige Renderer machen daher ein “st_union(geom) group by name”, bevor sie die Labels einzeichnen, aber das macht die Sache langsam…)

Weise mapper haben mal gesagt “wir taggen nicht fuer den Renderer” duckundweg:smiley:

Das passiert aber auch ohne Routing… da werden extra Fußwege angelegt und die Wanderroute führt weiterhin über die Straße.

Bei Routing kann man das Ergebnis mit älteren Ergebnis vergleichen… um automatisch Abweichung festzustellen und dadurch fehlerhafte Bearbeitungen finden.

In der Praxis… braucht man Relationen nicht… man braucht gpx/kml… Dateien. Eine Relation kann als Grundlage dienen ein gpx z.b. zu erstellen. Also eine Relation sollte alle Informationen enthalten um ein Gpx zu erstellen.

Gerade was z.B. Radrouten und Co. anbelangt, sollte man auch mal eine gute Darstellung auf der Karte im Hinterkopf haben. Die sollte fix und verlässlich sein. Ich befürchte, für Radwege und Co. funktioniert eine rein stützpunktbasierte Geschichte nicht. … Ja und nur gpx… kommt sowas bei raus:https://www.spreewald-biosphaerenreservat.de/karte/#&g=4&k=26. Wenn ich als Datenverarbeiter das sehe, läuft mir ein kalter Schauer den Rücken hinunter… Auch darstellungstechnisch ist das gruselig… Man sieht übrigens, welcher der Wege mal aus OSM stammte: https://cycling.waymarkedtrails.org/#route?id=2196978.

Da lob ich mir die in OSM als Relationen erfassten Rad-Routen als Relationen… Solche Radrouten sind auch in der Realität in der Ausschilderung recht stabil. Ja und einmal in OSM gut erfasst, ist der Fehlergehalt recht gering (es sei den iD zerwürfelt aus ner Laune heraus die Reihenfolge). Auch ein gutes Radrouting funktioniert, siehe z.B. auch https://cycle.travel/map.

Sven

Kommt auf den Renderer an, und darauf, welche der Daten wegen derer der way gesplittet wurde, einen interessieren. Wenn man Abstriche bei der Aktualität macht, man man mit Vektortiles z.B. Straßennamengeometrien machen (die aufwendige Vorberechnung des ST_Union also “vor dem Rendern” machen bzw. beim Vorrendern) und braucht noch nicht so riesige Maschinen wie wenn es live und “sofort” gerendert werden soll, und daraus die Namen rendern.

Ich bin grundsätzlich aber auch schon seit dem Anfang der Meinung, dass man soviel es geht explizit eintragen sollte, anstatt es über properties indirekt auszudrücken, weil das zwar etwas mühseliger ist beim Zeichnen, und auch komplizierter für bestimmte Darstellungen (z.B. fester offset der Linie anhand der Linienstärke einer parallelen Linie, eigentlich braucht man dafür wahrscheinlich zusätzlich die properties), aber dafür einfacher und übersichtlicher ist, lagegetreuer und präziser bei der Form und die Topologie besser abbilden kann. Die Komplexität der realen Welt besteht zwar weiterhin, aber das Modell ist geometrisch näher und die Eigenschaften verteilen sich besser auf die Stellen wo sie auch hingehören, anstatt andere vermeintliche “Haupt”elemente zu überfrachten (insbesondere highways)

Klar kann “man”. Nur: Wer ist “man”?

Szenario: Auf einem Hügel wird ein Windpark gebaut und zwei neue Anfahrtswege von Norden und von Süden angelegt. Ein noch wenig erfahrener Mapper trägt diese Wege ein, was natürlich gut und richtig ist. Er kann unmöglich auf dem Schirm haben, dass a) eine Wanderroute auf einem alten Schotterweg westlich um den Hügel herumführt, b) diese Wanderroute nur über zwei Stützpunkte definiert ist, einer nördlich, einer südlich, was bislang auch gereicht hat, und c) die zwei neuen Weg eine kürzere Verbindung zwischen den zwei Punkten ermöglichen, eventuell nur indirekt über weitere Wege, so dass die Relation in den heruntergeladenen Daten gar nicht vorhanden ist. Dennoch wird die Relation jetzt über den Hügel geroutet statt außenrum, obwohl sich der markierte Wanderweg gar nicht geändert hat.

Wer macht jetzt den Vorher-Nachher-Vergleich, um das festzustellen? Der Mapperkollege kann es nicht, er weiß ja gar nichts von der Relation, und sie wurde durch seine Neueinträge gar nicht berührt.

Das kannst du, wie oben gesagt, nur zuverlässig verhindern, indem du alle 20 oder spätestens 50 Meter einen Punkt in die Relation setzt, um später versehentlich entstehende Abkürzungen auszuschließen. Gut, kann man machen. Muss dann nur ausgeschlossen werden, dass die Punkte bei irgendeiner Bearbeitung gelöscht werden.

Es geht nicht um fehlerhafte Bearbeitungen, sondern um sinnvolle, die ungewollt das Punkt-zu-Punkt-Routing verändern, indem sie Abkürzungen ermöglichen, die beim Anlegen der Relation nicht berücksichtigt wurden, weil sie noch nicht da waren.

Ja, und wo wird das ältere Ergebnis zwischengespeichert, wie lange, …?
Und wer sagt, dass das ältere Ergebnis das korrekte, das gewollte widerspiegelt?

Wer entscheidet, ob das neue Ergebnis ein Fehler oder die Korrektur eines Fehler ist?

Die ‘neue’ Route wird durch eine Algorithmus ermittelt, nicht durch das Vorhandensein von Ways als Member in einer Relation.

Eine Diskussion der potentiellen neuen Probleme durch Stops und Stützpunkte beim Editieren, bei der QS, beim Rendern, … ist für mich noch nicht abgeschlossen und sollte mMn neben den Vorschlägen und deren Vorteilen zusammen mal dokumentiert werden.

Die Probleme mit dem PTv2 kennen wir (z.T. = “split-ways” auch durch Tools verursacht), ein Re-Design wird neue Problem mit sich bringen.

Will OSM das GIS vom Amt für Tiefbau sein? Die Brücke also zentimetergenau am Widerlager beginnen lassen und das Tempo 40 Schild dort, wo es am Luftbild erscheint, auch wenn drunter ein Schild, “in 25m” hängt, das am Luftbild aber nicht erkennbar ist, genauso wenig wie die Aufschrift “40 km/h Zone” übrigens… Wozu eigentlich OSM-Carto, wenn es eh 20 oder 80cm Luftbilder gibt? Das geeignete consumer-GPS-handheld das nicht Minuten für eine einzelne Messung braucht, auf dem man sich am Bilschirm dort sieht, wo man laut Luftbild tatsächlich ist, das kommt sicher in den nächsten 20 bis 50 Jahren auf den Markt.

PS: War wirklich tun mit einem Straßenabschnitt, der auf 10m einen Hunderter erlaubt? So schnell beschleunigt kein mir bekanntes Fahrzeug (links 50, rechts 40)! Ich plädiere für “fallen lassen”.