Dann hast du noch eine Abbiegebeschränkung eingebaut, die zwar „only_right_turn“ heißt, aber von way/33117412 (from) zwingend auf way/671515520 führt (to)! Das gibt heftige Routingfehler (und beim nächsten Kartendienst-Vergleichstest schlechte Noten für OSM). Vermutlich waren from und to vertauscht. Bitte sorgfältig arbeiten :D

Wieso hast du denn way/631868362 zum hw=residential abgestuft? Ich mache mal wieder einen secondary draus.

Diese Änderung wurde durch changeset/67968414 zurückgesetzt. Grund: Offensichtlich irrtümliche Bearbeitung.

Hallo HFeierabend, ein Ort wird normalerweise von _einem_ place-node repräsentiert, der auf dem verkehrstechnischen Zentrum des Ortes liegt. Bodenwerder ist derzeit als zwei Orte in der OSM-Datenbank, was etwas schräg ist, es ist ja nur ein Ort. Hättest du was dagegen, den nördlichen Node (= deinen neuen) wieder zu löschen und den verbliebenen auf das Zentrum (etwa Münchhausenplatz, schätze ich) zu schieben?

Hallo Hermann001, bitte achte bei der Überarbeitung von Kreuzungen darauf, dass keine übersteilen Abbiegewinkel entstehen, die real nicht existieren. Bei dieser Kreuzung: osm.org/go/0De7j2txE?layers=N&m= musste man von der Eppsteiner Straße nach links auf die B 455 mindestens einen 140°-Winkel fahren, real ist das eine normale rechtwinklige Abbiegung. Ich hab die Kreuzung mal wieder zurechtgeschoben.

Hallo Bahntech, bitte einzelne Fahrstreifen auf einer Fahrbahn nienienie als separate Ways mappen. Das sieht für einen Router wie drei parallel laufende Straßen aus, zwischen denen nicht gewechselt werden kann, und führt zu übelsten Fehlern. Markierte Fahrspuren auf einer Fahrbahn immer als lanes an den Way taggen, nur baulich getrennte Fahrbahnen als separate Ways. Danke!

Hier nochmal zum direkten Vergleich: https://ibb.co/jDm29t6

Ich wäre dir sehr dankbar, wenn du deinen Tonfall um einige Grade versachlichen könntest. Nach einigen Jahren exzessiven Lane- und Destination-Taggings glaube ich auch nicht, dass ich diese Merkmale vollkommen vernachlässige.

Ich habe eine unvollkommene Darstellung der Kreuzung durch eine andere unvollkommene ersetzt, deren Nachteile ich (immer noch) wesentlich kleiner finde, und du hast jetzt wieder eine (noch schrägere) unvollkommene eingesetzt. Mit Unvollkommenheiten müssen wir in OSM leben, solange wir breite Verkehrsflächen, auf denen man sowohl einen weiten Linksbogen als auch einen weiten Rechtsbogen fahren kann, als Linien abbilden, die diese Breite einfach nicht haben. Wir können nur abwägen, welche Unvollkommenheiten bedeutend und welche unbedeutend sind.

Auch habe ich – entgegen deiner Unterstellung – diesen Edit mitnichten deshalb vorgenommen, weil mein Navi spinnt – das tut es nicht –, sondern weil mir bekannt ist, dass in anderen Fällen bereits überscharfe Abbiegewinkel zu Fehlroutings geführt haben, und weil ich der Meinung bin, dass meine Version die Geometrie /sämtlicher/ Abbiegevorgänge (geh sie mal nacheinander durch) realistischer abbildet als die Vorversion oder deine es tun, nämlich ohne überscharfe Knicke und Zickzack-Führungen – zugegebenermaßen um den Preis zweier „virtueller“ Fahrwege innerhalb der Kreuzungsfläche, wo keine bauliche Trennung ist. Tatsächlich hat im Kreuzungsbereich selbst auch die L 531 keine bauliche Trennung, auch der Quersteg ist daher strenggenommen falsch, streng nach Lehrbuch müssten die Zweige der L 531 für die Kreuzung vereinigt werden, aber das würde – da sind wir uns wohl einig – dem Geradeausfahrer einen Zickzackway präsentieren, der mit dem OSM-Grundsatz „keep straight roads straight“ nichts mehr zu tun hätte.

