Die A57 in Fahrtrichtiung Köln soll zwar demnächst auf die mittlere Behelfsbrücke verlagert werden, aber aktuell wird der Vekehr immer noch über die westliche Behelfsbrücke geführt. Daher einstweilen die Verlagerung rückgängig gemacht.
Die Objekt-IDs der gelöschten mittleren Brücke sind leider im Changeset nicht enthalten, daher keine direkte Wiederherstellung möglich.

Parkplatzflächen werden _entweder_ (im einfachsten Fall) als einzelner Punkt _oder_ als Fläche erfasst. Es macht keinen Sinn innerhalb eines bereits als Fläche erfassten Parkplatzes einen zusätzlichen Punkt mit amenity=parking zu setzen. (Gleiches gilt natürlich auch für andere Einrichtungen).
Ich habe diese daher mit Änderungssatz 32116252 wieder entfernt. (ebenso einen Weg ohne jegliche Attribute oder Verwendung in einer Relation)

I did not complain about any POI tagging. You added building=yes to way/119010957, which I assumed as wrong. Because I have no local knowledge I did not change data.
According to your previous comment "The first way is the area where the cars for sale are parked", it seems I was right.

Mit diesem Änderungssatz wurde für beide Rampen wieder access=no gesetzt, nachdem kurz zuvor access=yes gesetzt wurde. Es blieb allerdings bei motor_vehicle=yes, sodaß Router wie z.B. OSRM weiterhin genau dort lang routen. Ist das so beabsichtigt? Sind die beiden Abschnitte nicht doch gesperrt?
(s.a. www.openstreetmap.org/note/361943)

Unfortunately parking:condition and parking:lane are both explained at one page in the Wiki. This way most explanations and examples refer to the usage of parking:condition together with parking:lane and thus have subkeys left|right|both. (AFAIK there is no subkey all, as you used).
What I did at some parking areas, is to use parking:condition:... without any left/right/both (e.g. way/231970629/history, version #3).
Especially at the parking spaces at Were Street you could indeed also use the parking:lane tags (at the highway) instead of separate areas (something like parking:lane:both=diagonal; most areas looks like diagonal parking, loading zone more like parallel)
Parking discs and no fee are not contradictory. Parking discs (at least in Germany and other European countries) are used to register the arrival time to have the possibility to check how long a car is parking already. There's no fee. See http://en.wikipedia.org/wiki/Disc_parking

You should not change tags, only because they're marked as deprecated to wrong ones. The tag opening_hours does not apply to access restrictions. Time based access restrictions, maxspeed and so on are tagged using conditional restrictions (osm.wiki/Conditional_restrictions).
Furthermore you possibly misinterpreted the date format of the existing data.
Value "06-10" of date_off could also be June 10th (in the style of ISO 8601), not only 6th of October (same with date_on).
Only someone with local knowledge could tell you for sure.
IMHO best way is to set a fixme or try to contact a mapper editing in the area.

I assume way/119010957 is no building.
Why adding shop=car_repair to building (way/107539548), when all other tags are applied to way/119010957?

I assume parking discs have to be used at these parking areas. In this case parking:condition=disc should be added.

If maxstay restriction is limited to the times added by Hlav/malenki as maxstay_hours=*, parking:condition:maxstay and parking:condition:time_interval should be the best way according to the Wiki.

Concerning way/263086521: Really at all days including public holidays the time time interval?

(See also comment at changesets 31286737, 31285334 and 31286954)

I assume parking discs have to be used at these parking areas. In this case parking:condition=disc should be added.

If maxstay restriction is limited to the times added by Agaric as opening_hours:stay=*, parking:condition:maxstay and parking:condition:time_interval should be the best way according to the Wiki.
(See also comment at changesets 31286737, 31284527 and 31286954)

I assume parking discs have to be used at these parking areas. In this case parking:condition=disc should be added.

If maxstay restriction is limited to the times added by Rhubarb as parking_restriction_hours=*, parking:condition:maxstay and parking:condition:time_interval should be the best way according to the Wiki.
According to way/175957681 it could be possible, that the given intervals reflect the time when it's allowed to park there at all.
This can't be determined remotely, only Rhubarb or someone else with local knowledge could help with this.
Concerning "...more used "maxstay:times"" in the changeset description:
Due to taginfo "maxstay:times" is currently used 59 times by 6 editors.
"parking:condition:maxstay" is used 208 times, not counting more than 4000 occurences for parking lanes (left/right/both).
(See also comment at changesets 31286737, 31284527 and 31285334)

You're right a simple tag "maxstay" exists, but IMHO it only reflects a restriction valid all the time. At all objects of this changeset maxstay is (as well as using a parking disc) limited to some time interval.
Indeed parking:condition:hours is not the preferred tagging, according to the Wiki it should be changed to parking:condition:time_interval. But I can't find maxstay:times anywhere in the Wiki.
(See also comment at changesets 31286954, 31284527 and 31285334)

Der "real,-"-Supermarkt existiert bereits mit allen Daten auf way/32861466.
Ich habe daher den mit diesem changeset erstellten zusätzlichen Knoten ohne zusätzliche Daten (node/3365674443) wieder entfernt, zumal dieser auch falsche Daten enthielt (falsche PLZ, abweichende Schreibweise des Namens)

Hausnummer 9 und 11 überlagern sich. Liegen die wirklich in Etagen übereinander? Hausnummer 11 ist in NRW ALK am nächsten Gebäude eingezeichnet (kann aber durchaus dort falsch sein)

Bitte lass doch bitte zukünftig fixme-tags bestehen, wenn Du sie nicht bearbeitest. (hier DHL-Zustellbasis, aber auch in anderem changeset gesehen)
Es ist nicht sinnvoll, fixme-tags einfach nur zu entfernen, ohne irgendetwas davon abzuarbeiten.

Mit changeset/28578827 rückgängig gemacht.

Warum hast Du den Namen "Hammfeld Nord" entfernt (way/260765945)? An der Kreuzung Hammer Landstraße / Schanzenstraße ist das genau so ausgeschildert.
Übrigens: oneway=no wird im allgemeinen nicht erfasst. Und der Poller existierte auch schon (node/3252305339).

Fixme-Tag entfernt, ohne die entsprechenden Informationen hinzuzufügen? Leider ist im Changeset auch kein Kommentar angegeben (das hilft anderen durchaus beim Verständnis, wenn er die Änderung auch wirklich beschreibt)

Warum wurde hier die Hausnummer vom Gebäude entfernt? Weil auch Adressinformationen am Entrance-Node hängen?
Das Gebäude schließt den Entrance-Node mit ein und das Gebäude hat nur eine Hausnummer. Ich persönlich würde, wenn man Duplikate vermeiden will, die Adr-Tags vom Entrance-Node entfernen. Und wenn aus Gründen der Anpassung an das Tagging im Umfeld die Adresse vom Gebäude entfernt werden soll, dann würde ich nicht eine unvollständige Adresse zurücklassen, die in entsprechenden Tools zu Fehlermeldungen führt, sondern _alle_ Addr-Tags entfernen.

Der Weg 93516908, der beide Gebäudeteile darstellen sollte, war leider nicht in sich geschlossen (Anfangs- und Endpunkt unterschiedlich). Das führte unter anderem dazu, daß das Gebäude gar nicht mehr gerendert wurde. Mit changeset/28316206 korrigiert.

Warum wurde der Name auf Stüttgenweg geändert? Der heißt "Stüttger Weg" (wie das auch vorher gesetzt war)