Sparsamkeitsgebot Way-Splits

ohne aktuellen Anlass, einfach um mal mein aufgestautes Unverständnis loszuwerden, möchte ich mal den Mikro-Mapping-Irrsinn beschreiben, der vom Ansatz her zu einem exponentiellen Wachstum der Way-Splits und damit ins Verderben führt.

Viele Bestrebungen produzieren Way-Splits, aber das OSM-Datenmodell erlaubt einfach nicht die Ko-Exististenz mehrerer dieser Bestrebungen, und daraus folgt automatisch ein Sparsamkeitsgebot:

  • Bus-Routen Mapper machen sogar vor Kreiselsplits nicht halt

  • Wander-Routen-Mappen splitten auch Bundesstrassen, wenn ihre Route mal für 5 Meter darübergeht

  • Maxspeed-Mapper wollen genau die Schilder-Position abbilden, für jede Richtung einzeln

  • Brücken-Mapper mappen auch eingerohrte Mini-Bäche, und bei echten Brücken muss die Grenze genau am Widerlager sein, auch wenn 5m weiter ohnehin ein Waysplit ist

  • traffic-calming=island braucht natürlich 4 zusätzliche Way-Splits (2 je Richtung), und das obwohl die Verkehrsinsel selbst auch noch gemalt ist

  • TR-Mapper mappen zwanghaft auch “disfunktionale” TRs an Kreuzungen, die also nur Abbiege-Relationen verbieten, die kein intakter Router nehmen würde. Und splitten dann nicht nur am via-point, sondern auch noch woanders, weil sie glauben, TRs brauchen kurze Schenkel. Und noch ganz viele no-u-turns - auch das ein Irrglaube

  • (Turn-) Lane-Mapper wollen es auch ganz genau wissen

Also postuliere ich das Sparsamkeitsgebot:

  • Bus-Routen dürfen Lücken und/oder überzählige Wegstücke haben, Kreiselsplits sind tabu!

  • gleiches für Rad-Wanderrouten: Splits von Fernstrassen sind tabu!

  • maxspeeds: es ist KEINE relavante Information, wo genau kurz nach einer Kreuzung ein Temposchild steht, das Tempolimit gilt ab Kreuzung! Stehen bei einem Tempolimit auf freier Strecke die Schilder für beide Fahrtrichtungen 20m auseinander, dann nimmt man halt die Mitte!

  • Brücken: Brücken sind grosse Dinger mit Schildern dran für max-weight und so. Und wo genau sie anfangen ist unwichtig

  • die Anfahrt auf eine grosse Kreuzung hat genau eine Abschnitt mit (Turn-) Lane Information. Auch wenn eine Rechtabbiegespur erst 10 Meter weiter anfängt

  • TRs: nur funktionale TRs mappen, und für die nur am via-point splitten

  • usw. Liste is nicht abschliessend, aber Prinzip hoffentlich klar.

Welches Problem sollen “deine” Regeln denn überhaupt lösen?

Hm. Ich habe vor ein paar Tagen auch eine Straße aufgeteilt > https://www.openstreetmap.org/changeset/102531317. Hätte ich damit gegen das Sparsamkeitsgebot verstoßen?

@abrensch
Grundsätzlich würde ich dir Recht geben, bei manchen Änderungen meint man die wollen die Realität auf den cm abbilden. Aber ich habe noch nirgens gelesen, dass einer deiner Punkte verboten wäre, höchstens vielleicht ein Best-Practice.

Ich kann dich aber verstehen, mittlerweile hat die Openstreetmap ein Level an Detaillierung erreicht, bei dem man mancherorts wirklich suchen muss, um noch etwas zu finden, das nicht gemappt ist. Dass genau dieses auch getan wird, sieht man daran, dass es überhaupt Diskussionen über das Thema gibt.

Ich seh es schon vor mir: Irgendwann in ferner Zukunft braucht es Google Streetview nicht mehr, man braucht sich dann nur OSM in 3D ansehen, dann sieht man fast das Gleiche. :roll_eyes:

