"Wir mappen nicht die Vergangenheit!"
Wir mappen nicht die RÜCKSTANDSLOSE Vergangenheit.

i.d.R. sind Geschäftsräume sind immer noch als Geschäftsräume vorhanden.
Der einzige Grund, warum man "disused:shop" o.ä. löscht ist, wenn man von Außen nicht erkennen kann, falls da jemals ein Laden war (z.B. die Fenster wurden durch Wände ersetzt, die Namenschilder wurden abmontiert).
Dies spontan zu beurteilen widerspricht das OTG-Prinzip von OSM, insbesondere, weil es auch Menschen gibt, die leerstehende Geschäftsflächen eintragen.

Mit der Logik komme ich immer noch nicht hinterher, zudem "bridge:name" auch nur deswegen zustande kam, weil es vor "man_made=bridge" definiert worden ist.
Außerdem bin ich der Meinung, dass man Elemente auf Brücken auch so auswerten kann, in dem man Prüft, welche Elemente im Polygon liegen und auf welcher Ebene sie liegen (ähnliche Regeln wie Gebäudeteile, zuder man i.d.R. keine Relationen benötigt).

Und bevor wir nur im Kreise reden, habe ich hierzu noch einen Thread geöffnet, damit auch andere von der Situation wissen:
https://community.openstreetmap.org/t/verschmelzung-von-highway-und-man-made-bridge/133095

Mein Problem ist, ist, dass es inkonsistent ist, da es bei meisten anderen Brücken eben nicht gemacht wird und ich mit der Logik auch deswegen nicht hinterherkomme.

Der einzige Grund, warum du dies als natürlich siehst, liegt darin dass
a) diese als Fußgängerstraße gekennzeichnet ist und "highway=pedestrian" als Fläche dementsprechend gültig ist
b) beim Eisernen Steg nur eine Wegfläche gibt (keine Bordsteine o.ä.)
c) der Weg sonst von den Eigenschaften (Oberfläche, Zugriffe, Markierungen) durchgängig ist*
d) Brücke und Weg den gleichen Namen hat

Aber gerade dies zeigt auch, warum dies One Feature, One ASM Element verstößt, da bei jeder anderen Situation der Weg von der Brücke getrennt werden MUSS, also was ist die versteckte Sonderregel, warum du man_made=bridge mit highway=pedestrian verbindest?

Diese Änderung sehe ich kritisch aus zweierlei Gründen: Erstens wird der Eiserne Steg als Brücke und Eiserne Steg als Weg miteinander vermischt, was gegen die OSM Regeln ist[1] (wäre vor allem ein Problem, wenn der Weg auf dem Eisernen Steg einen eigenen Namen hätte), zweitens (und das ist zugegebenermaßen eher subjektiv) ist der Weg an sich linear und ist natürlicher als eine Linie als eine Fläche darzustellen, insbesondere, weil viele Router immer noch nicht über Fläche routen können (wobei die Fläche an sich immer noch mit "area:highway" eingetragen werden kann, auch wenn es auf Carto nicht erscheint).

[1]osm.wiki/One_feature,_one_OSM_element

Übrigens noch Hesse DOP20 als eine weitere Quelle, zur Anpassung der die Gebäudeformen, um die Verzerrungen der Mainzer Luftbilder zu vermindern.

Es kann sein, dass diese Straße nun doch nicht so gut ausgebaut ist, wie ich es dachte, aber es war eine Weile her, seitdem ich es geändert habe (Grenzfälle eben).

Mein Hauptproblem ist aber, dass die Klassifizierung der Durchgangsstraßen (d.h. highway=primary, secondary, tertiary and manchmal auch unclassified) eigentlich durchgängig sein sollen und deswegen nicht mitten auf dem Weg aufhören sollte, nur weil ein Abschnitt schlechter (bzw. in diesem Fall besser) ausgebaut ist als der Rest, was durch deine Änderung deswegen passierte.

Wenn der südliche Teil der Limburger Straße jedenfalls highway=secondary ist, sollte diese auch bis zur Aarstraße sein oder umgekehrt, dass die Limburger Straße zwischen B 417 und B 275 highway=tertiary ist (was ich am Ende gemacht habe).

Also: "highway=path" ist selber kontrovers, die Logik dahinter teilweise widersprechend und/oder realitätsfremd und m.M.n. hätte es im jetzigen Zustand nie akzeptiert werden sollen (selbst Carto rendert diese als Radwege). Auch wenn das im Wiki so steht, es ist nicht ein absolutes Handbuch sondern kennzeichnet "nur" die allgemeine Meinung der Community (und es gibt auch weitere Fälle, wo das erwartete Tagging sich von der Beschilderung abweicht).

Vielmehr aber liegt es auch darin, dass ich Drususwall selber wie eine Art Straße sehe und deswegen als "highway=cycleway" taggte (ditto für den abgeschnittenen Teil der Wilhelm-Quetsch-Straße, welcher sogar eine ehemalige Straße war, könnte übrigens genau so sehr ein "highway=unclassified" sein), zudem das Fahrzeug-spezifische an der Stelle auch deutlicher wird (außerdem, was sind normale Straßen wenn sie nichts anderes sind als gemeinsame bzw. getrennte Fahrbahn/Fußwege sind?).
Stichpunkt: Fahrbahntrennung an einer Radspur. Da kommt für mich nur "highway=cycleway" in Frage, da dieser am Ende eine Erweiterung der Fahrbahn ist und sonst wie Eine behandelt wird. Ditto Radwege als Fahrradstraßen (sonst würde man der Logik nach jeden Fußweg mit Fahrradfreigabe als "highway=path" taggen, wird von manchen übrigens auch so gemacht wegen dieser Logik).

