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 
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.
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.
Da gab’s mal ein Proposal, Streckenrelationen vorzugsweise nur noch mit Waypoints zu definieren. Damit würden Splits unnötiger werden.
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.
Ab welcher Länge würdest du Splitten “erlauben”?
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.
+1
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.
Oder gibt es sowas in JOSM schon?
turn:lanes: https://wiki.openstreetmap.org/wiki/User:Dex2000#turn:lanes.2C_turn:lanes:forward_und_turn:lanes:backward_DE
(da kann man gut abschätzen, wieviele böse Splits dazugekommen sind ;))
Zum Thema: Ich sehe (auch) kein Problem darin eine Strasse da zu splitten, wo sich eine Eigenschaft ändert.
Wo sich’s vermeiden lässt, sollte man vlt. drauf achten. Eine Strasse splitten, weil ein Rohr drunter liegt, ist natürlich Quatsch.
@abrensch: Kannst Du mal beschreiben, wo genau die Stückelungen Probleme bereiten? Ich kenne das nur aus mkgmap (Garmin OSM Karten) Sicht. Dort entscheidet der Style für jeden OSM Weg einzeln, welche Garmin Attribute der Weg in der Karte haben soll. Das sind allerdings nur sehr wenige. So gibt es z.B. nur ein Bit für surface (paved/unpaved) und drei Bits für maxspeed. Nach der Umwandlung werden zuerst mal alle Wege mit gleichen Garmin Attributen wieder zusammen “geklebt” und mit Douglas-Peucker vereinfacht, um die Split-Punkte wieder loszuwerden. Der zusammengeklebte Weg enthält dann während der Verarbeitung noch die Liste der Original-Wege, so dass man nachvollziehen kann, wo die Daten herkommen.
Im Prinzip müssten doch alle Datenverarbeiter ähnlich vorgehen können?
Freu’ mich über die breite Diskussion hier, weil zeigt, dass zumindest bei den Forums-Teilnehmern es ein Problembewusstsein bzgl. der Zersplitterung gibt.
Aber eins möchte ich noch klarstellen:
ich spreche hier nicht als (B-) Router-Entwickler, sondern in meiner Rolle bei der Fernstrassen-QS (brouter-suspects). Und da sehe ich es eben immer wieder, dass es die kaputt-gemappten = zersplitterten Ecken sind, wo die Fehler herkommen, z.B. gerade eben:
https://www.openstreetmap.org/changeset/103563087
Der Grund für den Split hier ist unklar, könnte das lane-mapping sein, aber das ist wahrscheinlich auch falsch. Kollegen wie dieser können einfach nicht so genau auf Vespucci schauen, um auch die kleinen Abschnitte noch zu sehen.
Als Router-Entwickler habe ich mit der Zersplitterung garkein Problem - das interne Datenmodell von BRouter splittet zusätzlich noch an jedem nicht-trivialen Node, und trotzdem kommt das Datenvolumen fast ausschliesslich aus der Geometrie, nicht aus dem Tagging.
Wenn es um das Motto geht
“So genau wie nötig, so allgemein wie möglich”,
stimme ich zu.
Das *kann *ein Umdenken bedeuten, z.B. nicht alle straßenbegleitenden Features wie Gehwege an die Straße zu taggen, damit nicht bei jeder Änderung derer Eigenschaften die Straße gesplittet werden muss.
Es gibt aber Eigenschaften wie Zahl der Spuren und Geschwindigkeitsbeschränkungen, wo man mMn in den sauren Apfel des Taggens am way beißen muss und in der Folge das Splitten in Kauf nimmt.
Da bin ich bei dir. Je mehr man mit kaputte Dinge reparieren beschäftigt ist um so negativer sieht man diese mapping Praxis.
Die Routen Relationen könnte man mehr mit Routing arbeiten bzw. OSM teilweise oder ganz abstrahieren.
Es gibt einen Unterschied zwischen “Pfusch”, den sich kein Handwerker nachsagen lässt, und effizientem Arbeiten. Als guter Handwerker muss man wissen, wo es auf die Genauigkeit ankommt, und wo man fünfe gerade lassen sein kann, weil das für alle das Leben einfacher macht. Ein schlechter Handwerker arbeitet ungenau an Stellen, wo es drauf ankommt - oder akribisch genau, wo es eh keine Rolle spielt.
Die unserer Arbeit zugrunde liegenden GPS-Daten oder Luftbilder können leicht mal 10 Meter daneben liegen. Wenn ich ein Ortseingangsschild sehe und drei Meter danach ein Tempolimit 40, mappe ich dann ein 3-Meter-Stück mit Tempolimit 50? Ganz bestimmt nicht - höchstens vielleicht, wenn um die Stelle seit 10 Jahren im Gemeinderat gestritten wird und es tatsächlich signifikant ist, dass es dort die berühmten “drei Meter von Kleinkleckersdorf” mit eigenem Wikipedia-Artikel gibt.
“Genauigkeit” in OSM darf nicht zum Selbstzweck werden. Man muss unterscheiden, wo es drauf ankommt, und wo nicht.
(Edit: Womit ich nicht sagen will, dass Protoxenus einem Handwerk nachgeht, das weiss ich nicht, aber für Programmierer, Ärzte und Piloten gilt das gleiche…)
(Edit: Protoxenus richtig geschrieben…)