Hallo TomRat, du hast hier einige Abbiegebeschränkungen gesetzt, die sich ohnehin schon aus Einbahnregelungen ergeben (du hast also das Abbiegen gegen die Einbahnrichtung nochmal verboten). Das ist weder nötig noch erwünscht, siehe osm.wiki/DE:Relation:restriction unter „wichtig zu beachten“ Punkt 2 :)

Hallo, du hast osm.org/way/25394566 (und den östlich angrenzenden) hier per tunnel=yes in die Erde verlegt, war das Absicht?

Hallo T2018, der von dir eingezeichnete osm.org/way/1175963831 ist baulich weder vom Kreisel noch von der Straße getrennt und damit nur eine Fahrspur, die mit lanes=2 schon erfasst ist. Nur baulich Getrenntes wird als separater Way eingezeichnet.
Siehe osm.wiki/DE:Key:lanes

Hallo, ich weiß, es ist ewig her, aber welchen Grund gab es für osm.org/relation/3400573 (U-Turn von der Frankfurter über die B 44 zurück in die Frankfurter)? Das Wenden an Kreuzungen und Einmündungen ist generell erlaubt (als zweimaliges Linksabbiegen), und ein Verkehrszeichen, das das hier verbietet, sehe ich auf Mapillary nicht. Ich nehm das mal raus, ja?

Die gemappte Tafel etwas weiter südlich gehört zu dem Objekt, das ich oben verlinkt habe.

Sicher, dass keine Verwechslung mit osm.org/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 osm.org/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: 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