Wenn du deine Version besser findest, bitte, dann lassen wir sie drin, du fährst da wahrscheinlich öfter drüber als ich und sollst keine Magengeschwüre bekommen :)

Ergänzung: Praxisfragen des Kreuzungs-Mappens und insbesondere des Hinter-Verkehrsinsel-auf-einen-Punkt-Zusammenführens wurden hier mal ausgiebig diskutiert: https://forum.openstreetmap.org/viewtopic.php?id=54616

Der Rechtsabbiegewinkel von way/160279380 auf way/160279385 beträgt jetzt etwa 125 Grad. Entspricht das der Realität? Bei Abbiegewinkeln deutlich über 90 Grad sagen Router im LKW-Modus ganz schnell „da kommen wir nicht rum, nehmen wir lieber einen Umweg“. Deshalb gilt in OSM die Konvention, dass Einmündungen, die nicht real spitzwinklig sind, mit einem Winkel von etwa 90° abgebildet werden. Die Alternative zu der von mir gewählten Möglichkeit wäre hier, auf die Aufteilung ganz zu verzichten und die Verkehrsinsel als traffic_calming=island an den Way zu taggen.

Sorry, aber damit ich was dazulerne, könntest du mir etwas genauer sagen, was an meiner Arbeit nicht stimmt? Ich bin am 11.2. mehrfach da langgefahren, wobei mir das ziemlich grobe Mapping der Hüttentalstraße und des Zubringers auffiel. Anhand meiner GPXe habe ich das dann überarbeitet.

Solange wir Verkehrsflächen als Linien darstellen, was fürs Routing zwangsläufig so sein muss, müssen wir da immer Kompromisse finden :) siehe dazu auch @kreuzschnabel/diary/43843.

Was heißt „barrier=yes“ an node/5007462131 – also was für ein barrier ist da, und wie sehen da die access=Regelungen aus?

An alle geänderten Ways habe ich maxspeed:note=Baustelle getaggt, nach Abschluss der Maßnahme können sie danach selektiert werden, damit keine Altlasten bleiben.

Hallo Uwenr5, in dieser Änderung wurde das Landuse-MP von Kaisersesch interessant modifiziert: alle Elemente waren nach der Bearbeitung doppelt vorhanden. Irgendwas läuft da schräg, bitte sei vorsichtig!

(Der jetzt fehlende Teil des Waldes liegt/lag um den Hochsimmer zwischen Sankt Johann und Ettringen.)

Hallo uwenr5, hast du hier versucht, relation/363585 zu teilen? Das ist lobenswert, aber dabei scheint was schiefgegangen zu sein, jetzt fehlt die Hälfte. Ähnlich ist es mit relation/1924108. Dürfte ich dich generell bitten, zu überlegen, ob du zur Bearbeitung von Multipolygonen einen anderen Editor als iD (den einfachen Editor im Browser) einsetzen möchtest? iD hat da einfach noch zu viele Macken und löscht immer wieder mal Teile, die hätten stehenbleiben sollen. Und sicher willst du nicht, dass andere hinter deiner Arbeit aufräumen müssen.

Sorry, ist jetzt node/1977041541 – hab ihn mit dem Weg-Ende verheiratet.

Hallo Uwenr5, du hast in diesem CS den Gipfel des Sammetzkopfes (node/747229287) um 150 m nach Südwest verschoben. Das ist nicht korrekt, der Gipfel ist eindeutig beim Gipfelkreuz, ich war heute da :) aus welcher Quelle auch immer du das hattest, ich schieb das mal wieder zurück.

Frage zu way/492184950: Ist das ein Fußweg (schmal) oder ein Wald-Fahrweg? Letzteres wäre highway=track. Das südliche Ende endet momentan noch im Nichts am Waldrand. Hast du ein GPX davon, das du auf den Server hochladen könntest? Ich war heute in dem Wald auf der Suche nach Rettungspunkt 5713-627 und habe entdeckt, dass die gemappten Wege nix mit der Realität zu tun haben :( wenn du da öfters mal langläufst und was aufzeichnen könntest, das wäre hilfreich.