Hi,
wurde bei einem Unfall zerstört und soll wieder aufgebaut werden: https://feedback.karlsruhe.de/reportId=9a58cabf-cc42-416f-aec6-3eac22486755

Hello aleksij,
please stop doing these automated "error correction" edits. Many of your corrections actually change the data for the worse, e.g. you added a lot of wrong public transport related tags and wrong building tags.
Please note that the errors shown by iD editor are only warnings for potential tagging errors and should be only applied after carefully looking at the data. Automatical error corrections should be avoided.
I will completely revert this changeset as it only contains (partly erroneous) automated iD editor changes and does not add any new data.

Hi,
die "platform"s sehen für mich eher nach "stop_position"s aus. Bitte nicht blind dem iD-Validator vertrauen und genauer prüfen, was eigentlich geändert wird.

Hello,
the situation is a bit difficult here: There are construction works on the bridge, so therefore the road has been closed for general traffic until 2022 (access=no). Nevertheless one lane of the road can still be used by small buses and emergency vehicles (e.g. to access hospitals in Speyer), there is a traffic signal controlled alternating oneway on the bridge.
To still allow routing for these vehicles, setting highway=construction would be wrong.
It is also possible to access the Luxhof parking for all traffic ("Zufahrt frei").
On sunday whb has added the traffic signals and barriers and I changed it to highway=unclassified, which comes closer to the current importance in the road network, so it should be mapped ok now.

Hallo whb,
wie kommt man denn jetzt mit dem Fahrrad auf die badische Seite? Wurde die Einbahnstraßenregelung auf der anderen Brückenseite aufgehoben?
Graphhopper routet jetzt über die Rheinhäuser Fähre, diese fährt allerdings nur im Sommer am Wochenende.

Hello Brecht,
there are construction works on the bridge, but it can still be used by buses and emergency vehicles, it is also possible to drive to the Luxhof parking, so highway=construction is not correct here. The access rights were set correctly, so there should be no routing over the bridge.

One more problem: The "two points are very close" autofix seems to be very buggy and has destroyed several geometries (https://github.com/openstreetmap/iD/issues/7379)
I also tested the iD validator and found that it doesn't really show which tags are added. So main problem seems to be the editor :( . One more reason not to use autofix.

I changed the platform to disused now so that it does not show up in validators anymore.
In general I wanted to make you aware, that the validators just show possible mistakes, which should not be corrected automatically but checked before. In the platform case public_transport=no and access=no should have been a sign that setting public_transport=platform is not the correct solution.

Hi,
please be more careful when "fixing" things:
- osm.org/way/414812379 and osm.org/way/274376418 are not street cabinets
- osm.org/way/322556125 is not a public transport platform
- landuse=basin is correct tagging according to the wiki, natural=water is especially strange for underground basins like e.g. osm.org/way/274376413
Validators usually only show possible errors, which should be checked carefully for each case! Especially the iD-Editor is known for a very strange opinion about tagging and validating, see e.g. https://forum.openstreetmap.org/viewtopic.php?id=67975!

Wäre es nicht sinnvoller den vorherigen Namen als Beschreibung einzutragen, anstatt pauschal überall description=Hundekot-Tütenspender zu setzen? Die stichprobenartig von mir geprüften Namen erhalten durchaus noch Informationen bspw. zu zusätzlich vorhandenen Mülleimern und zum Hersteller/Marke ("Dog Station", "belloo" etc.), auch würde ich nicht ausschließen, dass es doch korrekte Verwendungen von name-Tags für Hundekotbeutelspender gibt.
Wo ist die Dokumentation zu diesem mechanischen Edit zu finden? Ein Eintrag im Forum ist meiner Meinung nach nicht ausreichend.

Ich habe keinerlei emotionale Bindung zu diesem Changeset ;). Mein Ziel war nur das Gebäude-Objekt von dem Rechenzentrum-Objekt zu trennen, welche, wie du ja auch ausgeführt hast, eben nicht identisch sind, und nach meiner Änderung nicht zueinander kompatible Tags hatten (location=underground), siehe auch osm.wiki/One_feature,_one_OSM_element#One_feature_per_OSM_element. Falls dies zu von mir nicht bedachten Problemen führt, überlasse ich es gerne den lokalen Mappern eine bessere Lösung zu finden.

