Ich bin vor kurzem im Wiki auf die Seite „Relationen sind keine Kategorien“ bzw. die Verkehrsverbund-Sammelrelationen gestoßen und da ist mir erstmal aufgefallen, dass in meiner Gegend (Mitteldeutscher Verkehrsverbund bzw. MDV; Sammel-Relation) genau das noch getan wird. Schlimmer noch: Ich habe selbst eine Sammel-Relation erstellt, da mir am Anfang nicht bewusst war, dass dies nicht gewollt ist bzw. nur einen größeren Mapping-Aufwand darstellt und keinen Mehrwert bringt. Asche über mein Haupt. Ich werde die Relation natürlich zeitnah wieder auflösen.
Wäre es hier nicht vielleicht sinnvoll bei allen Sammel-Relationen einen Hinweis als Notiz oder fixme anzubringen, mit dem ungefähren Wortlaut:
Das wird in OSM viel “missbraucht” - Es gibt für jede Bundes/Landstraßen relationen und mapper die das fleissig pflegen. Durch die ref ist das halt unsinn aber - tja
Unsinn wäre es nicht, wenn man alle Informationen/Daten z.B. zum Objekt “Bundesstraße” wie ref an die Relation taggen würde, statt an jeden way. Analog zu Radrouten und Wanderwege.
Naja… was bringt denn das fixme? Wenn du es nicht selber löschen willst, wäre es besser hier zu diskutieren und dann hier zu entscheiden, welche Relationen evtl. gelöscht werden sollten.
Das fixme wäre nur eine Übergangslösung, da als Erstes bei jedem Mitglied der Sammel-Relation geprüft werden müsste, ob den auch der network=* und operator=* Tag richtig oder überhaupt hinterlegt sind und erst dann die Sammel-Relation gelöscht werden sollte. Da es mir hier nicht nur um die MDV Sammel-Relation geht, sondern z. B. auch um die im oben verlinkten Wiki-Artikel, ist es mir jetzt nicht auf die schnelle möglich, die Relationen ordnungsgemäß aufzulösen. Mit dem Hinweis wären aber andere Mapper informiert und können sich ggf. auch darum kümmern.
Was heißt denn drum kümmern? Du lädst dir die “Sammelrelation” ins jOSM, lädst alle Kinder runter. Dann markierst du alle und schaust, was es im network (etc.) für Werte hat. (operator kann ja unterschiedlich sein). network kann auch semikolion-getrennt andere Werte haben. Alle “richtigen” Relationen kannst du gleich aus der “Sammelrelation” löschen. Der Rest ist dann etwas Auffand. Jenach dem wie gut der Verkehrsbereich mit PTNA fehlerfrei gehalten wird. Sprich, wenn network halbwegs gepflegt ist, ist das eine Sache von 5min.
Das das jemand tut, weil du ein fixme gesetzt hast musst du nicht hoffen. Die Mapper, die sich um die Relation kümmern haben sie ja angelegt trotz dessen es die Regel gibt.
Es geht um KISS - Und relationen ist nunmal das komplexeste was OSM zu bieten hat. Und ich weiss aus den 10+ Jahren die ich routing überwache - Relationen ist das was kaputt geht. Da kommt ein popup in irgendeinem Editor - das wird schnell weggeklickt - zack kaputt.
Und einen “ref” verteilen kann jeder - Und darum gehts bei OSM - KISS - Es muss so einfach sein das auch nicht informatiker, nicht technik affine Menschen konstruktiv mitarbeiten können. Wenn du alles in immer kompliziertere Datenmodelle quetscht wird die Anzahl der Menschen die überhaupt in der Lage sind beizutragen immer kleiner.
Und wir hatten diese Diskussion schon vor 15 jahren. Damals hat die immer die “josm” fraktion, auf die “potlatch” fraktion geschimpft. Und das war so - Die profis sind irgendwann ziemlich schnell auf josm umgestiegen, und die Einsteiger haben im Potlatch die relationen kaputt gemacht.
Been there, done that.
Relationen müssen die ultima-ratio sein für dinge die sich nicht anders abbilden lassen.
Du kannst alles auch ohne Relationen abbilden. Statt einer Boundary-Relation kannst du auch alles in dutzende Tags an jeden Grenzweg packen. admin_2:left:name=Deutschland + admin_4:left:name=Niedersachsen usw. Auf einmal ist die Relation KISS
Das ganze hat nichts mit ultima-ratio zu tun, sondern immer, was ist einfacher zu warten.
…ich hab auch schon ÖPNV-Routen erfasst, ist aber schon eine Weile her (für mich selbst ist das Thema zu dynamisch, als daß ich es in meinem Bereich schaffe, zeitnah zu aktualisieren)…
Aber! Um eine solche Sammelrelation wieder aufzulösen, würde ich es zu 100% genau so machen, wie du es beschrieben hast! Danke!
…Trotzdem meine erweiterte Meinung: wenn man es im Detail betrachtet:
…ist das für mich nicht mehr KISS… → das ist es schwieriger, alles in entsprechende Tags zu packen! Der Mittelweg ist das Ziel!
Mit einschlägig dokumentierten weiteren Geodatentyp ist sowas leichter zu erfassen!
OSM selbst hat es aber leider bisher nur nicht geschafft, die OGC-Standards umzusetzen…
Nein - kannst du nicht. Du kannst nicht das Verhältnis von 2 oder mehr verschiedenartigen Objekten Beschreiben ohne exakt das objekt was eine beziehung zu diesem hat zu referenzieren. Du kannst natürlich auf einem way sagen - “via:nodeid=4711” - dann hast du aber zur relation nichts gewonnen.
Also klassisch die turn restriction.
Und auch bei Boundaries wird es spätestens dann unmöglich wenn wir von ex und enclaven sprechen.
Klar geht das. Eine turn-restriction wäre dann no_turn=<source_direction>,<destination_direction> und dann halt mit Semikolon getrennt die nächste Einschränkung. Das geht alles. Ist aber komplexer als eine stupide Turn-Relation. Genauso wie bei den Grenzen und Multi-Polygonen.
Wieso? admin_2:left:name=Deutschland und admin_2:right:name=Deutschland ist eindeutig. Alle Wege laden und dann musst du dir das halt alles zusammen bauen.
Genauso wie du es bei der Sammelrelation forderst. Wenn ich den ganzen Verkehrsverband haben möchte, muss ich mir die dazugehörigen Routen zusammensuchen und hoffen, dass alle Bus-Routen entsprechend gepflegt sind.
Bei der “Sammel-Relation” ist der Nutzen nur sehr gering im Vergleich zum “Schaden”. Wenn OSM-Tools aber sowas wie Vererbung unterstützen würden, sähe das wieder anders aus. Dann hast du den Vorteil, dass du alle Infos zum Netzwerk (network:guid, wikidata, … nur noch in einer Relation pflegen musst und nicht mehr in hunderten.
Du weisst schon wie die turn restrictions so funktionieren?
Nur um das nochmal aufzuschreiben. “direction” oder “richtung” spielt überhaupt keine rolle. Also du kannst eine no_right_turn in eine no_left_turn verwandeln und die verändert ihr verhalten überhaupt nicht.
Das einzige was interessiert ist ein “no” oder “only” am anfang der restriction, und die objekte die da referenziert werden - der rest ist völlig schnuppe.
Denn was du in der turn restriction definierst ist das du von way A im Knotenpunkt B nicht auf weg C oder NUR auf weg C wechseln darfst. Ob das links/rechts/straight ist ist total wumpe. Das wird nur dafür genutzt dir ein tolles icon hinzumalen.
Und da kommen wir schon zum problem der Restrictions. Ich monitoring das Routing in NRW seit mehr als 10 Jahren und bekomme mails wenn sich routing ändert.
Der häufigste grund warum routing kaputt geht sind turn restrictions. Da werden einfach überall total sinnfrei fiktionale turn restrictions hingekleistert und die mapper glauben das das “straight” “left” “right” irgendeine Auswirkung hat. Das ist aber völlig irrelevant. Es wird lediglich definiert welche kanten/edges innerhalb des Graphs hier benutzt werden dürfen und welche nicht. In welche “richtung” geht ist völlig egal.
Also - vorsicht bei Aussagen: “Das ist ja alles kein Problem”.
Ich will auch darauf hinweisen, dass das Thema “Relationen als Kategorien” auch bei Carsharing eine Rolle spielt. Es gibt unzählige Kategorisierungs-Relationen nach dem Motto “Cambio-Stationen in Hamburg“.
Ich habe das beim MDV umgesetzt, siehe Änderungssatz 176490837. Bei den anderen lt. Wiki werde ich aber erstmal ein fixme anbringen, da es leider nicht in 5 Minuten erledigt war (Liegt aber vielleicht auch an meinen JOSM Skills ). Ich werde das bei den andern nach und nach angehen, sofern niemand anderes schneller ist als ich.
Das sehe ich ein bisschen anders. Viele der Sammel-Relationen wurden schon vor über 10 Jahren angelegt. Den Personen, die diese heute pflegen, wenn sie den überhaupt gepflegt werden, ist vielleicht nicht bewusst, dass das so nicht gewollt ist.
Ja… so trivial funktionieren sie (fürs Routing), weil wir Relationen dafür nutzen.
Den Information, dass du von Süden kommend nicht nach Osten fahren darfst (genau darum geht es) kannst du auch per simplen Key/Value an dem Kreuzungsnode erfassen. Es ist halt für den Mapper als auch den Auswerter komplizierter. Die Relation ist einfacher, aber es würde auch ohne gehen.
Wenn du aus der Relation ein Schild rendern willst, klappt das nicht mehr. Völlig schnuppe ist was anderes
Ja… nennt sich pre-processing. Rechne den Winkel der Kreuzungswege aus und transferiere die Info in die OSM-Wege und aus den OSM-Wegen berechnest du deinen Graphen. Geht, ist aber nicht so komfortabel. Das ist doch genau das was ich sage.
Pre-processing verlangst du doch auch von den Leuten, die Routen-Netzwerke auswerten wollen.
Vielleicht wäre das mal ein organisiertes Projekt wert, innerhalb dessen man sich nach längerer Diskussion auf ein gutes Schema einigt, das nicht mehr den Grundprinzipien von Relations widerspricht, und dann Stück für Stück alle Verkehrsverbünde in das neue Schema überträgt.
). Ich werde das bei den andern nach und nach angehen, sofern niemand anderes schneller ist als ich.
