DE talk:Tag:amenity=parking

Tiefgaragen

Da bisher keine ausführliche Dokumentation für Tiefgaragen vorhanden ist dokumentiere ich mein Vorgehen an dieser Stelle.

Aufgabe: Darzustellen war eine Tiefgarage, die mehrere (an verschiedenen Stellen) Ein- bzw. Ausfahrten für PKW hat. Daneben existieren weiter Eingange für Fußgänger.

Problem: Der unterirdische Verlauf der Wege ist unbekannt bzw. nicht unproblematisch darstellbar.

Ziel: Es soll deutlich werden, dass alle Eingange/Einfahrten zur gleichen Tiefgarage gehören. Ein überirdisches Routing zu den einzelnen Eingängen sollte prinzipiell möglich sein.

Lösung: Der Fall ist mit dem neuen parking-schema abgedeckt: http://wiki.openstreetmap.org/wiki/Proposed_features/parking. Die Darstellung einer Tiefgaarage mit den oben beschriebenen Problemen ist über eine Relation möglich: http://wiki.openstreetmap.org/wiki/Proposed_features/parking#Underground_parking

Die Tiefgarage selbst wird nur noch in einer Site-Relation erfasst:

• type=site
• site=parking
• name=[Name der Tiefgarage]
• amenity=parking
• parking=underground
• sowie weiterer Tags zur näheren Beschreibung der Tiefgarage.

Eingänge zur Tiefgarage werden als Node in der Datenbank erfasst:

• amenity=parking_entrance

• name=[Name des Zugangs] z.B. Fußgängerzugang Y-Straße oder Einfahrt X-Straße
• Wer den Eingang benutzen kann wird über die klassischen access-Tags angezeigt.

• Ein Eingang für Fußgänger: vehicle=no, foot=permissiv
• Eine Fahrzeugzufahrt: vehicle=permissiv, foot=no

Die Eingänge zur Tiefgarage werden in die Relation aufgenommen, erhalten in der Relation aber keine Rollenbeschreibung

— nicht signierter Beitrag von Falcius (talk • contribs) 11:47, 14 April 2012, bearbeitet 16:01, 15 April 2012

dein fall ist bereits mit dem neuen parking-schema abgedeckt: http://wiki.openstreetmap.org/wiki/Proposed_features/parking. tiefgaragenbeispiel ist hier explizit erwähnt: http://wiki.openstreetmap.org/wiki/Proposed_features/parking#Underground_parking --Flaimo 12:29, 14 April 2012 (BST)

Ach herje, dass hätte ich dann auch einfacher haben können :-/ Sehe ich es richtig, das nach dem proposed feature das Parkhasu selbst überhaupt nicht mehr als eigene Node erfasst wird, sondern ausschließlich in der Relation?--Falcius 12:40, 14 April 2012 (BST)

Exakt. Der Renderer oder das Routingprogramm sucht aus der Relation alle Mitglieder zusammen und kann dann zentriert ein "P" malen (so wie bei den Haltestellenrelationen auch). Routingprogramme könnten alternativ auch das "P" bei der Entrance hinmalen die meiner aktuellen Position am nächsten ist. --Flaimo 14:47, 14 April 2012 (BST)

Beispiele, bei denen ich das Tagging umgesetzt habe: Beispiel 1 Wobei ich den Node mit der Tiefgarage belassen belassen habe und die Tiefgaragentags zusätzlich in die Relation kopiert habe. Beispiel 2, hier befinden sich die Tiefgaragentags ausschließlich in der Relation.--Falcius 09:15, 29 April 2012 (BST)

access=customer

Laut der access Seite im Wiki gibt es auch den Wert "customer". Ist dieser nicht passender bei Supermärkten etc als "permissive"? --Soldier Boy 13:39, 18 May 2012 (BST)

