Offensichtlich recht viele, sonst gäbe es ja hier keine Diskussion
Ja. Weil auch das legitime Interessen hast. Es gibt genug Leute, vielleicht gar mehr als solche, die Behindertenparkplätze suchen, die Briefkästen und Fastfood-Restaurants suchen. Und es ist nun mal weder deine noch sonst jemandes Aufgabe, zu beurteilen, ob das mehr oder weniger wichtig ist als ein Behindertenparkplatz. Deshalb muss jeder Kartenersteller entscheiden, was er für wichtig hält. Und wenn er eben keine Behindertenparkplätze anzeigen will, dann muss er das doch nicht tun, oder?
Das kann alles durchaus sein. Aber die Lösung ist einfach: Schreibe die Entwickler dieser Karte an und bitte um Aufnahme. Oder frage bei der wheelmap nach, ob sie eine garmin Karte erstellen wollen. Oder mach selbst eine. Aber lass die Tags dafür, wofür sie sind. Sonst hat das ungeahnte Auswirkungen. Z.B.: Ich fahre mit meinem Navi durch Augsburg und suche Parkplätze. Ich kann aber die Parkhäuser (nach Namen) nicht finden, denn leider tauchen in der Liste hunderte benannte Parkplätze auf, dich ich nichtmal benutzen darf.
@ Rainer
Daß Du Dich von mir als persönlich beschimpft ansiehst, wundert mich sehr.
Ich habe eine allgemein gültige Feststellung gemacht und darauf hingewiesen, daß der Mißbrauch des Name-Tags immer wieder in unterschiedlichsten Konstellationen auftaucht und meine Meinung über diesen nervenden Mißstand geäußert, ohne jemanden persönlich anzugreifen.
Ein Wheelmap-Garmin-Karte kann mit ein wenig Geduld mit Hilfe des Map-Composers von Nop erstellt werden.
Voraussetzung: ein klares Tag-System, das ermöglicht, die für Behinderte relevanten Einrichtungen hervorzuheben.
Ein Symbol für Behindertenparkplätze ist leicht erstellt.
Man lädt eine Grafik des üblichen Schildes aus dem www herunter und integriert es leicht modifiziert in die Composer-Symbole-Sammlung.
Wenn nun der Behinderten-Parkplatz als Fläche mit einem besonderen access-Vermerk eingetragen wird (access=private ist zu allgemein und daher ungeeignet) ist es möglich, im Map-Composer eine Renderregel zu erstellen, die auf so einer Fläche einen Node in Gestalt des Behindertenparkplatzschildes anzeigt, ohne daß dort in OSM ein Node eingetragen wurde.
Zusätzlich ist es möglich, eine Renderregel zu erstellen, die dafür sorgt, den Wert eines bestimmten Tags bei Bedarf als Name anzuzeigen.
Ich hab da jetzt gerade keine Idee für ein konkretes Beispiel.
Oder doch?
Parkausweis=PAnn (PA=Parkausweis / nn=Nummer) (“Parkausweis” durch ein englisches Wort ersetzen.)
Wenn das ein wichtiger Hinweis ist, der angezeigt werden soll, dann bestimmt man in den Renderregeln, daß für den Fall, daß amenity=parking + access= ?? der Wert von Parkausweis als Name angezeigt werden soll, bzw an den Wert des Name-Tags angehängt werden soll.
Da solche Parkplätze auch baulich breiter und fast auf jeden Parkplatz integriert sind sollte diese Fläche extra aufgenommen werden.
Gruß Gerd
EDIT: Parkplätze mit Parkausweisen (und Nummern; auch wenn er noch mit Behindertenschild ausgewiesen wird) würde ich mit = privat taggen, auf keinen Fall mit = wheelchair - da er ja nicht allgemein für “wheelchair” nutzbar ist.
Nope, die Parkausweisnummer gilt in diesem speziellen Falle ja nur von 8 bis 19 Uhr (“Anwohnerparkplatz”), in der übrigen Zeit steht er für alle Autofahrer mit Behindertenausweis zur Verfügung.
amenity=parking_space oder ein anderer Wert, der sich vom für den gesamten Parkplatz genutzten Schlüssel/Wert amenity=parking unterscheidet ist zu mE zu bevorzugen. Das erleichtert die Erstellung von Renderregeln.
access=wheelchair
finde ich gut. Dürfen solche Parkplätze auch von Behinderten benutzt werden, die ohne Rollstuhl unterwegs sind? Oder gibt es da Unterscheidungen?
Nur zeitweilige allgemeine Nutzung: Das kann man doch bestimmt durch eine Art “Öffnungszeiten-Tag” ausgedrücken.
access=wheelchair finde ich nicht gut, weil der access=wheelchair tag meines erachtens heißt, dass man auch im Rollstuhl da hinkommt.
und behindertenparkplätze sind nicht nur für rollstuhlfahrer.
Ok, das ist einleuchtend.
Der Begriff “disabled” ist allerdings sehr vieldeutig.
Warum nimmt man da nichts eindeutigeres?
access=hindered_people
oder
access=handicapped_people
das ist keine gute lösung. was kommt dann als nächstes? “parent_parking_space”, “woman_parking_space”, “customer_parking_space” usw? parking_space beschreibt ist erster linie die physische präsenz einer fahrzeugstellfläche. access rights sind ein eigenes kapitel und die tags dafür sollten so allgemein sein, dass sie sich auf diverse unterschiedliche elemente anwenden lassen. mein vorschlag wie man “transportation modes” und “roles” unter einen hut bekommt findest du hier.
wheelcair ist aber auch das Zeichen für einen “Behinderten-Parkplatz” (auch in England, Skandinavien …). So einen (EXTRA-)Ausweis erhalten nur Menschen mit Behinderung, die außerordentlich GEHBEHINDERT sind - http://de.wikipedia.org/wiki/Schwerbehindertenausweis
Ich bin manchmal mit einen ehemaligen Arbeitskollegen (Halbseitenlähmung) unterwegs, und da wäre es m.E. sinnvoll zu wissen, wo ein Parkplatz in entsprechender Nähe ist. Bei einem Einkaufszentrum ist es nicht so schlimm, da sind immer solche Parkplätze. Aber bei POI wäre es manchmal wünschenswert.
Beispiel: Frauenkirche in Dresden: Es gibt mehrer Parkplätze in unmittelbarer Nähe, um einen Besuch der Kirche zu ermöglichen. Fahrradparkplatz und Parkhaus sind da. Also fahre ich ins Parkhaus (Tiefgarage) von da mit Rollstuhl über den Lift zur Frauenkirche, um unterwegs zu sehen, dort ist ein Behindertenparkplatz, von wo aus wir direkt zur Kirche hätten laufen können.
BITTE: Also bitte (irgendeine allgemeine) Regelung. Warum? - http://www.behindertenparkplatz.de/faq-behindertenparkplatz/
Fahrradparkplätze (amenity=bicycle parking) sind doch auch vorhanden. Warum nicht auch amenity=handicapped_parking_space, da es sich um einzelne Stellflächen handelt.
Ich nutze erst mal wheelcair=* , wie bei Toiletten und anderen öffentlichen Zugängen.
größer ist die Chance, daß es eine breite Verwendung findet
weniger Fehler entstehen beim Rendern und Taggen.
Ein Behindertenparkplatz ist eine klar umrissene Fläche.
Diese Fläche ist meiner Erfahrung nach für keine weitere Nutzung vorgesehen.
Ihre Position sollte so genau wie möglich erfaßt werden.
Das Taggingschema sollte so angelegt sein, daß es ohne umständliche Bedingungskombinationen gerendert werden kann.
Das Taggingschema
amenity=handicapped_parking_space|parent_parking_space|women_parking_space etc.
ist eindeutig und verhindert jede Verwechslung.
Unerfahrenen Kartenbastlern, die sich beispielsweise mit MapComposer eine wheelmap-Karte bauen wollen, erspart es die Erstellung komplexer Renderregeln. Ich würde es in jedem Fall bevorzugen. Denn so ein einfaches Schema ist leichter zu übersehen, leichter vermittelbar und kann sehr schnell eingegeben werden.
Ich würde so ein Schema beim Erfassen einzelner Stellplätze oder geschlossener Stellplatzgruppen mit Sonderfunktion, die sich innerhalb eines großen Parkplatzes befinden, bevorzugen. Es läßt sich problemlos auf jede andere Einrichtung übertragen, die ausschließlich Behinderten vorbehalten ist.
Für Einrichtungen, die allgemein zur Verfügung stehen und zusätzlich behindertengerecht gestaltet sind, ist dieses Schema nicht (!) gedacht. Dafür gibt es ja bereits das System *=yes .
tippeltappel, wenn der Composer in dieser Richtung Beschränkungen aufweist oder unkomfortabel ist, dann sollte das im Composer gelöst werden und nicht ein etabliertes Schema geändert werden. Und wenn dem Ersteller des Editors die Eingabe von zwei Tags zu komplex erscheint, kann er eine Vorlage erstellen, sodass der Benutzer nur noch Behindertenparkplatz angeben muss und der Editor dann die nötigen Taggs automatisch setzt.
Das Schema bei OSM ist allgemeine Obertaggs die die Objekte grob gliedern und dann weitere Feinheiten durch weitere Taggs unterscheiden. Ein Mutter-Kind-Parkplatz oder ein Behindertenparkplatz ist nun mal ein Parkplatz für ein Auto, der besondere Eigenschaften hat. Eine Abstellmöglichkeit für ein Fahrrad ist aber kein Parkplatz für ein Auto.
Im Composer sehe ich kein Problem. Ich selbst habe auch kein Problem, kombinierte Bedingungen zu erstellen. Weiter oben habe ich so ein System ja selbst vorgeschlagen. Es war nur eine Überlegung, ob man die Erfassung und damit auch das Rendern vereinfachen könnte.
und wie weit willst du das dann treiben? wie wäre es zB mit customer_parking_space, visitor_parking_space, resident_parking_space?
was, wenn der behindertenparkplatz für bewohner eines mietshauses ist? resident_disabled_parking_space??? oder wie wäre es mit dem hier: volvo_parking_space
sorry, aber das access schema hat schon einen sinn. durch die modulhafte gestaltung der taging-schemen muss nicht jedes mal das rad neu erfunden werden, speziell im parkplatzbereich wo es unzählige “zielgruppen” gibt.
hier schreibt Raul von der wheelmap.
Wir haben uns das nochmal angesehen und werden als Nächstes den “Namenszwang” für Parkplätze herausnehmen. Würde das helfen?
Ja, unbedingt. Das gleiche bitte auch für Toiletten. Und möglicherweise auch für bestimmte shop-Kategorien: Ein Supermarkt hat immer einen “richtigen” Namen, ein Kiosk nicht unbedingt.
Wäre es möglich, bei Parkplätzen automatisch nach capacity:disabled zu fragen? (Ohne Zwang, aber als nächstes sinnvolles Merkmal.)
Warum habt ihr überhaupt einen Namen-Zwang? Klar ist es wünschenswert, wenn man einen vorhandenen Namen mit eingibt, aber den Zwang verstehe ich nicht.
