Hi Necessarycoot72, an elevation of 291 m seems hardly plausible. The hills here around the B 260 road are all of similar elevation, so it should rather be 491 m. Maybe "height" referred to something else, then it was not the best idea to change the tagging without local knowledge :)

Wobei die aktuellen Luftbilder in Hessen und RLP erfreulich genau sind. Aber hier geht es ja gar nicht um Lagegenauigkeit, sondern um die Auflösung, mit der die Geometrie erfasst wird, unabhängig davon, ob sie vielleicht tatsächlich als Ganzes drei Meter westlich liegt. Und dann finde ich es schon etwas anmaßend, ohne Rücksprache mit irgendjemandem zu entscheiden "hier wurde unnötig gut gearbeitet, das verschlechtere ich gleich mal wieder". Das ist in meinen Augen etwa so, als würde ein einzelner User auf Wikimedia Commons entscheiden, dass kein digitales Bild größer als 800x600 Pixel sein muss, und alle höher aufgelösten Bilder runterskaliert nochmal hochladen. Frag doch zumindest den Mapper, der das so detailliert gemappt hat, was er von einer Vereinfachung hält, bevor du sowas einfach machst. Datenqualität immer heben, nie senken. Nodes in einem Way lösche ich nur dann, wenn zb eine perfekt gerade Straße im Zickzack gemappt wurde. Und das ist dann auch eindeutig eine Verbesserung der Präzision.

Danke für deine Antwort. In der Datenbank sparst du durch solche Löschungen überhaupt keinen Platz, weil alle Vorversionen gespeichert bleiben. Du verbrauchst nur zusätzlich welchen für deine neue Version. Navi-Anbietern stellt sich das beschriebene Problem nicht, denn die führen nach ihrem Export der OSM-Daten selbst schon eine Filterung durch, vereinfachen also die Daten nach ihrem Geschmack. Und so solltest du es auch machen: Erst die Daten, die du brauchst, aus der Datenbank exportieren, sie dann nach deinem Geschmack vereinfachen und dann deine Navi-Daten draus bauen, sie aber in der Datenbank für alle anderen Anwender in der bestmöglichen Qualität zu lassen. Wenn du aber direkt in der Datenbank präzise Daten durch vergröberte ersetzt, dann entscheidest du de facto für sämtliche Millionen OSM-Nutzer weltweit (zu welchem Zweck auch immer sie OSM nutzen), dass dein persönlicher Geschmack an Präzision für sie alle auszureichen hat und sie keine besseren Daten bekommen als du persönlich sie haben willst (denn ohne mühsames Versionengeblätter bekommt man bei einem Export ja immer die aktuellen Daten geliefert). Und zweitens definierst du damit die Arbeit aller Mapper, die präziser arbeiten als du, für nutzlos oder sogar schädlich, und schmeißt sie weg, ohne mit diesen Kollegen auch nur Rücksprache zu halten. Verstehst du jetzt, wo das Problem liegt? "Auf den Schlips treten" ist nicht ganz die treffende Bezeichnung dafür.

Hallo LightSpirit, ich habe die Kreiselanschlüsse mal überarbeitet. Erstens gibt es keinen Grund dafür, die Äste einer aufgeteilten durchgehenden Bundesstraße in primary_links umzutaggen – das sind nach wie vor primarys. links sind Zubringer oder kurze Verbindungsstücke zwischen zwei Straßen, z.B. hier: osm.org/way/28876442 Zweitens weiß ich nicht, was diese Doppelknicke an den Aufteilungen sollen, die überhaupt nicht da sind. Die Fahrbahn geht einfach in einer weiten Kurve weiter und kann doch auch so gemappt werden. Drittens beginnt die bauliche Trennung des Anschlusses nach Nastätten schon kurz hinter der Brücke, die hab ich entsprechend rausgezogen. Die war auch mal da :)

Auch den Kreisel in Simmertal osm.org/way/34394360 hast du in diesem Edit von 25 auf 12 Punkte reduziert. Was soll das, wo liegt die Verbesserung? Nodes sind nicht knapp, wir müssen nicht sparen. Und auch wenn du persönlich es schön findest, ein rundes Objekt in der Datenbank eckig abzubilden, gibt dir das doch nicht das Recht, geleistete Arbeit von anderen einfach wegzuwerfen. Nehmen und verbessern gern, aber nichts verschlechtern.

