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.
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.
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”.
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
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
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.
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!
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.
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.
Ich oute mich hier mal als so einer, der für das Ändern von Fahrbahnmarkierungen für Fahrstreifen, für unterschiedliche Geschwindigkeitsbegrenzungen, für Busrouten, Wanderrouten u.a. Straßen aufsplittet. Und ja, ich setze die Geschwindigkeitsbegrenzung da hin, wo sie hingehört, an die Stelle des Verkehrsschildes.
Warum mache ich das?
Weil das Datenmodell, das wir verwenden, eine andere Vorgehensweise nicht zulässt.
Weil ich so erzogen wurde, nämlich: genau zu arbeiten. In meinem Beruf wird Pfusch („ach, das passt schon irgendwie“) nicht akzeptiert.
Mir ist auch klar, das eine Zerstückelung der Straßen immer größere Probleme beim routing (Rechenaufwand, Speicherbelegung) hervorrufen werden.
Und es gibt immer noch Mapper, die es cool finden, das alles, was nicht bei drei auf dem Baum ist, mit dem nächstliegenden highway verbunden werden muss.
Meine Schlussfolgerung daraus: das Datenmodell muss den heutigen Erfordernissen angepasst werden.
Als OSM aus der Taufe gehoben wurde, konnte sich wahrscheinlich keiner vorstellen, welche Dimension das annimmt.
Aber wozu haben wir eine OSM-Foundation? Wozu haben wir eine Data Working Group? Das wäre doch mal eine Aufgabe, zu organisieren, dass das Datenmodell weiter entwickelt wird.
Das dümmste, was wir tun könnten, wäre:
Daten wegwerfen
Daten nicht erfassen, weil sie im Moment unbequem sind
Damit meine ich nicht, dass wir die Farbe des Schildes, auf dem die Öffnungszeiten des Tante-Emma-Ladens geschrieben stehen, erfassen, sondern die Daten, die dem Namen Open>STREET<Map zugeordnet werden können.
Es kommt oft vor, dass eine Wanderroute von einem Waldweg auf eine Bundesstraße stößt und sie 10 oder 20 m weiter auf der anderen Seite wieder verlässt. Das als Kreuzung zu mappen, um Auftrennen zu vermeiden, hieße Nutzer zu verwirren, weil die Bundesstraße eben nicht einfach nur überquert wird. Gerade an solchen Stellen ist die präzise Abbildung ein großer Vorteil von OSM. Wanderer können die Information, dass es auf der Straße langgeht, schon bei der Vorbereitung gebrauchen - denk mal an eine Tour mit kleinen Kindern. Und das Stück Straße einfach aus der Relation rauslassen? Für menschliche Nutzer geht das, sie sehen ja, wo es weitergeht. Für maschinelle Auswerter ist das nicht so einfach, wenn die Relation Lücken hat.
Da hat JOSM auch recht: Da ist dann entweder Brücke, Durchlass oder Furt. Beim ersten muss man die Straße splitten, beim zweiten das Gewässer, beim dritten keines von beiden.
Und wenn man nichts Genaueres weiß, kann man die Warnung auch ignorieren.
Eine Brücke zu ignorieren, damit ein Router weniger Aufwand hat, halte ich für einen grundfalschen Ansatz und einem Gewässer in der ganzen Länge layer=-1 zu geben, damit JOSM nicht mehr meckert, ebenfalls.
Datensparsamkeit in dem Sinn, dass nicht alles zentimetergenau erfasst werden muss, ist ok, aber dazu absichtlich falsch mappen ist für mich nicht akzeptabel.
Ich überprüfe die Korrektheit einer Route u.a. über deren Lückenlosigkeit. Das ist für mich ein sehr wichtigste Werkzeug zur Datenpflege.
Vielmehr sollten sich die Editoren des Problems annehmen. Wie wäre es z. B., wenn man mit einem Dreifachlick automatisch die gesamte Straße bis zur nächsten abzweigenden Kante markieren könnte.
Oder durch Drücken eines Shortcuts immer die jeweils nächste Kante mit zur Auswahl hinzunehmen, je nach Shortcut in aufsteigender Richtung der zuerst ausgewählten Kante oder in absteigender oder in beiden Richtungen.
