Yet there's only a decision to rename the place "Marktplatz" to "Helmut-Schmidt-Platz", but the renaming itself is planned to take place at April 26th, 2017, not now!
Therefor I've reverted this change.

Die Durchfahrtbeschränkung für motorisierte Fahrzeuge gilt zwischen Stürzelberg und Zions (Oberstraße/Deichstraße) nur am Wochenende und Feiertags und das auch noch zeitlich befristet. Genau so ist das auch getaggt.
Ich vermute, daß Du das conditional-Tag nicht kennst. Das ist aber kein Grund, wieder einmal Daten zu verfälschen, oder?
Auf welcher Quelle basiert die Erfassung des neuen Wirtschaftswegs in Delhoven?
Worauf die anderen Änderungen?

Habe die ursprünglichen Klassifizierungen aufgrund des zweiten Vetos wieder hergestellt.

Die Bahnstraße bzw. deren Verlängerung bis zur Edisonstraße stellt die Hauptverbindung zwischen Stürzelberg und Delrath dar und ist auch so ausgeschildert. Ich sehe absolut keinen Grund diese Verbindung von tertiary herabzustufen,schon gar nicht auf residential (Wohnhäuser sind da im Mischgebiet eher die Ausnahme).

Ich weiß nicht, ob es wirklich sinnvoll ist, die Edisonstraße zwischen Bahnstraße und B9 während der Bauarbeiten zur tertiary heraufzustufen, zumal die B9 im Bereich in Richtung Neuss weiterhin befahrbar ist und die Ausschilderung Richtung Delrath weiterhin über die Bahnstraße führt (an der B0 ist nur das Gewerbegebiet ausgeschildert)

BTW Auf Basis der Ausschilderung ist der Zinkhüttenweg m.E. auch keine tertiary (auch von Neuss aus kommend wird Delrath erst an der Bahnstraße ausgeschildert, am Zinkhüttenweg ist lediglich das Gewerbegebiet ausgeschildert)

Obviously you misused at least the tag amenity=embassy for POI "MS Motorservice International GmbH" (same error in changesets 39279541, 39279654, 39279258)
The telephone number you've set belongs to a different company and there's no location "Dormagen" listed at the website you've set
Perhaps wrong location due to an outdated source? (BTW: Which source did you use?)

What about setting alt_name to "Am Rheinfelder Hof" in the meanwhile? This way Nominatim will bring already a result for "Am Rheinfelder Hof", but map shows current state.
On the other Hand buildings still have the current, valid adress and the street is very small. Thus it's a minor problem to me.

Changed Name "Am Rheinfelder Hof" is not yet valid. IMHO renaming of way happened a little bit to early.
When new name becomes valid in two weeks, I assume housenumbers of the surrounding buildings will change also. (Added note/548086)

Name "St.Hubertus-Weg" will start to be valid in more than a year (19,05.2017)! Therefor changed name tag to name:proposed.

Your changeset comment say, roundabout will be build completely approx. mid of April. Nevertheless you've changed all ways, which where set to construction, as they were already usable for public access. You did the same at this area already twice (including breaking some relations) and some more times at other areas (e.g. Reuschenberger Straße).
At openstreetmap only the current, reviewable, state has to be mapped (except conditional rules, which may cover situations in the future), not something, that may happen some time.

Anyway, you missed to revert your "Umleitung" change and my access changes at the track between "Kohnacker" and "Am Wittgeshof". You removed the access=no from the track leading towards the roundabout, but you did not remove the barrier, you've created at your first changeset concerning the roundabout.

You missed the temporary oneway of "Neusser Straße" between "Bismarckstraße" and "Salvatorstraße".

Although I've set a note, you missed to change way direction at the already used part of the roundabout (roundabout implements oneway=yes automatically, but this part of roundabout is currently used clockwise, not anti-clockwise as usual).

You've changed some highway=path, which currently do not have any sign (footway nor mixed foot-/cycleway), but are expected to be mixed ways, as they are connected to other mixed ways and where mixed ways before construction works. It's not the first time, your mapping of ways does not meet the situation (free of doubt like footways, cycleways or also very often living streets).

Last thing I need to point out: You've moved at least a part of "Neusser Straße" (the one from Dormagen direction roundabout) towards the fuel station. Based on which source? You could not have used Bing (like you do usually), as it does not show this new street. I do not know any source, free to use for openstreetmap, which could show such newly build ways.
I've tracked this ways by walking in the middle of the way a slow speed with a Garmin etrex.

Your changeset consist of that much errors, I don't feel like checking each single change you did. Therefore I will revert the whole changeset.

In the past years I've corrected a lot of things you changed, which are used different without any doubt and described the reason in the changeset (partly even in English and German language). In some cases you reverted these corrections again and again (most commonly streets with paving stones, which you declared to living street only based to the surface). I wrote personal mails to you, but you did not response nor changed your tagging behaviour in the future but repeated the same type of error again and again.