Hallo 9ix, jeder mappt bei OSM in der Präzision, die er oder sie angemessen findet. Aber jeder Edit sollte eine Verbesserung sein. Du selbst kannst Straßenkurven gern mit wenigen Nodes relativ eckig mappen, nichts dagegen. Aber wenn sich jemand anders schon die Mühe gegeben hat, eine langgezogene Straßenkurve wie osm.org/way/107327581 mit 12 Nodes in einer sauberen Rundung zu mappen, würdest du das dann bitte so lassen und nicht die Hälfte der Punkte in deinem nächsten Edit grundlos wieder rauswerfen? Danke.

Hallo, ist dein etwas grobes Mapping der B 62 in Angenrod noch aktuell oder war das ein Baustellen-Provisorium?

Hallo AymOSM, bitte nur wirkliche Namen ins name-Feld eintragen, nicht irgendwelche Beschriftungen. Der Weg heißt garantiert nicht "Pee Klammer auf Markierung Klammer zu". Markierte Routen werden in OSM immer als Relationen erfasst, das hat viele Vorteile. Für Wanderrouten z.B. osm.wiki/DE:Tag:route%3Dhiking

Kannst du gern dranschreiben. Notwendig finde ich es nicht, da ein Router auch so wissen sollte, dass für Nicht-Autobahnen etc. in DE generell 100 gilt, wenn nichts dransteht.

Hallo, ins name-Tag eines Weges gehört nur der Name des Weges selbst. Eine Wanderroute, die den Weg benutzt, wird als Relation erfasst. Die Extratour Hochrhöntour z.B. als osm.org/relation/1026672. Diese Relationen können in Karten und Navi-Apps hervorgehoben dargestellt werden. Es gibt keine Notwendigkeit dafür, den Routennamen zusätzlich an die einzelnen Wege zu setzen.

Hallo Buddor, du musst nicht per Abbiegebeschränkung das Abbiegen gegen eine Einbahnstraße verbieten. Siehe osm.wiki/DE:Relation:restriction#Wichtig_zu_beachten Punkt 2.

I might be wrong of course, I am not a local resident. Firstly, Wikipedia is never a source for OSM – they might even have copied their data from OSM, causing circular reasoning. Looking at the 1:25k OS map, there’s words like "Cairns", which are obviously not place names but mere descriptions, printed in the same type as words like "Combe Head", which obviously are. So, we have to apply some common sense. The words "Looking steads" are, in the map, printed in a spot which, in my eyes, is not related to the peak (too far off it) but to the deep gully between the peak in question and Glaramara itself.

Hallo, in dieser Bearbeitung wurde osm.org/node/1051028529 um 60 Meter nach Westen geschoben, wohl aus Versehen. Hab ich wieder zurückgeschoben. Bitte aufpassen :)

Hi ramyazka, the two forks of L 3276 are not oneway streets, that wouldn’t make sense either (impossible angles for turning left). Where did you get that information?

Wenn da ein Feld-Fahrweg ist, highway=track, wenn da ein Pfad ist, nicht für Traktoren gedacht, dann highway=path.

Hi Tugman, in this edit you turned the entire path into a bridge. This obviously not the case so I removed the bridge tagging again and put some short bridges in according to the aerial image.

Hi Maroonvelvet, du hast hier einen ganzen Abschnitt der Aula auf waterway=weir gesetzt. Ich hab das mal wieder auf river korrigiert :)

Und dort überschneiden sich die 15-min- und 5-min-Isochronen, so dass es Punkte gibt, die zwar in 5 min, aber nicht in 15 min erreichbar sind, was logisch nicht geht. Das müsste man mit dem Maintainer der Auswertesoftware mal besprechen. Möglicherweise gelten die Isochronen nur für Ortschaften und schließen nicht notwendigerweise die Anfahrwege ein. Immerhin ist fast ganz Steinfischbach innerhalb der 5-min-Isochrone, was AFAIS nur über die K 714 machbar ist, so dass sie schon berücksichtigt werden muss. – Eine "Verfälschung" war das jetzt nicht, ich mach dir auch keinen Vorwurf, aber das Problem wurde irgendwie an der falschen Stelle gelöst.

Dann gilt der Grundsatz: Wir mappen nicht für den Router :) wenn der einen Waldweg bevorzugt, dann hat er einen Fehler, und dann sollte der Fehler im Router behoben werden, statt ihn durch fehlerhaftes Tagging der OSM-Daten zu kompensieren.
Welcher Waldweg ist es denn genau? Den sollte man sich dann auch mal anschauen.

Hallo Stubenkater, was genau soll aus osm.org/way/110325849 und Fortsetzung werden? path=track ist kein etabliertes Tagging.