Hi, das Changeset ist schon etwas älter, daher weiß ich das nicht mehr so genau. Ich glaube ein Grund war, dass das Gebäude nicht direkt das Rechenzentrum ist, sondern das Rechenzentrum unter dem Gebäude liegt. Damit ist z.B. das location=underground am Rechenzentrum nicht mit dem Gebäude kompatibel, da sich das Gebäude ja nicht nur unterirdisch befindet.

Schön, dass der KVV OSM nutzt, das Tag stört ja auch nicht. Ich würde aber das information=office wieder zusätzlich ergänzen, damit auch andere Karten etwas damit anfangen können.
Kann man die KVV-Karte eigentlich schon irgendwo öffentlich finden oder ist die nur für den internen Gebrauch?

Hallo Funki,
was soll denn der Key `information:kvv` bedeuten? Und ist diese "Information" im Betriebshof öffentlich oder nur VBK-intern zugänglich?

Hallo chrischtili,
irgendwie hast du Anicura hier 3 mal eingetragen: 1x am Gebäude, 1x als POI und dann noch 1x mit Maps.Me
Ich habe die drei POI zusammengeführt, dabei ist mir aufgefallen: Auf der Homepage wird die Neue Bahnhofstraße 14 als Adresse angegeben, dort ist auch in OSM eine Tierarztpraxis eingetragen? Handelt es sich um die gleiche Praxis mit zwei Standorten? Oder ist ein Umzug in Am Eisweiher geplant, bzw. hat schon stattgefunden? In diesem Fall müsste eine der Praxen als geschlossen, bzw. im Bau gekennzeichnet werden.
Viele Grüße
mapper999

Thanks for the comment. I added the tags now.

Hallo,
ich habe in diesem Changeset, die von mir ursprünglich verbrochenen und von dir bemängelten falschen Vz 278 mittels Mapillary korrigiert. Dabei habe ich teilweise die Position korrigiert und dabei auch die Position der separat gemappten Verkehrszeichen angepasst.
Beide Varianten haben ihre Vor- und Nachteile (einzelne Notes bilden zwar die genaue Position ab, lassen sich aber nicht maschinell dem Weg zuordnen für den sie gelten und sind anfällig gegenüber versehentlichen Verschiebungen, insbesondere solange sie in Editoren nicht angezeigt werden.) und solange beide Varianten erlaubt sind, sehe ich kein Problem darin, diese zu behalten. Ich akzeptiere beide Varianten, wobei ich persönlich das Eintragen als Punkt im Weg bevorzuge, trotzdem zerstöre ich nicht die Arbeit anderer, die die andere Variante bevorzugen. In der Praxis dürfte es egal sein, da Verkehrszeichen soweit ich weiß von keinem Programm ausgewertet werden und in den meisten Fällen klar sein sollte, welche Variante verwendet wurde. maxspeed=100 ist wohl beliebt, da es in JOSM angezeigt wird und so einfach gewartet werden kann, und laut Wiki ist es auch eine valide Variante, die natürlich durch eine detailliertere Version ersetzt werden kann.

Hallo,
gibt es einen Konsens, dass Verkehrszeichen auf dem Weg falsch sind? Laut Wiki ist beides möglich (beide Versionen haben Vor- und Nachteile), insofern sollte das meiner Meinung nach nicht mechanisch geändert werden.

Hi,
this was not really a correction: traffic sign 1049-11 is directly related to traffic sign 276 and should therefore be separated by a comma, not a semi-colon.

Hallo mani100,
danke für den Hinweis, ich habe mir das "Schutzgebiet" nochmals vor Ort angeschaut. Dort steht ein Schild "Artenschutzmaßnahme - Eigentum der DB Netz AG", es ist aber nicht so ganz klar, ob damit tatsächlich das eingezäunte Grundstück oder die umliegende Böschung gemeint ist. Auf dem Grundstück ist aktuell ein Anhänger geparkt.
Ich habe die protected_area wieder entfernt, da es sich wohl offensichtlich um kein offizielles Naturschutzgebiet handelt.
Viele Grüße, mapper999