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.

Da habe ich wohl definitiv was falsch kopiert. :) Behoben.

Ernsthafte Frage: Gibt es einen Grund, warum du das Parking-Taggings auf deiner Art machst?

Zuallerst ist das Tagging falsch: Du verwendest access-Werte mit einer Bedingung, was aber falsch ist, da Auswerter diese sonst als rohe "access"-Werte anstelle von Bedingungen ausgewertet werden (d.h. du solltest "access:conditional" verwenden, wie du es schon bei bei "parking:*:restriction:conditional" machst).
Dann ist es noch so, dass die access-Logik auf positive Werte, logischer aber ist es, wenn du die Einschränkung als Bedingung tagst (bei positiven "parking"-Werten" gilt "access=yes", wenn nicht überschrieben und Auswerter dementsprechend auch nicht wissen, dass man an den gegebenen Zeiten eigentlich nicht parken darf), wodurch die ganze Bedingungslogik auch vereinfacht wird.

Außerdem ist für "private=residential" keine Bedingung nötig, da diese eh nur bei "access=private" ausgewertet wird.

Ich habe deine Änderungen manuell zurückgesetzt.

Zu allerst ist access=bus zu vermeiden, da es von der Bedeutung her uneindeutig ist (dürfen andere da auch hinfahren oder nicht) und zudem Fußgänger (die allgemein von den Schildern wenig eingeschränkt werden) mit einschließt und hat sogar dafür gesorgt, dass es zu einer Verschlimmbesserung kam.
Außerdem ist die Grüneburgweg eh KFZ frei, von daher sind alle anderen Verkehrsmodi (z.B. bus, psv) auch implizit erlaubt (das passende Tagging aber fehlte aber an der Stelle).

Außerdem hast du die Zugriffe auch auf dem Radweg übertragen, was aber falsch ist, da Busse darauf nicht passen und SIW auch in dieser Richtung nicht freigegeben ist.

I assume you forgot to save on iD or had written to an open changeset? This is because you edited stuff in both Munich and Seydisfjordur which affects more things than a single bench.

But the reason I drew building parts in the first place is because they ARE different in reality (check the areal imagery on that building). That's what I meant with "record any useful data" in that I couldn't figure out any colours or levels when I surveyed this area but the differences are there (hence why they "[can] be filled in later on).

I've decided to restore these building parts because they don't really hurt in the database.

Define "unneeded": Just because I couldn't record any useful data for them doesn't mean they can't be filled in later on.

Übrigens vergessen, meine Änderungen, einige Gebäude mit Wikimedia zu verbinden, vorerst hochzuladen.

Habe ich übrigens fast vollständig zurückgesetzt: Die zwei Zufahrtswege sind keine Nebenfahrgassen, die drei "Parkplätze" sind (noch nicht aufgeteilte) Stellplätze, sonst hätte man Parkplätze innerhalb von Parkplätzen, was völlig sinnfrei ist.

Es gibt praktische Gründe hierzu:
- Parkplätze: Mit den Einfahrten wird. Die Erfuhrter Straße wurde deswegen einmal zerstückelt (in Teile, die kürzer als 3m sind) bevor ich erklärte, dass solche Einschränkungen implizit sind (weswegen ich an der Stelle auch die ganzen Einfahrten einzeichnete) und Parkplatzauswerter diese selber bearbeiten müssen.
- Routing: Bei separaten Bürgersteigen sind die Einfahrten eine Möglichkeit, diese Querungen zu verwenden. Teilweise ein Hack aber dennoch spielt es vor allem fürs Rollstuhlrouting eine große Rolle, weil viele Einfahrten abgesenkte Bordsteine haben.

Außerdem gibt es noch andere Karten, die davon profitieren z.B. 3D-Karten wie OSM2World oder f4maps, um eine detailliertere Welt darzustellen.

Das ist auch der Grund, warum Tagging für den Renderer auch nicht gern gesehen wird, weil man davon ausgeht, dass Carto der Kern von OSM ist, auch wenn dann dadurch dann andere Daten beschädigt werden.

Anders als z.B. mit separaten Bürgersteigen (wo man durchaus vorsichtig handhaben muss), sind diese Einfahrten eher harmlos, gleiches gilt auch für andere Formen von Micromapping
wie Gebäudeteile (ist mir schon mal im Bad Kreuznacher Industriegebiet passiert) oder ein Wassergraben an einer Straße (z.B. am Westerhaus in Ingelheim).

Ich aber schon (habe diese ja auch selber hinzugefügt), insbesondere weil das Mappen der Einfahrten auch anderen Nutzungen hat als nur für die Darstellung der Karte...

Also, you've added house=semi_detached onto the nodes of some of these houses. I've removed these some days ago but it's a slip up nonetheless.

Ich habe diese Änderung nun zurückgenommen und der Straße ein "parking:both:staggered=yes" hinzugefügt. Je nach Lage könnte man es aber entfernen, weil die Idee davon ist, dass die parkenden Autos die Seite wechseln, weil zwei nicht gleichzeitig existieren können (was auf den Luftbildern aber durchaus der Fall ist), nicht weil auf beiden Seiten Einfahrten vorliegen. Das müsste ich aber vor Ort überprüfen.

"schade dass mit dem Änderungssatz die Information wegfällt, wo genau die Parkplätze sind, das war tatsächlich Handarbeit vor Ort."
Finde ich nicht so cool, weil dadurch die Straßen ÜBELST fragmentiert werden und das Bearbeiten davon auch SEHR stark verkompliziert und zudem noch inflexibel ist.
Lediglich beim Fall von tatsächlichen Parkbeschränkungen (d.h. Park- und Halteverbot) ist die Fragmentierung von Parkplätzen sinnvoll, da diese Einschränkungen auch real sind und selbst wenn sind diese auch nicht so kurz wie bei deinen Änderungen.

"Wie wäre es denn damit, die Parkplätze nicht als Eigenschaft der Sraße zu mappen, sondern die tatsächlichen Parkflächen zu mappen und auf der Straße tags zu setzen, dass die Parkplätze separat gemappt sind?"
Das ist auch die einzige sinnvolle Lösung, lohnt sich aber m.M.n. auch nur bei explizit markierten Parkplätzen (Verifizierbarkeit).

Ansonsten darfst du auch nicht vergessen, dass einige Parkeinschränkungen und -eigenschaften auch anderswertig dargestellt werden können z.B. mit "parking:both:staggered=yes" um darzustellen, dass die Parkplätze an eine Straße sich abwechseln.
Bei diesen Änderung hast du wiederum so gemacht, dass an den Einfahrten kein "parking:*=*" hinzugefügt worden ist (das ist übrigens unvollständig und sollte mit "parking:*=no" ergänzt werden), allerdings fällt dass unter Tagging für den Datennutzer, da diese dies selber an Grundstückszufahrten berechnen können.
Tatsächlich nennt die englische Seite für straßenseitiges Parken einige Beispiele von impliziten Einschränkungen (darunter die o.g. Einfahrten) und auch auf der deutschen Seite wird es implizit genannt, dass das Aufteilen der Straße wegen einzelner Parkplätze unnötig ist (z.B. ein markierter Behindertenparkplatz an gefolgt von unmarkierten Allgemeinparkplätze).

Ich bin jedenfalls dafür, dies auf den Ursprungszuständ zu ändern, da diese Aufteilung kaum sinnvoll ist.

Wenn du willst, kannst du es in den Foren besprechen, ich glaube aber auch nicht, dass du damit wirklich Unterstützung erhalten wirst.

Nördlich des des Güterbahnhofs, nahe Rhoischnook, gibt es ein solches Schild, welches besagt, dass Am Leinpfad ein Betriebsgelände ist. Auch an der Südbrücke habe ich dort ein solches Schild gesehen zu haben.