Den meisten muss ich keep the history wohl nicht erläutern. Und ich bin mir durchaus bewusst, dass es durch ‘split’ zu neuen Elementen und durch ‘merge’ zu gelöschten (bzw. inaktivierten) Elementen kommt. Allerdings ist mein Eindruck, dass das systematische Löschen und Neuzeichnen von Objekten als Arbeitsmethode nicht geduldet wird.
Wie andernorts erwähnt, habe ich nicht die Energie für endlose Diskussionen über etablierte OSM-Regeln – schon gar nicht abseits meiner Muttersprache. Möchte dies jemand ansprechen, oder ist aktives Wegschauen das mittlerweile bevorzugte Vorgehen?
Demnach gab es zumindest schon eine Sperre auf Grund von Wäldern, die etwas “overnoded” erfasst wurden.
Bzgl. keep the history könntest du an einem entsprechenden Änderungssatz einen Kommentar hinterlassen und um eine entsprechende Änderung des zukünftigen Mappingverhaltens bitten (die Wiki-Seite könntest du entsprechend verlinken). Wenn dann keine ausreichende Antwort oder Änderung des Verhaltens erfolgt, kannst du dich ggf. an die DWG wenden.
Naja, gegen Micromapping von Strassen habe ich nichts und gerade bei Bergstrassen bin ich froh über die Details welche die genaue kurvigkeit anzeigen. Gibt da schöne Apps wie kurviger. Wenn wir schon 5cm luftbilder haben, können wir die auch nutzen. Aber ja, löschen und neumachen ist eher uncool.
Merci d’attirer mon attention sur ce point. Je ne m’étais pas rendu compte que l’historique était perdu selon lequel des tracés d’une route divisée je garde. Il s’agit simplement d’une erreur de compréhension de l’outil. J’en tiendrais compte à l’avenir. Concernant le “overnodding”, je pense avoir démontré que je suis les conseils de la discussion de 2022 et je simplifie moi-même régulièrement certaines surfaces.
Erstmals Danke, dass du dich gemeldet hast. Die Werkzeuge sind tatsächlich nicht immer intuitiv und iD hatte mir immer zu hohe Latenzen, was ständig zu “dragged nodes” führte.
Grundsätzlich ist es wichtig, dass das Problem erkannt ist und sich nicht weiter zieht. Ich bin im Moment aber mit der Frage überfordert, wie dies korrigiert werden kann. Es dürfte einige Hundert changesets betreffen, die ich nicht einfach zurücksetzen kann. Und eigentlich schätze ich deine Mühe, das alte und verschwommene Bildmaterial von Bing anhand der Swisstopo Luftbilder zu korrigieren.
Das “overnoding” ist weniger zentral, fiel mir aber bei deinen giratoire auf – ein Kreis ist durch drei Punkte eindeutig definiert, was die OSM-Renderer nicht beherrschen. Aber selbst die schwachen OSM-Renderer bekommen mit 24 Knoten einen akzeptablen mittelgrossen Kreisverkehr hin und brauchen nicht 60 Knoten. Auch hier gilt: don’t tag for the renderer.
Dies geht auf 200 Meter auch mit 12 statt 18 oder 32 Knoten. Auch Bogenelemente definieren sich aus drei Punkten (wie gesamte Kreise), was eine reine Renderingaufgabe ist und kein Problem der Genauigkeit. Und wenn du deswegen mit deinem Tesla einen Unfall baust, ist dies kein Problem der Datengenauigkeit oder von OSM an sich, sondern ein klassischer Fall von “Nichtbeherrschen eines Strassenfahrzeugs” welches mittels Strafbefehl gelöst würde. Just saying.
Ich frage mal in die Runde, ob das überhaupt korrigiert werden muss. Klar ist “keep the history” das Ziel, aber ein Revert finde ich hier auch nicht zielführend.
Das ist nicht "tag for the renderer“, sondern schlichtwegs eine unterschiedliche Herangehensweise, nicht? ID zeichnet aus meiner Sicht deutlich mehr Knoten in Kreise als JOSM, in der Umgebung von Bern ist das oftmals bei Silos zu sehen. Solange wir nicht Bezier-Kurven in OSM haben können, wird es da immer Unterschiede geben. Und 24 oder 60 Nodes im Kreisel ist ich weniger relevant als 10000 Nodes in grösseren landuse-Polygonen.
Bleiben wir hier beim Thema und „spielen weniger auf Mann“, OK?
iD hat bis vor kurzem eine fixe Anzahl an Punkten für einen Kreis gesetzt. Seit dem letzten Update wird aus einem Bereich eine optimalere Anzahl Punkten ausgewählt.
Sorry, ich habe nichts von einem Revert geschrieben – zumindest nicht so wie dir das vorschwebt. Würde nach zwei Jahren auch eine Unmenge ‘conflict resolution’ produzieren. Das Ziel ist die Originalobjekte (respektive deren ID) auf die neue Geometrie zu übertragen. In JOSM wäre das ein Klick, solange die neue Geometrie nicht in die Datenbank hochgeladen wurde. So bleiben nur Umwege mittels merge-Funktion. Level0 könnte dies allenfalls, beherrsche ich allerdings nicht.
Manchmal bin ich froh, dass ich nicht alles mitbekomme. Erklärt im Nachhinein auch einiges. Allerdings bin ich merklich irritiert, dass nach der kompetenten Antwort von @whb eine Reaktion auf etwas kommt, was ich explizit als subjektive Randbemerkung gekennzeichnet habe.
Können wir sehr gerne machen, ich wäre sogar äusserst froh, wenn wir bei den technischen und fachlichen Aspekten bleiben könnten, statt thematisch immer sofort zu Optik und Ästhetik zu wechseln.
Das iD selber das subjektive ‘overnoding’ verursacht ist äusserst unglücklich, aber symptomatisch für meine Resignation gegenüber iD und gelegentlich auch dessen Nutzern. Das befeuert den Irrglauben “mehr ist besser”. Wenn man vor lauter Knoten, den zugehörigen Weg nicht mehr zuverlässig im ersten Anlauf selektiert bekommt, dann sollte dies ein Alarmzeichen sein.
Habe ich beim Überlesen rein interpretiert, exgüse.
Das habe ich mir den Bezierkurven anzudeuten versucht. Solange dies nicht in Renderern oder Routing-Apps ankommt besteht immer die Chance, dass sich Editor:innen, dies extrem genau nehmen an Louis Borges‘ Karte aus On Exactidude in Science annähern und (deutlich) mehr Nodes zeichnen als für eine Karten-Abstraktion nötig wäre.