Sicher, dass keine Verwechslung mit way/226914450 vorliegt? "Geometrischer Punkt" sagt mir gar nichts. Ich guck noch mal, wenn ich nächstes Mal oben bin :)

Hallo Sprühwurst, du hast in diesem Edit das komplette Straßenstück way/354931205 um 62,4 Meter nach Nordwesten geschoben. Ich habs repariert. Uffbasse :)

In der genannten Quelle steht: "Im gleichen Jahr (17. Juni 2008) beschloss der Ortsgemeinderat von Maikammer, die Kalmitstraße in Kalmithöhenstraße umzubenennen." Damit ist "Kalmitstraße" old_name oder alt_name, ich habe mich für alt_name entschieden. Die L514 habe ich in diesem CS nicht bearbeitet.

Vielleicht kommst du demnächst nochmal durch :) Sache ist die, dass PKW-Router die Strecke meiden, wegen des 1.5-t-Abschnitts. Der auch irgendwie keinen Sinn macht.

(Hüttenhohl ist das östliche Ende, wo die Kalmithöhenstraße abzweigt)

Hallo Lokai, du hast das maxweight der Totenkopfstraße von 1.5 auf 2.8 angehoben. Aber zwei kurze Abschnitte direkt am Hüttenhohl sind noch auf 1.5, daher wird die Strecke von Routern gemieden. Ich nehme an, die zwei können auch auf 2.8?

That’s what I meant to say. I am aware you didn’t put the number in there, however your edit turned a tag that was wrong in form and undefined in content into a tag that was correct in form, but wrong in content. In other words, your edit turned useless data into false data :-/ that’s what I don’t like about these maproulette activities.

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: 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 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 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 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 node/1051028529 um 60 Meter nach Westen geschoben, wohl aus Versehen. Hab ich wieder zurückgeschoben. Bitte aufpassen :)