das "customer" ist ziemlich umstritten. ich würde dass noch nicht so im wiki vermerken. ich würde es bei permissive belassen und ggf customer nach dem neuen, vorgeschlagenen access-schema mappen, was parallel existieren kann: http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5 --Flaimo 14:54, 18 May 2012 (BST)

Private Parkplätze gar nicht mappen?

Im Artikel heißt es:

Zudem sollen generell nur öffentliche Parkplätze eingetragen werden, da private Parkplätze (z.B. für die Mitarbeiter einer Firma) für parkplatzsuchende Menschen in der Regel nicht sehr hilfreich sind.

Meine Frage: ist das wirklich noch aktuell? Und ist das so eindeutig? Es gibt doch einige Gründe dagegen:

• Beim Lesen der englischen Fassung des Artikels kann ich keinen expliziten Hinweis dieses Inhaltes entdecken. Vielleicht habe ich ihn nur übersehen. Ansonsten frage ich mich, warum wir hier einen deutschen „Sonderweg“ brauchen.
• Private Parkplätze aller Art können ja leicht durch ein passendes access=*-Tag ausgewiesen werden. Unser Standard-Renderer stellt das ‘P’-Symbol dann blass dar, sodass die Unterscheidung von öffentlichen Parkplätzen leicht fällt. Damit entschärft sich das Problem der „parkplatzsuchende[n] Menschen“ zumindest, oder entfällt sogar ganz.
• De facto werden inzwischen sehr oft auch private Parkplätze (v.a. größere, etwa Firmen-Parkplätze) gemappt. Die Regel wird also zumindest nicht mehr allgemein beachtet.
• Ein guter Grund dafür ist die zunehmende Vollständigkeit vieler Stadtpläne: wenn man einen größeren Privat-Parkplatz gar nicht einträgt, klafft an dieser Stelle einfach eine Lücke auf der Karte, was seltsam ist. Denn ...
• Das Wichtigste: Wir mappen doch nicht nur „für parkplatzsuchende Menschen“! OSM ist inzwischen viel mehr als eine bloßen Straßenkarte und in vielen Orten bereits viel genauer, als es handelsübliche Straßenkarten je waren. Ich meinesteils etwa mappe, weil ich korrekte, vollständige und detaillierte (!) Stadtpläne liebe. Einen großen Parkplatz einfach auszulassen, sei er auch noch so privat, scheint mir daher unangemessen.
• Viele dieser Parkplätze sind zudem zumindest für Fußgänger sehr wohl öffentlich zugänglich und begehbar.

Daher frage ich mich, ob man die zitierte, sehr generelle und autoritär daherkommende Formulierung nicht zumindest etwas abschwächen sollte.

Viele Grüße, --Chrysopras (talk) 11:05, 19 May 2013 (UTC)

Sehe ich auch so. Ausserdem haben "parkplatzsuchende Menschen" gelegentlich auch Zugang zu diesen privaten Parkplätzen (z.B. als Mitarbeiter/Kunde/Besucher). --rayquaza (talk) 14:13, 4 October 2013 (UTC)

amenity=parking nur bei P-Zeichen mappen?

In der deutschen wie auch englischen wiki-Seite kann ich keinen entsprechenden Hinweis finden wann ein Platz auch als Parkplatz erfasst wird. Sehr oft gibt es Flächen auf denen Parken möglich ist, geparkt wird, es nicht ausdrücklich verboten ist und/oder das Parken geduldet wird - jedoch kein Parkplatz-Schild, wie das StVO-Zeichen 314, vorhanden ist.

Mein Frage ist ob diese Plätze trotzdem mit amenity=parking gemappt werden sollen!? Schließlich sind sie keine offiziellen Parkplätze. --Saxonyking (talk) 14:16, 4 June 2014 (UTC)

Parkplätze nur für PKW

Wie ist Ein Parkplatz zu kennzeichnen, der nur für PKWs zugelassen ist? Dort steht an der Parkplatzeinfahrt das übliche Verkehrszeichen (traffic_sign=DE:314) in Verbindung mit einem Schild, auf dem ein PKW abgebildet ist (wie traffic_sign=DE:1024-10, nur ohne das Wort "frei"). Wäre access=motorcar eine Lösung?--Der-martin (talk) 00:26, 18 June 2014 (UTC)