Hmm, “splitten ohne jeden Anlass” hab’ ich ja garnicht in die Liste geschrieben, aber da steht ja auch “nicht abschliessend”, also ja, das war nicht im Sinne des Sparsamkeitsgebots.

Aber worum es wirklich geht siehst Du 30m weiter: https://www.openstreetmap.org/node/345059244#map=19/48.82240/8.71060&layers=ND

Ist ein Way-Split für eine Wanderroute, und an der Stelle ändern sich jetzt völlig grundlos die Eigenschaften der Steinhofstrasse.

Aber selbst das wäre nach “meinen” Regeln noch o.k., da steht ja nur, dass man für sowas keine Fernstrasse splitten sollte.

Ziel ist einfach, die Entropie klein zu halten und damit die Wartbarkeit zu erhöhen und die Fehleranfälligkeit zu vermindern.

Also ich sehe es im Prinzip genauso wie Du. Bei einer Datenbank sollte die Qualität der Daten im Vordergrund stehen und beim Erzeugen von Karten findet eine Generalisierung statt, also sollte eine Geodatenbank generalisierungsfreundlich sein und Mikrodetails sind irrelevant (oder auch unrealistisch weil unterhalb der Meßgenauigkeit).

Allerdings sehe ich uns da auch als Minderheit auf verlorenem Posten. Ich sehe hauptsächlich Mikromapping und übertriebenes Mikromapping auf dem Vormarsch, bei dem OSM eher hingebungsvoll wie ein Malbuch mit winzigsten Details ausgemalt oder auch um unpflegbar veränderliche Daten bereichert wird. Einen Blick für Relevanz und Datenqualität geschweige denn Generalisierung nehme ich nur sehr selten war.

Von daher +1 mit einem tiefen Seufzen. :slight_smile:

Wie würde der brouter das handhaben, wenn an diesem Abschnitt https://www.openstreetmap.org/way/927512070#map=19/48.82292/8.71044&layers=N eine Baustelle wäre und jemand diese eintragen würde (angenommen ich hätte die Straße nicht gesplittet). Wie komme ich von der Calwer Straße zu Im Tann? Ganz außenrum fahren?

PS: Grundsätzlich hast du natürlich recht. Ich finde aber, Wege gehören an Kreuzungen aufgeteilt.

Lücken in Bus- und Wanderrelationen, nur um das Aufsplitten einer Straße zu vermeiden? Halte ich für sehr fragwürdig.

Insgesamt würde eine Anwendung deines Sparsamkeitsgebots meines Erachtens mehr Probleme schaffen als lösen. Sparsamkeit darf nicht zu falschen Eintragungen führen. Wenn eine Routenrelation eine Lücke hat, dann ist das ein Fehler.

Wenn nun einmal ein Wanderweg ein Stück entlang auf einer Fernstraße verläuft, was meines Erachtens von Wanderwegplanern vermieden werden sollte, dann muss halt die Fernstraße hierfür aufgeteilt werden. Es sei denn, es gibt auf diesem kurzen Stück eine begehbare Bankette, die einen parallel eingezeichneten Trampelpfad (surface=grass) neben der Straße rechtfertigen könnte.

Unabhängig vom letzten Satz:

Ein Way muss aufgesplittet werden wenn er unterschiedliche Tags hat: hw=residential und hw=construction rechtfertigen allemal einen Split

Aber: der OP hat wohl noch bus_bay, parking:*, sidewalk und weitere Tags vergessen.

+1

Keine Fehler wegen Sparsamkeit.

Das ist ein Grund, wieso ich bei zunehmender Detaildichte immer wieder dafür plädiere, den Haupt-“way” nicht mit Attributen zu überlasten und statt dessen den lediglich durch einen Bordstein von der Straße getrennten Gehsteig als eigene Linie einzutragen oder auch Parkbuchten nicht lediglich als Attribut an die Straße zu pappen sondern neben der Straße einzuzeichnen.

Seperat eingezeichneten Gewege ermöglichen es dann z.B., Wanderrouten nicht der Straße sondern dem Gehweg hinzufügen.

