Wenn man die Verbindung zwischen den hier behandelten Stellplätzen und der Straße herstellen wollte, würde man dann eher highway=residential residential=link verwenden oder vielmehr highway=service service=driveway?
Angesichts der Tendenz, dass die Straßenlinie in OSM nur noch die Fahrbahn darstellt, sehe ich hier keine Verkomplizierung, ganz im Gegenteil.
Nun, es gibt ein einzigen textlichen Hinweis auf Tag:parking=street_side – OpenStreetMap Wiki:
When not to use
…
For parking lots (i.e., a dedicated area for parking enclosed by a barrier or containing its own service roads) see parking=surface.
Ansonsten gibt es auf der ansonsten sehr ausführlichen Seite kein einziges Beispiel, auf dem sich die Parkplätze hinter dem Bürgersteig auf Privatgrund befinden. Dieses Thema wird einfach nicht behandelt! Im Moment ist es einfach eine Lücke im Taggingschema.
Und das Überqueren eines Fußweges ist für mich halt KEIN
(für mich auch dann nicht, wenn das Argument vorgebracht wird, dass ja der Bürgersteig zur Straße gehört)
Das stimmt. Demnach sind Garagen direkt an der Straße auch parking=street_side.
genau, weil dort Fahrbahn steht, und Gehwege kein Teil der Fahrbahn sind. Man könnte jetzt nur noch diskutieren ob es vielleicht falsch ist, dass da “Fahrbahn” steht, aber nach der derzeitigen Definition kann es so kein street_side sein.
Das Problem ist, dass einige „Parkplätze“ so eine Chimäre darstellen. Ich würde am liebsten alle Parkplätze dieser Art eher als Straßeneigenschaft erfassen (deswegen war auch meine Tendenz immer eher street_side, weil surface eben nicht an der Straße erfasst werden kann) und nicht separat.
Für parking=surface fehlt die Zufahrt, für parking=street_side die unmittelbare Verbindung zwischen Parkplätzen und Fahrbahn. Das betrifft aber im Grunde auch lange Reihen von Garagen entlang der Straße, ist ja im Prinzip dasselbe in Grün. Letztere habe ich bisher gar nicht als Parkplatz erfasst, sondern einen highway=service + service=driveway von der Straße zur Mitte der Garagen gezogen und entsprechend eine width=* an selbige gesetzt. Was eben daran lag, dass die Garagen sowieso private sind und es eigentlich nur darum ging, zu erfassen, dass man dort nicht auf der Fahrbahn parken darf.
Wenn wir den Ansatz von @Mammi71 weiterspinnen, dass diese Parkplätze ja alle auf Privatgrund liegen, dann müsste das ja ein hinreichendes Kriterium sein. Dann wäre das so gesehen – analog zu on_kerb – vielleicht ein on_property, oder beside_kerb. Aber ich glaube nicht, dass wir jetzt noch einen neuen Typen brauchen, sondern eher überlegen sollten, ob
parking=surface immer eine Zufahrt benötigtparking=street_side und der Fahrbahn auch ein Gehweg sein darf.Und da wäre dann vielleicht ein street_side=* zum Erfassen dieser Besonderheit besser geeignet, eben weil man es direkt an der Straße erfassen könnte und nicht zwangsweise einen separaten Parkplatz mappen muss.
wir haben in den letzten Monaten alle Straßenparkplätze in Berlin gemappt und uns dabei auch angeschaut ob sie im öffentlichen Straßenland sind. Es gibt da seltene Ausnahmen wo street_side Parkplätze nicht auf öffentlichem Grund stehen, oder teilweise auf Privatgrund (laut Alkis). Als tag haben wir operator:type verwendet damit man access zusätzlich eintragen kann (manche sind allgemein benutzbar weil nicht erkennbar privat und keine Schilder).
Und wie habt ihr dabei Parkplätze erfasst, die durch einen Gehweg bzw. Geh- und Radweg von der Fahrbahn getrennt sind?
Ich finde, ja.
Schwierig, weil bevor parking=street_side eingeführt wurde, alle Parkplätze, die ebenerdig sind mit parking=surface getagt wurden. Nachträglich die Definition zu ändern ist problematisch.
Ich würde hier auf jeden Fall surface mappen. In OSM unterscheiden wir verschiedene Kategorien von Parken im parking-Key, die sich wiederum (“fachlich”, aber eigentlich auch wunderbar in der OSM-Logik) in zwei Klassen unterscheiden lassen:
lane, half_on_kerb, on_kerb, street_side und shoulder)surface, Parkhäuser, Tiefgaragen…)“on-street” hört dort auf (und “surface” fängt dort an), wo das Straßenland aufhört. Diese “planerische Logik” ist hier mMn sehr gut kompatibel mit der eher physischen Philosophie von OSM.
Die Beschreibung, wonach ein surface-Parkplatz eine Zufahrt haben “muss”, ist wohl eher dem Umstand geschuldet, dass surface ungefähr so alt ist wie OSM selbst und originär für “einen großen Flächenparkplatz” eingeführt wurde, der eben nun mal solche Zufahrten hat. Über irgendwelche Edge Cases hat sich da noch niemand Gedanken gemacht. Der ganze Straßenparken-Komplex ist im Vergleich dazu ja noch recht jung - zuerst kam street_side, später der Rest (synchronisiert mit den schon vorher entstandenen Centerline-Tags).
Da gibt es also auch noch ne Menge, wo noch Definitionen, Beschreibungen, Beispiele etc. geschärft werden können. Gelegentlich bin ich da dran…
Ich bin z.B. auch eher unglücklich damit, dass street_side oft als “irgendwie am Straßenrand” verstanden wird. Dafür war es eigentlich nicht gedacht, sondern für baulich angelegte Parkbuchten (die gibt es im Eingangsbeispiel nicht). Die Definition war seit Anfang an recht unscharf, da der Rest (z. B. Gehwegparken / on_kerb – könnte man hier schon eher annehmen, wenn es denn Teil des Straßenlandes wäre) erst später dazu kam und es manchmal auch Fälle gibt, wo so eine “Restkategorie” halt bequem passt.
Und wie ist es mit Geh/Radwegen wie hier:
Unter Bezugnahme auf meinen Beitrag
Eingangsbeispiel:
Privatgrundstück (auf Grund Begrenzungssteine wahrscheinlich)
außerhalb des Straßenraumes
fehlende (StVO-konforme) Beschilderung
eher parking=surface
letztes Beispiel:
Privatgrundstück (auf Grund der Beschilderung weniger wahrscheinlich)
außerhalb des Straßenraumes (auf Grund der Beschilderung weniger wahrscheinlich)
fehlende (StVO-konforme) Beschilderung (im Gegenteil, ist vorhanden)
tendenziell schon eher parking=street_side (ich kann aber gut auch gut damit leben, wenn das jemand mit surface mappt)
Da gebe ich Dir vollkommen recht. Aber gerade bei Garagenreihen oder eben solchen Parkplätzen vor Geschäften, ist die Ausgestaltung ja immer so, dass ein Parken dort ein Parken auf der Fahrbahn verbieten würde. Es ist also schon so, dass die Existenz, ja auch die Größe/Länge dieses „Parkplatzes“ Auswirkung auf die Gestaltung der Bordsteine haben und eben ein „Doppelparken“ nicht erlauben. Das war für mich gefühlt auch immer ein Unterschied zwischen street parking und surface parking. Und genau da sehe ich eben einen physischen Zusammenhang und daher kommt auch mein inniger Wunsch, diese Art Parkplatz eher über parking:<side>=* zu erfassen.
die hätten wir vermutlich als surface gemappt, aber das sind keine Straßenparkplätze darum haben wir sie eher gar nicht gemappt.
Genau das ist der Grund, weshalb ich bei Stellplätzen, die einzeln und nur über den Gehweg erschlossen sind, street_side verwendet habe. Ich bin davon ausgegangen, dass die Parkraumanalyse dies aus dem verfügbaren Parkraum ausstanzt - im Gegensatz zu surface. Ich merke aber gerade, dass die Auswertung dass gar nicht macht 
Siehe z.B. hier:
Damit wollte ich verhindern, bei jedem privaten Stellplatz die Straße zu zerstückeln. Auch wenn etwas offtopic: Sollte ich zusätzlich etwas wie Key:obstacle:parking - OpenStreetMap Wiki an die separat eingetragene Stellplatzfläche hängen? Oder wäre es besser die Auswertung zu erweitern? @Supaplex030
Wäre es nicht einfacher, kerb=* zu erfassen?
kerb=* auf Wegen zu erfassen ist nicht unumstritten und momentan müsste man mindestens noch parking:<side>=no + parking:<side>:restriction=no_parking erfassen. Oder sollte parking:<side>=separate das alles auch können? Ist separate überhaupt angebracht bei parking=surface? Ja wohl eher nicht, oder?
Fazit: 5 Mapper, 5 Meinungen.
1 etabliertes Mapping
1 alternatives Mapping
1 Neudefinition von bestehendem Tagging
1 neues Proposal
1 neues Subtagging für mehr Details
Immer wieder lustige Runden hier 
Gute Nacht.
Bitte so einfach wie möglich mappen!!!
Seitlicher Parkplatz mit Gehweg dazwischen =street_side
Extra Parkplatz, wo eine extra Zufahrt nötig ist=surface
Übrigens sieht das Osmose auch so… was ich da schon von parking=surface in parking=street_side geändert habe… 
Ich habe nicht mitgezählt… 
vielleicht braucht es einen neuen Wert für street_side wenn der tag anscheinend skunked ist 