Sollte es sich um Parkplätze entlang von Straßen handeln, dann bitte parking:lane verwenden. In diesem Fall wird z.B. parking:condition:both:vehicles=motorcar verwendet, siehe: http://wiki.openstreetmap.org/wiki/Key:parking:lane#Only_some_vehicles_allowed --Saxonyking (talk) 19:44, 18 June 2014 (UTC)

Danke für die (schnelle!) Antwort, sie hilft aber leider in diesem konkreten Fall nicht weiter. Es geht um die Karl-Marx-Allee in Berlin-Mitte, im Bereich zwischen Schillingstraße und Alexanderstraße / Otto-Braun-Straße. Dort befindet sich der Parkplatz auf der Mittelinsel der Karl-Marx-Allee, die in Form zweier einzelner Straßen mit jeweils oneway=yes getaggt ist (was ich nicht selbst gemacht habe, aber für äußerst sinnvoll halte). Von daher schließt sich ein parking:lane-tag meiner Meinung nach aus, zumal dieser bereits für die Parkplatzsituation auf beiden einzelnen Seiten dieser Einbahnstraßen verwendet wird, jeweils in Richtung des OSM-Weges (wofür wiederum ich verantwortlich bin - Verbesserungsvorschläge sind selbstverständlich immer willkommen, daher ja hier diese Frage ;-)).--Der-martin (talk) 08:28, 24 June 2014 (UTC)

maximale Höhe

Gibt es eine möglichkeit die maximale Höhe einzutragen? Sehr hilfreich wenn man mit transporter unterwegs ist... Eigentlich könnte dafür maxheight ja auch problemlos herhalten. Vielleicht wird das teilweise schon auf den highway gemappt, aber da parkhäuser und teilweise parkplätze auch mit einer maximalen höhe gekennzeichnet werden, sollte das ja auch dort sinnvoll sein zu taggen Hakuch (talk) 11:58, 4 April 2017 (UTC)

maxheight=2.5 - direkt am Parkplatz. Wenn es auch für die Zufahrtswege gilt, dann evtl auch noch an der Zufahrt auf den Weg taggen. Nicht zu verwechseln mit height=X, das wäre die Höhe des Parkhauses. --Mueschel (talk) 11:51, 4 April 2017 (UTC)

dan würde ich das mal auch auf die Wikiseite mit aufnehmen, sprech das aber kurz noch auf der englischen talk seite an.. Hakuch (talk) 11:58, 4 April 2017 (UTC)

parking:condition nur für parking:lane=* oder auch für amenity=parking?

Hallo!

Ich habe gerade den Fall, einen kleinen Parkplatz, der nur für ANWOHNERPARKEN gedacht ist (zu bestimmten Zeiten plus ein bestimmter Anwohnerparken-Buchstabe), zu taggen. Der access-Key für amenity=parking o.a. hilft da nicht weiter ...

Aber dafür gibt es ja eigentlich parking:condition=* (mit Wert "residents"), das auf der englischen Wiki-Seite zu "amenity=parking" auch unter "See also" aufgeführt ist, auf der deutschen leider nicht. Und klickt man es (auf der englischen Seite) an, landet man per Weiterleitung bei parking:lane=*, wo eben auch parking:condition erklärt ist (und auch parking:condition:time_interval für die zeitliche Gültigkeit) ... Es gibt also keine eigene, allgemeine Seite für "parking:condition", leider ...

Allerdings wird parking:condition dort auch immer nur mit dem Anhang "side" (:left, :right oder :both) aufgeführt, was bei parking:lane ja auch Sinn macht. Mir ist nicht ganz klar, ob der Zusatz ":side" OPTIONAL ist oder zwingend zu parking:condition dazugehört. Im Prinzip sollte es ja optional sein wie alle Tag-Erweiterungen (denke ich).