Am Ende ist das keine (wirkliche) Verzerrung der Realität, vor allem, dass ich die Zugriffe an der Stelle nicht änderte (DAS wäre eine Verzerrung) und dieser Vorwurf ist wirklich unter aller Kanone.

Weißt du noch, wie viele Stellplätze es sich um Behindertenparkplätze sich handeln? Ich habe die Aufteilung größtenteils rückgängig gemacht, da die Einzeichnung der Parkbuchten einfacher und praktischer ist als es in dem Fall nur über "parking:*" zu machen.

Na Wiki był napisane że remonty muszą tyle się trwać na ale to się zmieniło w marcu :

osm.wiki/w/index.php?title=Tag%3Ahighway%3Dconstruction&diff=2827304&oldid=2814266

Jednak : Według Wiki powinno się zaznaczać remonty przes access:conditional i nie przes highway=construction.

Cześć.

Zauważyę że znakałeś remont ulicy. Problem jest że OSM można używać offline (np. nawigacje) i zatem zawarte dane (za) szybko się dezaktualizują.
My normalnie zaznaczymy remonty które potrwają co najmniej sześć miesięce.

osm.wiki/Pl:Dobre_praktyki#Nie_mapuj_tymczasowych_wydarze%C5%84_i_tymczasowych_obiekt%C3%B3w

Warum hast du die Limburger Straße in Neuhof nur zum Teil wieder in "highway=tertiary" zurückgesetzt?

Außerdem sind nicht alle `highway=trunk` auch unbedingt Kraftfahrstraßen (auch wenn die meisten davon solche sind), was gerade bei einfachen Fahrbahnen der Fall ist.

Gibt es einen Grund, warum du einige (gekreuzten) Bundensstraßen durch "highway=trunk" ersetzt hast?

Da frage ich mich, was der Grund für die Änderung ist, insbesondere dass es
a) nicht der Standard ist,
b) die gegenwertige Tags nicht berücksichtigt (was nach einen Hack hindeutet)
c) schon das zweite mal ist, dass das mit Konsti passierte

This isn't what I call a fix because the lines already were connected to the platforms themselves and PTv2 doesn't consider platform edges as valid (same deal with adding public_transport=platform to railway=platform_edge).

Basically, I've reverted it because I don't see what it should really "fix" it.

Verwechslung zwischen "access" und "access:conditional": Bedingungen sind allgemein nur gültig, wenn am Schlüssel ein "*:conditional" angehängt wird.

Das heißt, "access = private @ (Mo-Fr 08:00-17:00)" ist falsch, "access:conditional = private @ (Mo-Fr 08:00-17:00)" is aber korrekt.

Allgemein ist es nicht nötig, eine Straße vor Kreuzungen aufzuteilen, da es schon an sich ersichtlich.

(Zudem wäre es hilfreich, die Abbiegespuren an der Stelle zu mappen, da die Aufteilung an der Stelle definitiv sinnvoll ist und parallel zu "parking:*" gemacht werden kann).

PS: Es nicht gern gesehen, wenn jede Änderung nur eine Aktion ist (z.B. eine Straße aufzuteilen, speichern und dann weiter hinten diese nochmal aufteilen):
osm.wiki/Changeset#Group_similar_changes_together
Das, und das Tagging von Bestimmten Tags falsch (z.B. parking:*:access) und anderen zu komplex (es ist einfacher, die Einschränkung als ":conditional" zu taggen anstelle den Ausnahmezustand).

Kann sein, dass es sich in der Zwischenzeit geändert hat aber Ampeln kann ich zwischen der A 661 und der K 168 nicht erkennen und Höchtsgeschwindigkeiten spielen definitiv keine keine Rolle für highway=trunk, lediglich die Kreuzungsfreiheit und Überholverbot.

Man muss allerdings auch sagen, dass bei vielen der "Parkplätzen" sich eigentlich um Stellpläze handeln (amenity=parking_space, idealerweise in kleinere Stücke aufteilen) und die eigentliche Parkplatzfläche (d.h. einschließlich befahrbarer Bereich) dementsprechend fehlen.

Das macht die Änderung in "parking=street_side" (welches man als Mischung zwischen "amenity=parking" mit "parking=surface" und großflächigere "amenity=parking_space" ansehen kann) nicht weniger falsch, zeigt allerdings auch, dass die Datenlage an der Stelle einfach falsch ist.

Das könnte man als einen automatischen Edit ansehen, gerade weil die Vorschläge für die U-Bahn-Halte m.M.n. falsch sind (wenn normale Züge halten, ist es "train=yes", tun dies aber nicht, deswegen "subway=yes" oder "light_rail=yes")

In anderen Worten: Bitte die iD-"Verbesserungs"-Vorschläge nicht blind übernehmen.