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.
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:
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.
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…)
Aber genau das ist ja das Problem: Jeder, der in irgend einer Weise genau arbeitet, wird der Ansicht sein, dass es in diesem Fall drauf ankommt. Denn sonst täte er es ja nicht. Ich finde zum Beispiel weiterhin (wie gestern geschrieben), dass eine Wanderroute, die 10 oder 20 Meter einer Bundesstraße folgt, diese Strecke in der Relation auch enthalten sollte und dass das eine wichtige Information ist. Genau das wird aber im Eingangsposting angeprangert (wenn auch da mit nur 5 Metern).
Dann muss projektweit festgelegt werden, wann Genauigkeit wichtig ist und wann generalisiert werden kann.
Bei der Schreibweise von Namen scheint es dir nicht drauf anzukommen
Da bin ich bei dir. Das drauf ankommen hängt vom betrachtungswinkel ab. Dem Wanderer ist die Wanderrelation wichtig, dem Radfahrer die Radwegrelation und dem Autofahrer die Fernstraße. Ich sehe keinen Grund warum einer dem anderen vorschreiben kann, auf seine Details zu verzichten.
Den Grund für den Split müsstest Du beim Mapper nachfragen. Mit Vespucci ist das 24m lange Straßenstück ohne Probleme sichtbar (auch die Oneway-Pfeile).
