Für Parkplätze am Straßenrand ist der key parking:lane vorgesehen. Zur Benutzung heisst es in der englischen Wiki:
In der deutschen Wiki wird dagegen das genaue Gegenteil gefordert:
Davon abgesehen ist es natürlich schon eine ordentliche Schnipselei, wenn man eine Straße, an der in Abständen von 30 Metern Parkbuchten für jeweils 2-4 Fahrzeuge angeordnet sind, entsprechend in Segmente aufteilen will, vor allem, wenn sich linke und rechte Straßenseite nicht entsprechen.
Da ist es von der Arbeit her wesentlich übersichtlicher, die Parkbuchten als Fläche mit amenity=parking zu mappen. Man kann die Flächen sauber darstellen und braucht dann auch nicht diese endlos-tags wie parking:lane:left:parallel=street_side oder parking:lane:right:capacity:disabled=*. Ich würde amenity=parking hier auf jeden Fall favorisieren, es wird aber z.B. von Osmose angemeckert.
Ich bin mir sicher, dass das schon früher mal diskutiert wurde, kann aber kein entsprechendes Topic finden. Wie macht man es denn jetzt am besten?
Frage: Hier auf den Dörfern gibt es am Ortsrand öfters neben der Straße bekieste Parkplätze ganz ohne Aufteilung oder spezieller Zufahrt. Man fährt einfach an irgend einer Stelle von der Straße auf den Platz und bleibt dort stehen. Wenn man diese Plätze als area mit amenity=parking mappt, wird von Osmose angemeckert, dass der Platz keine Zufahrt hat. Macht es Sinn, dann eine Zufahrt zu erfinden, auch wenn es eine solche OTG nicht gibt, oder die Fehlermeldung als “Falschmeldung” wegknipsen?
Wegknipsen. Das ist einer der ganz wenigen Fälle, in denen ich es sinnvoll finde, Flächengrenze und Linienelement zu verkleben. Wenn du die innere Parkplatzgrenze an den Straßen-Way klebst, drückst du damit perfekt aus, dass die Parkpositionen direkt von der Straße aus anfahrbar sind, ohne dass es eine separate Zufahrt gibt.
Was meckert denn Osmose? “fehlende Zufahrt”?
Allgemein sollte man die Parkbuchten auf Straßen als “amenity=parking + parking=street_side” nutzen. Da sollte auch Osmose nicht mehr meckern.
Danke für den Tip … ich hatte bisher im Wiki lediglich die Ausführungen zum Taggen von Parkbuchten unter parking:lane=street_side gesehen. Dass es eine zusätzliche Wikiseite für den Tag “parking=street_side” gibt, war mir bisher entgangen. Die Kombination “amenity=parking + parking=street_side” werde ich als nächstes mal probieren - mal schauen, was Osmose dazu zu sagen hat.
Zu 2.:
Siehe hier den Parkplatz am Sportgelände Tankwartshausen (in der Bildmitte):
Solche Plätze gibt es hier in fast jedem Dorf, häufig an Sportplätzen und Vereinsgeländen, auch öfters am Ortsrand, wo die Gassigeher und Luftschnäpper parken. Nicht weit entfernt an der Werra sind gleich noch 2 solche Plätze. In den größeren Ortschaften sind diese im Normalfall beschildert und asphaltiert, die kleinen Gemeinden haben für so was oft kein Geld. Es darf aber ganz offiziell dort geparkt werden.
Da würde ich ein highway=service als Verbindung in der Mitte oder an beide Enden mappen und surface=* entsprechend auch für den Parkplatz (parking=surface) verwenden. Rein Straßen-begleitend ist der ja nicht mehr.
Wenn es sich nicht nur um eine einzelne Parkreihe parallel zur Straße handelt sondern um einen größeren Platz,arbeite ich mit einer virtuellen Zufahrtsstraße, die ich mitten in die Fläche hineinführe.
Ich habe die bisher bearbeiteten Plätze brav als separate area OHNE fixing an den way der Straße (voll guter Deutsch Alder ) gemappt, obwohl der Vorschlag, die beiden Elemente aneinanderzupappen, durchaus ihren Reiz hat . Deswegen meckert Osmose ja auch die fehlende Zufahrt an.
Den Vorschlag, einen highway=service von der Straße irgendwo in die Fläche zu führen, werde ich wohl aufgreifen, aber mal ganz ketzerisch ausgedrückt ist das schon irgendwie Taggen für den Router (der den Parkplatz sonst nicht findet), wenn man eine Zufahrt erfindet, die real in der dargestellten Form nicht existiert, oder?
Bzgl. Verkleben von ways und areas meine ich in einem der zahllosen Wikis oder Forenbeiträge gelesen zu haben, dass es bis dato keinen echten Konsens gibt, ob dies generell bäh ist oder in einigen Fällen (z.B. landuse-areas an Wegen) eben doch Sinn macht, oder irre ich mich da?
Kann man so sehen. Ich sehe es aber so: Es gibt ja eine Zufahrt. Die ist nur sehr breit, eben halt so breit, wie die komplette zur Straßen hin liegende Parkplatzbreite.
Na ja - das könnte ja auch daran liegen, dass man die gesamten highway=* so mappt, wie sie real gar nicht existieren.
OSM ist (und wird wohl auch auf ewig so bleiben) halt ein Kompromiss bzw. Mischmasch aus flächigem “Malen-nach-Zahlen”, linienförmig abstrahierten Routing-Informtionen und punktförmigen “Interessen”.
Machen wir halt das Beste daraus.
das Verkompliziert die Auswertung aber ziemlich, weil man um die Kapazität oder den Flächenverbrauch zu schätzen dann von den viel zu großen Parkplatzflächen erstmal die geschätzten halben Straßenflächen wieder abziehen muss, wobei man bei gegeben width auf dem highway auch erstmal überlegen müsste, ob da die Parkspuren ggf. drin sind oder nicht. M.E. besser die realen Parkflächen mappen mit parking=street_side kennzeichnen wenn man das überhaupt explizit machen will.
Persönlich habe ich generell Bauchschmerzen, wenn die beiden Systeme, Flächen und Linien mit gewissen Breiten, vermengt werden.
Im Fall von Landnutzung (landuse/natural) Stelle ich meistens die Frage, bis wohin die Fläche den geht, sowohl auf der Quelle wie in Realität. Die Antwort ist äußerst selten die Straßen-/Wegmitte. Und selbst wenn, geht das auch sehr gut separat um 50 cm versetzt zur Wegmitte. Wenn Du Lust auf Flächen hast, kannst Du Dich bei area:highway=* oder eventuell auch landuse=highway bedienen.
) gemappt, obwohl der Vorschlag, die beiden Elemente aneinanderzupappen, durchaus ihren Reiz hat 
. Deswegen meckert Osmose ja auch die fehlende Zufahrt an.