If you change one tag, you should have a look at the other tags as well, as there may be some corresponding tags. A tag "tracktype" makes no sense, if highway is changed from track to service or some other kind of road. If there's a note set to explain a temporary change and this temporary change is reverted, leaving the note could confuse users.

I really don't complain about single errors. Errors can happen, to everyone. I onyl complain about systematic, repeated errors, which have a major impact to the use of openstreetmap.
----------------------------------------
German summary:
Dein Änderungssatz trägt den Kommentar "Kreisverkehr fertig ca. Mitte April". Dennoch hast Du bereits jetzt alle noch nciht fertiggestellten/freigegebenen Wege als fertig markiert. Das entspricht nicht den Vorgaben von Openstreetmap, da stets ein nachvollziehbarer Zustand erfasst werden soll.
Zudem ist der ganze Änderungssatz inkonsistent, da Teile der Daten noch dem Baustellenzustand entsprechen, andere dem erwarteten Fertigstellungzustand (Einbahnstraßen, Richtung des Kreisverkehrs, Umleitungsstrecke über den Feldweg (highway=service ist das m.E. nicht, aber das mag Ansichtssache sein), Geschwindigkeitsbegrenzungen, Barriere auf dem Feldweg).
Du hast (nicht zum ersten Mal) Wege zu dedizierten Fußwegen gemacht, obwohl es keine entsprechende Beschilderung oder andere Anhaltspunkte dafür gibt (Wege sind an andere gemischte Rad-/Fußwege angebunden und waren auch vor den Bauarbeiten gemischte Rad-/Fußwege)

Wenn man einen Wert ändert, sollte man sich auch andere gesetzte Werte ansehen, die ggf. zu diesem in Bezug stehen (tracktype macht bei einer Änderung highway=track nach service irgendwie keinen Sinn mehr; ein Hinweis auf den Grund für eine temporäre Änderung wie die Einbahnstraße der Neusser Straße, verwirrt, wenn sie nach Wegnahme der temporären Änderung stehen gelassen wird)

Mir geht es nicht um einzelne Fehler, die können jedem passieren. Aber systematische Fehler, die eindeutig gegen abgestimmte, tausendfach verwendete und im Wiki seit langem dokumentierte Regeln verstoßen, und trotz mehrmaliger Hinweise konsequent wiederholt werden, sind dem Projekt wenig zuträglich, binden Ressourcen, die man sinnvoller als für immer wiederkehrende Korrekturen verwenden könnte und erzeugen zu guter Letzt Frust.
Wie bisher auch, erkläre ich nach Möglichkeit gerne (ergänzend zum Wiki) gewisse Erfassungsmethoden. Bestimmt gibt es auch andere Mapper, die Dich gerne unterstützen, per Mail oder im Forum.

Dieser Änderungssatz enthielt so viele Fehler, daß ich wirklich keine Lust hatte, zu suchen ob da noch etwas außerhalb des Baustellenbereichs geändert wurde, was korrekt ist. Bitte erfasse das ggf. neu.

Gleichzeitig bitte ich Dich eindringlich, nicht erneut diesen Bereich fehlerhaft zu bearbeiten. Danke.

Außerdem möchte ich Dir nochmals einen Wechsel des Editors nahelegen. Potlatch hat insbesondere im Zusammenhang mit Relationen bekannte Schwächen (ID soll da deutlich besser sein, wenn Du nicht JOSM nutzen willst). Gerade Relationen sind aber mitunter nur schwer und aufwendig zu reparieren. Da bleibt manchmal (im angemessenen Zeitrahmen) auch nur ein Umkehren des Änderungssatzes.

Aufgrund der im (deutschen) Wiki vorhandenen Liste "Deutsche Postdienstleister" (s.o.) war ich schon davon ausgegangen, daß es für die Briefkästen in Deutschland eine einheitliche Vorgabe gibt.
Aber Du hast Recht, daß die deutsche Seite zum Operator-Tag im allgemeinen zur Gesellschaftsform keine verbindliche Aussage trifft. Die gleiche Seite sagt aber letztendlich auch aus, daß bei Briefkästen der Deutschen Post (AG) der operator nicht erfasst wird: "Wenn bei weitem die meisten Objekte einer Art von einem bestimmten Unternehmen betrieben wird (z. B. wie im obigen Beispiel die Postkästen durch die Deutsche Post) und nur relativ wenige durch alternative Anbieter, sollten nur die Ausnahmen getaggt werden."
Auf den englischen Wiki-Seiten finden sich diese Punkte alle nicht.
Also doch, jeder wie er mag?