Separat eingezeichnete Parkflächen ermöglichen es dann, auch Zusatzinformationen wie zulässige Parkdauer oder Behindertenstellplätze einzutragen, ohne damit die Straße “zu belasten”.

Und über all dem schwebt dann der “Aufpasser”: separates Mappen nur bei existierender “baulicher Trennung” …

Mann kann es niemals nicht allen recht machen.

Lücken finde ich nicht ok. Überzählige Stücke, z. B. in Kreiseln, sind aber in Ordnung, weil man die recht einfach rausrechnen kann: Bei drei Segmenten X, Y, Z geht Y halt nur von dem Schnittpunkt X/Y und Y/Z. Der Rest von Y ist dann nicht Teil der Route.

Wenn man Langeweile hat, kann man die Schilder separat als Node mappen :slight_smile:
Laut StVO (§41) stehen “Vorschriftzeichen […] dort, wo oder von wo an die Anordnung zu befolgen ist.”. Wenn man kleinlich ist, ist die Position des Verkehrszeichens also relevant. Ich weiß aber nicht, wie eng das vor Gericht ausgelegt wird. Ansonsten gebe ich dir recht, dass man hier bei OSM gerne etwas ungenau sein sollte. Die Realität ist ja auch nicht exakt.

Für verrohrte Bäche sollte die Straße gar nicht angefasst werden…

Vielleicht lässt sich das mit QA-Tools unterstützen. Oder mit irgendeiner Änderung am Datenmodell, die viele Splits unnötig macht?

Bei der Datenauswertung sollte es möglich sein, Splits wieder rauszurechnen? Es ist generell einfacher, überflüssige Daten wegzuschmeißen als fehlende Daten zu erfinden.

Ich denke dass sich der Detailgrad einem Maximum annähert. Irgendwann ist einfach alles gemappt, wofür sich noch Leute interessieren. “Exponentiell” ist also der falsche Begriff.
Berlin hat derzeit ca. 68 Kilobyte (komprimiert) pro Quadratkilometer. Das klingt gar nicht mal soviel :wink:

Hat irgendwer Statistiken, wie sich die Datenmenge/Dichte von einzelnen Regionen über die Jahre entwickelt hat?

Ohne die Straßen die du rausschmeißen würdest mitzuziehen sehe ich keinen technischen Unterschied zwischen einer Relation mit ‘zulässiger’ Lücke und einer kaputten Relation. Die Relationen müssten demnach aus meiner Sicht regelmäßig von Mappenden geprüft werden ob noch alles im zulässigen Rahmen und fern von Fernstraßen ist. Halte ich für der Datenqualität nicht unbedingt zuträglich.

Im übrigen bin ich persönlich der Ansicht, dass bauliche Trennung da einsetzen sollte wo es für ‘irgendeinen’ erlaubten gewöhnlichen Verkehrsteilnehmer nennenswerten Aufwand beim “Spur”-wechsel gibt. Ich denke da hauptsächlich an Rollstuhlfahrer.

Oder zumindest nicht torpedieren? Meckert nicht JOSM eine Kreuzung von waterway=stream und highway != bridge als Fehler an?

Eine Änderung am Meta-Modell ist eher Science-Fiction (was wurde eigentlich aus dem AREA-Datentyp?)

Aber eine Änderung der Semantik ist viel realistischer, und wenn hier Leute behaupten, sowohl lückenhafte Relationen als auch nicht streng-lineare Relationen seien “kaputt”, dann ist das vielleicht ein Fehler im semantischen Modell?

Für so Anwendungen wie waymarkes-trails oder die Berücksichtigung von Rad-Routen bei BRouter sind weder Lücken noch überzählige Abschnitte ein Problem.

Mit den Anwendungsfällen der Busrouten kenne ich mich nicht so aus. Jedenfalls lässt sich in beiden Fällen per Routing die fehlende Information gewinnen. Bei lückenhaften Relationen ist bei einer Kreiselbaustelle dann aber automatisch die Relation kaputt, während bei überzähligen Abschnitten die Relation stabiler ist gegen Fehler im Strassennetz.