Mein Frage: kann man parking:condition=* – dann eben OHNE Anhang :left, :right oder :both – (und parking:condition:time_interval) denn auch für amenity=parking benutzen? Da sollte doch eigentlich nichts dagegen sprechen, oder?

Ich habe bisher nur im Talk zu parking:lane einen kleinen Beitrag gefunden, der wohl auf das gleiche Problem eingeht, mit Verweis auf diesen Parkplatz, wo der User anscheinend "parking:condition:area" benutzt hat – auch eine Möglichkeit. Aber er hat im Talk keine Antwort bekommen dazu ...

Gibt es hier vielleicht Meinungen/Anworten/Vorschläge, die weiterhelfen?

Also:

1. Sollte parking:condition auch für amenity=parking möglich sein oder ist es jetzt schon möglich?
2. Dann mit Zusatz ":area" oder einfach ohne Zusatz?

Und sollte man darauf nicht im Wiki (auf amenity=parking) noch eingehen? --Goodidea (talk) 22:32, 1 June 2018 (UTC)

"parking:condition" wird praktisch ausschließlich zusammen mit parking:lane verwendet. Was du suchst ist "access:conditional". Der richtige Wert für access ist entweder access=residents (1200 Mal verwendet weltweit, aber nicht weiter dokumentiert) oder das gut bekannte access=private. Wenn das dann nur zu bestimmten Zeiten gilt, nimmst du access:conditional=private @ (Mo-Fr 22:00-06:00). Siehe https://wiki.openstreetmap.org/wiki/Conditional_restrictions --Mueschel (talk) 10:16, 2 June 2018 (UTC)

Ein Nachtrag: access:conditional=* funktioniert im Fall von Anwohnerparkplätzen tatsächlich nur mit "private" als Wert ohne Probleme. Das eigentlich präzisere "residents" ergibt einen Prüffehler in JOSM ("access:conditional-Wert: residents ist kein Einschränkungswert"). Ich würde daher auch wie von Mueschel vorgeschlagen bei zeitlichen Einschränkungen (was zumindest in Deutschland sehr häufig vorkommt) so taggen (Beispiel wie oben): access:conditional=private @ (Mo-Fr 22:00-06:00). Denn "private" steht ja auch für "Benutzung für die Allgemeinheit nicht erlaubt", was ja im Fall von Anwohnern auch zutreffend ist (Anwohner = nicht die Allgemeinheit, auch wenn es hier ja nicht um Parkplätze in Privatbesitz geht). Ich finde es nicht ganz schön, weil nicht intuitiv verständlich, es wirkt für mich nicht ganz sauber. Und kleiner Nachteil gegenüber der parking:condition-Methode (die wiederrum nur bei parking:lanes beschrieben ist, und zwar stets mit einer Seitenangabe – left|right|both): für eine Angabe eines Anwohnerparken-Schlüssels (z.B. ein Buchstabe) gibt es keinen Standard (wie es z.B. so möglich wäre parking:condition:residents=G). Das könnte man dann höchstens in einer note oder description angeben, z.B. description=Von Mo-Fr 22:00-06:00 nur Anwohnerparken (mit Parkausweis G), was vielleicht sowieso eine gute Idee wäre für die menschliche Lesbarkeit. --Goodidea (talk) 08:02, 8 December 2018 (UTC)

Tagging von Wanderparkplätzen

Wie taggt man einen Wanderparkplatz? --Mfbehrens99 (talk) 19:46, 17 October 2021 (UTC)

In 459 Fällen wurde schlicht name=Wanderparkplatz benutzt, siehe https://overpass-turbo.eu/s/1g06. Eher keine zufriedenstellende Lösung. Das hängt vermutlich damit zusammen, dass andere Angaben als name auf den Karten bislang nicht angezeigt werden. Für mich gehört die Bezeichnung "Wanderparkplatz" eigentlich in description=*. Eine spezielle Kennzeichnung für Wanderparkplätze gibt es meines Wissens nicht. Eine Möglichkeit wäre vielleicht, das Verkehrszeichen als Attribut zum Parkplatz hinzuzufügen: traffic_sign=DE:317 --Chris2map (talk) 18:35, 11 February 2022 (UTC)

