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.

Ist auch ein Teil der Binger Straße die K 49 oder war das ein Versehen?

Auf Grund der Tatsache, dass die Wege dort Betriebsgelände sind und dass ich auch nicht bemerkte, wie weitreichend die Beschilderung eigentlich gilt.

Kleine Tipp fürs nächste mal: Entfernte Elemente nicht sofort löschen, sondern durch "demolished:*=*" bzw. "razed:*=*" kennzeichnen, da die zerstörten Gegenstände auf den alten Luftbildern immer noch erkennbar sind (in dem Fall ist es okay, da du hier ein neues zeichnetest und dadurch ersichtlich ist, dass die Luftbilder veraltet sind aber trotzdem).

Das liegt wegen dem natural=water, welches blaue Flächen zeichnet. Diese können aber unter Umständen gestreift dargestellt werden z.B. mit intermittent=yes oder bestimmten basin-Werte.

Manchmal kann es auch sein, da hilft es dem Cache neu zu laden aber in dem falls waren die Becken die ganze Zeit gestreift dargestellt.

Ich würde dir jedenfalls nicht empfehlen, dies vollständig aus der Karte zu entfernen (selbst rein von der Darstellung her), da dadurch an Daten verfälscht werden (nennt sich auch Tagging fürs Rendering).

Einfach unter Orte das Geschäft auswählen und dann einen neuen Namen eingeben.

Was ich mit "dranhängen" meinte: Es ist mit building:parts=* nicht möglich, vom Gebäude was zu entfernen, was gerade fürs Modellieren von Durchgängen ein Vorteil ist, nur um am Gebäude etwas dranzuhängen; die Darstellung des Durchgangs über building:part ist aufwendiger als wenn man die Durchgangsfläche einzeichnen würde, und dafür habe ich ein man_made=tunnel verwendet analog zu den Gebäudedurchgängen als Wege.

Rein aus Neugier (und um neue Hinweise zu meiden): Gibt es übrigens einen Grund, warum du Namensänderungen nicht direkt über StreetComplete machst?

Das Problem an der Stelle ist hierbei, dass es nicht möglich ist, von Gebäuden etwas abzuschneiden. building:parts ist eher dazu gedacht, Teile am Gebäude dranzuhängen und nicht, um etwas zu entfernen (weswegen es einfacher ist, eine Fläche, die von etwas wegnimmt, als um das Äußere zu zeichnen).

Außerdem ist es noch so, dass Wege über tunnel=building_passage definiert sind, weswegen ich hier analog man_made=tunnel mit tunnel=building_passage verwendete (außerdem ist es selber kaum definiert bzw. nicht wirklich verwendet und mögliche Praktiken bzw. Standards sind noch nicht etabliert d.h. es kann sich in Zukunft als eigentlicher Standard etablieren).

Wenn ich es anders mappen würde, dann aber über area:highway, da man darüber hinaus auch noch die Höhenbeschränkung eingeben kann und bei einem 3D-Modell dadurch auch detailliert was abschneiden kann (nachteilig aber ist es nicht möglich, die Wege in eines einzelnen Durchgang zu kennzeichnen z.B. Straße mit Bürgersteig).

Stimmt. Korrigiert.

Warum hast du Gonzenheim und Ober-Eschbach als place=village umgetaggt, obwohl beide Stadtteile ganz klar mit der Innenstadt zusammengewachsen sind? place=village wird nur für eigene Dörfer oder isolierte Stadtteile (vgl. die Bad Vilbeler Stadtteile, die alle place=village verwenden mit Ausnahme von Heilsberg und selbst das ist grenzwertig) verwendet, beides trifft hier nicht zu.

Der Hauptgrund, warum ich dort einen Weg hinzugefügt habe, liegt, dass der Bordstein dort abgesenkt ist und dementsprechend eine Verbindung zwischen Rheinstraße und Peter-Altmeier-Allee geschafft wird (die Bordsteine kann ich da dementsprechend einzeichnen, insbesondere, weil diese auf den Luftbildern erkennbar sind).

Das mit den Pollern ist vermute ich mal ein Nebeneffekt, dass ich diese als eine Linie und nicht als einzelne Punkten zeichnete und ich nicht so ganz sicher bin mit Barrieren als Linie vs. Barrieren als Punkt.
Einen Pollerpunkt habe ich jedenfalls hinzugefügt, um es auch auf Carto sichtbar zu machen.

Allgemein ist es so, dass service=parking_aisle für alle möglichen Parkplatzwegen verwendet, egal ob diese Wege eigentlich um Nebenfahrgassen oder Hauptzweige sich handeln.
Das ist auch der Grund, warum ich bei einigen Parkplatzwegen in der Umgebung das service=parking_aisle entfernt habe, einschließlich dieser Wege.

Auf der englischen Wiki steht unter "Disambiguation":
"Road connects a parking lot or parking garage to a through street and serves as the entrance or exit of the lot or garage – use highway=service without service=* instead."

Und das trifft für diese Parkplatzwege am Ende auch zu: Ein Weg einer Durchfahrtsstraße (Jakob-Weldwer-Weg) zu einem Parkplatz.

Das hat drei Gründe:
- landuse=grass ist keine typische Flächennutzung und versuche es dementsprechend, soweit es geht zu ersetzen (hauptsächlich aber in landuse=meadow bzw. natural=grassland).
- Manchmal steht es im Konflikt zum existierenden landuse=*. (Straßen-)Bahngelände sind ein typisches Beispiel: Diese kommen häufiger als Rasen vor und die Verwendung von landuse=grass steht im Konflikt zum landuse=railway (m.M.n. der Hauptgrund für die Nutzung von landcover=*).
- Auch wenn es eher unwahrscheinlich ist, erhöht die Chance, dass dieses Tag am ende akzeptiert werden.

Zu meiner Verteidigung sind die Änderungen nicht einmal bei den 2022-Luftbildern erkennbar und auch bei Bing sieht man lediglich den Anfang der Änderungen.

Die Formen der Wege habe ich jedenfalls auf den Anfangszustand zurückgesetzt aber ich bin immer noch der Meinung, dass das service=parking_aisle hier nicht passt.