Im Original ausgeschriebene Texte kürze auch ich üblicherweise nicht ab. Wenn aber ein Anbieter selber Abkürzungen in (seinen) offiziellen Bezeichnungen verwendet, sehe ich persönlich keinen Grund, diese wieder auszuschreiben. Ist aber ganz klar meine persönliche Meinung und würde ich selber auch nicht bei bestehenden Werten ändern.
Aber müsstest Du nach diesem Grundsatz nicht als Operator dann auch "Deutsche Post Aktiengesellschaft" setzen? ;-)
(stelle ich mir etwas sperrig vor bei Gesellschaftsformen wie GmbH oder gar KGaA)

Gem. osm.wiki/Deutsche_Postdienstleister soll für Briefkästen der "Deutsche Post AG" als Operator "Deutsche Post" (ohne Gesellschaftsform) gesetzt werden. Ich habe das daher für den Briefkasten aus diesem Changeset wieder zurück geändert.
Ob man beim ref-tag die Abkürzung "Str." ausschreiben sollte, wenn der Betreiber selber die Abkürzung verwendet, ist wahrscheinlich Ansichtssache.

Ich stimme zu, daß ref_name aufgrund der Defnition im Wiki bei einer Trafostation nicht passt. Wir sind uns doch einig, daß auch dieser "Text" eine Form von Referenz darstellt, und wir lediglich ggf. das Problem haben, zwei Werte vernünftig unterzubringen, oder?
Ich würde daher nicht einen anderen/neuen Tag verwenden, sondern einen Subkey: "ref:name"
Verwendet wird dies bereits (http://taginfo.openstreetmap.org/keys/ref%3Aname), oftmals aber anscheinend (fälschlich) im Umfeld public_ttransport. Ich habe bei Stichproben über overpass in Deutschland auch ähnliche Fälle gefunden: node/321249766 und node/2612725413
BTW: Auf der Trafostation sreht wirklich Rostocker Str., Du hast Dir das also richtig aufgeschrieben. Könnte man vielleicht mal die evd oder Westnetz zu anschreiben
Und zu ALKIS/DOP: In der Tat kann man sich nicht darauf verlassen, daß in ALKIS alle Gebäude vorhanden sind oder alle in ALKIS eingezeichneten Gebäude auch existieren. Da das Liegenschaftskataster durch Einmessung entsteht, existieren kleine genehmigungsfreie Anbauten oder auch Schwarzbauten dort nicht. Oder Gebäude wurden geplant und genehmigt, aber nicht errichtet. Von daher wird es immer ein Zusammenspiel aus ALKIS, DOP und Survey sein, um optimale Ergebnisse zu erreichen.
Ich habe sogar schon erlebt, daß vor Ort angebrachte Hausnummern und die in ALKIS nicht zusammen passten (einmal im Niederfeld und einmal in Zons-Altstadt), bestimmt gibt es noch mehr solche Fehler.

Bei einigen der geänderten Objekte ist es aufgrund des Namens oder einer angegebenen Webseite zu erkennen, daß diese wohl ausschließlich Bio-Produkte verkaufen und organic=only somit berechtigt ist.
Bei anderen ist das (ohne Ortskenntnis) m.E. nicht zu erkennen. Ein Setzen von organic=only nur aufgrund eines vorher vorhandenen shop=organic erscheint mir etwas gewagt, da u.U. seinerzeit vom initialen Mapper ggf. nur gemeint war, daß "auch" oder vielleicht noch "überwiegend" Bio-Produkte verkauft werden.
Nicht eindeutig sind hier m.E. "Zwiebel" und "Wendelinushof"
Ich würde da eher nur organic=yes setzen und ein fixme.

Bei einigen der geänderten Objekte ist es aufgrund des Namens oder einer angegebenen Webseite zu erkennen, daß diese wohl ausschließlich Bio-Produkte verkaufen und organic=only somit berechtigt ist.
Bei anderen ist das (ohne Ortskenntnis) m.E. nicht zu erkennen. Ein Setzen von organic=only nur aufgrund eines vorher vorhandenen shop=organic erscheint mir etwas gewagt, da u.U. seinerzeit vom initialen Mapper ggf. nur gemeint war, daß "auch" oder vielleicht noch "überwiegend" Bio-Produkte verkauft werden.
Nicht eindeutig sind hier m.E. 844928101 und "Hofladen Peter Anhäuser"
Ich würde da eher nur organic=yes setzen und ein fixme.

Bei einigen der geänderten Objekte ist es aufgrund des Namens oder einer angegebenen Webseite zu erkennen, daß diese wohl ausschließlich Bio-Produkte verkaufen und organic=only somit berechtigt ist.
Bei anderen ist das (ohne Ortskenntnis) m.E. nicht zu erkennen. Ein Setzen von organic=only nur aufgrund eines vorher vorhandenen shop=organic erscheint mir etwas gewagt, da u.U. seinerzeit vom initialen Mapper ggf. nur gemeint war, daß "auch" oder vielleicht noch "überwiegend" Bio-Produkte verkauft werden.
Nicht eindeutig sind hier m.E. "Bauerngut Schiefelbusch", "La Luce" und "Burgwinkels Obst & Gemüse"
Ich würde da eher nur organic=yes setzen und ein fixme.

Mit diesem Änderungssatz wurde u.a. die Lage einiger Gebäude verändert, deren Grenzen zuvor auf Basis von NRW ALKIS (seinerzeit noch mit ALK bezeichnet) eingezeichnet wurden.
Neben kleinen Verschiebungen kommt es hauptsächlich durch Dachüberstände so zu deutlichen Unterschieden und damit auch zum typischen Luftbildproblem.
Ich bin weit entfernt davon zu sagen, daß die Daten von ALKIS 100%ig stimmen (dafür habe ich schon zu viele Abweichungen zur Realität entdeckt, falsche Hausnummern inklusive), aber i.d.R. scheint mir die Lagegenauigkeit von zweifelsfrei real existenten Objekten doch besser zu sein als bei Luftbildern, DOP40 eingeschlossen. Vor allem aber beziehen sich die Daten auf die Grundmauern, die m.W. auch in OSM die Referenz für eine Standard-Gebäudeausdehnung sind (ein komplettes 3D-Mapping kam bei diesen Gebäuden ja nicht zum Einsatz).
Ich greife auch auf DOP40 zurück, wenn die Daten in ALKIS sichtbar einen älteren Stand haben, definitiv nicht der Realität entsprechen oder das betreffende Objekt schlichtweg nicht im Liegenschaftskataster geführt wird.
In diesem Änderungssatz scheint es mir bei den vorher schon bestandenen Gebäuden zumindest teilweise jedoch unvorteilhaft zu sein, sich auf diese Daten zu beziehen.
Kurz noch zur Trafostation an der Matthias-Giesen-Straße: Ich glaube, hier ist die falsche Straße in den Namen gelangt. Ich bin auch nicht wirklich glücklich damit, solche Adress-Bezeichnungen in das Name-Tag aufzunehmen. Das würde ich doch eher für spechendere Namen sehen und Adress-Bezeichnungen eher in ein Ref-Tag setzen (analog zu Briefkästen).
Gleichwohl muß ich zugeben, daß das der Wiki.Artikel zu substations durchaus die Verwendung solcher Adress-Bezeichnungen im Name-Tag zumindest nicht ausschließt.

Gibt es eine Quelle dafür, daß der Mennweg dauerhaft von der B9 bzw. der Verlängerung der Industriestraße abgetrennt bleibt ? (auch für Radfahrer?)
Leider weist dieser Änderungssatz weder eine Quelle noch irgendeinen anderen Kommentar auf. Das würde die Änderung für andere nachvollziehbar machen (s.a. osm.wiki/DE:Good_changeset_comments)

Ein paar kleine Anmerkungen zu way/356919250:
Wenn ein access=private gesetzt ist, gilt dies automatisch für alle spezifischen Fortbewegungsarten, sofern für diese nichts anderes gesetzt ist.
bicycle und motor_vehicle sind von daher entbehrlich (aber nicht falsch)
Für foot würde ich eher permissive setzen. Ein strictes horse=no bedeutet, daß auch der Eigentümer diesen Weg nicht mit einem Pferd nutzen dürfte. Aufgrund des access=private würde ich das entfallen lassen.

Warum wurde mit diesem Änderungssatz der Punkt mit der früheren Adresse des Gebäudes entfernt? (Die Beschreibung des Änderungssatzes bezieht sich offenbar auf etwas ganz anderes)
Das Gebäude hatte früher die Adresse Delrather Straße 2 und der note-tag wies auch darauf hin, daß es sich um die frühere Adresse handelte. Da es durchaus möglich ist, daß jemand noch nach der alten Adresse sucht, macht diese als zusätzliches Info durchaus Sinn.

Die Attribute von Weg 271599466 wurden schon einmal aus gutem Grund entfernt: Das Gebäude hat einen Innenhof und wird daher mit einem Multipolygon dargestellt. Daher werden die Attribute, die das Gebäude betreffen, auch an die relation/3625675 gehangen und nicht an eine äußere (oder innere) Begrenzung,
Und auch hier macht es keinen Sinn, einen Knoten in ein Flächenobjekt zu legen, welches nochmals Attribute enthält, die bereits am umgebenden Objekt (hier die Relation) gesetzt sind.
Beides bereits korrigiert.

Hab nun auch die mittlere Brücke "gefunden". War nicht gelöscht, sondern wurde auf die gleiche Position wie der neue Bypass verschoben. Ebenfalls rückgängig gemacht.