Ich denke, hiking=yes wäre eine gute Ergänzung. So machen wir es ja z.B. bei Wegweisern, wenn diese "irgendwas mit Wandern" zu tun haben. Falls es eine Wanderroutenrelation gibt, kann man den Parkplatz außerdem laut Wiki mit der Rolle approach kennzeichnen. --Supaplex030 (talk) 21:00, 11 February 2022 (UTC)

LKW Parkplatz

Hallo, ich habe leider keine info gefunden, wie man einen reinen LKW Parkplatz taggen kann. Wer kann mir weiterhelfen? Danke. Beispiel hier: https://www.openstreetmap.org/edit?way=998677279#map=18/41.72138/26.33138 (Maxar/Bing imagery) --SLMapper1 (talk) 11:51, 11 February 2022 (UTC)

vehicle=no zusammen mit hgv=yes sollte das sein Dex2000 (talk) 12:47, 11 February 2022 (UTC)

Besser Parking:lane?

Die Dokumentation gibt an, dass man besser parking:lane benutzen sollte, statt Parkspuren als Fläche einzutragen. Ist das nur die Privatmeinung des Autors oder gibt es dafür einen Konsens? Discostu36 (talk) 12:44, 4 November 2022 (UTC)

Meiner Wahrnehmung nach ist das im Allgemeinen relativ konsensfähig (außer bei Parkbuchten), im Speziellen gibt es aber genügend Gründe, auch mal Flächen zu nutzen. Das Proposal des neuen Straßenparken-Schemas geht darauf am Rande ein: "...in the case of complex geometries (e.g. frequently separated street-side parking bays) or frequent changes in the physical or legal characteristics of the parking areas, it can be preferable to record this information separately...". --Supaplex030 (talk) 19:36, 6 November 2022 (UTC)

Das Zitat bezieht sich aber auf street_side, nicht lane, oder? Discostu36 (talk) 21:41, 6 November 2022 (UTC)

Nein, auf "separately mapped parking spaces and areas" im Allgemeinen. Also z.B. wenn sich die Eigenschaften eines "Parkbereichs" (Parkstreifen oder Parkbucht) häufig oder für einen kurzen Abschnitt ändern. Beispiel: einzeln markierte Stellplätze, z.B. für Menschen mit Behinderungen. Oder "Bündel" von Stellplätzen, mal auf der einen, mal auf der anderen Straßenseite – das wären dann komplexe oder fragmentierte Geometrien, was auch bei Parkbuchten (also street_side) oft der Fall ist – daher eignen sie sich eher zum separat mappen.

Das heißt natürlich alles nicht, dass man nicht dennoch alles andere auch separat mappen kann – das scheint mir dann nur nicht mehr im Rahmen des allgemeinen Konsens zu sein ;) Es scheint Mapper zu geben, die das tun. Ich kenne aber keine Community-Diskussionen z.B. zur Abwägung von Vor- und Nachteilen, was ja ein Beitrag zur Verschiebung eines Community-Standpunkts sein könnte. Einen zwingenden Grund, der dagegen spricht, ist mir nicht bekannt. In mir bekannten Auseinandersetzungen kamen eher "ästhetische" Vorbehalte zum Tragen ("Die Karte nicht mit P-Symbolen vollkleckern" – als Argument eher ungültig).

Apropos: Vielleicht hast du kürzlich diese Änderungsdiskussion im EN-Wiki gesehen – der englische Artikel zu parking=lane könnte ein Ort sein, solche Debatten zu sammeln oder auszutragen. --Supaplex030 (talk) 22:12, 6 November 2022 (UTC)