Eins von beiden muss die Routen-Fraktion aber schlucken, sie hat nicht das Recht, das Strassennetz beliebig zu zersägen.

Zumal ja in der Praxis sowieso ganz viele Relationen an Kreuzungen kaputt sind, d.h. der Status Quo funktioniert ja auch nicht.

Nö. Wenn der waterway einen anderen layer hat, dann nicht. Es wird auch nicht “verlangt”, da eine Brücke zu mappen.

Würde man die Sparsamkeitsgebote berücksichtigen, wären Kartendarstellungen von Bus- und Wanderrouten viel umständlicher, weil man erst die Lücken routen muss (ob das immer gut geht?) und dann die Verzeigungen absägen muss. Beim mappen hat man dann auch keinen Überblick, ob die Route ok ist.
Bei OSM geht zwar nicht nur um Karten, aber eben auch.

QS, die auf Vollständigkeit der Routen basiert, wäre komplizierter (Welche Lückengröße ist noch ok, wo fehlt wirklich was?)

Ja, es gibt Splits die tatsächlich unnötig sind (z.B. 1m Asphalt in einem gepflasterten Weg… die Info braucht echt keiner, wobei ich nicht weiß ob es das oft gibt.)

Ein wirkliches Problem ist es auch nicht, denn da wo viel gesplittet wird, ist die Mapperdichte offensichtlich hoch (sonst wär ja nicht viel gesplittet) und dann ist auch genug Arbeitskraft zum Warten da.

(Auch getrennte Fußwege machen Renderen Probleme, so richtig toll ist die Verdrängung bei Carto nicht.)

Na ein erster Anfang wäre erst mal eine Auflösung von Multipolygonen, die zugleich Linien vom Typ highway=* als outer haben…
Da kann man herrlich entsplitten… Ich aber auch sehr aufwendig!

Mal drei Beispiele: Brandenburg, Sachsen, Baden-Württemberg

Sven

Also es gibt für API 0.7 immerhin schon eine sehr grobe Idee, irgendwas mit Segmenten zu machen. Ich glaube zwar nicht, dass sowas in überschaubarer Zeit machbar ist, aber das gilt ja so ziemlich für alle Themen in diesem Zusammenhang, insbesondere auch für Areas.

https://wiki.openstreetmap.org/wiki/API_v0.7#Segments_.28instead_of_fragmented_ways.29

ich sehe das auch so, wieso sollte es unwichtig sein, dass die Wanderroute auf der Hauptstraße entlanggeht? Wenn es einen eigenen (Fuß/Geh-)Weg gibt kann man ja den auch mal explizit eintragen und damit die Flüsse „Splittingsparsam“ eintragen und datenmodellkompatibel eintragen (eigentlich mappe ich bei Gehwegen höchstens die fehlenden Verbindungen wenn ein Künstler da mal wieder ein paar Inseln hinterlassen hat), aber im Prinzip führt nichts dran vorbei, dass wir grundsätzlich immer mehr splitten.

Die Datenauswerter müssen damit zurechtkommen und die ways halt wieder zusammensetzen (je nach Interesse bzw. auf welche tags und Relationen man verzichten kann).

Auf Editorseite könnte ich mir vorstellen, dass man die Benutzerfreundlichkeit beibehält indem man es vereinfacht, zusammenhängende ways mit wenigen clicks zu selektieren anhand der Eigenschaften wie Straße mit diesem name oder ref oder maxspeed bzw. jeden tag die das Objekt hat. Sowas wie rechtsclick auf die Straße, daraufhin eine Liste der tags wo man einzelne aktivieren kann, dann ok und es werden alle angrenzenden Straßenstücke auch selektiert bis die ausgewählten Eigenschaften abweichen. Damit würde man auch Lücken in den Eigenschaften sofort erkennen.
Bzw. nicht „ok“ sondern gleich live alles passende selektieren und durch weitere tags schritt für schritt verkleinern.