Behindertenparkplätze, name-Tag

Jaaa! Fänd ich gut. Und bitte auch nach capacity allgemein. Sonst weiß man gar nicht, ob es sich um einen reinen Behindertenparkplatz handelt oder nicht. Das blaue P in der Mapnik-Karte sollte eigentlich nur dann angezeigt werden, wenn es sich um einen “normalen” Parkplatz handelt - egal ob mit oder ohne Behindertenstellflächen (mittelfristig würde ich mir für Mapnik unterschiedliche Symbole wünschen für wheelchair=yes und no).

Aber ein einzelner Behindertenstellplatz sollte auf der Mapnik-Karte nicht als blaues P erscheinen. Dafür gibts ja inzwischen amenity=parking_space, das die Wheelmap hoffentlich ebenfalls auswertet…

das wird echt komplex und wir haben nur wenig entwicklerpower… vielleicht sollten wir parkplätze ganz rausnehmen.

Das wär echt schade. :frowning:

Eigentlich sollte das mit einer kleinen Anpassung der SQL-Abfrage erledigt sein. Ist der Code Open Source? Wenn ja, wo gehostet?

Mangelnde Verfügbarkeit von Entwicklern entschuldigt Abweichungen von geltenden Konventionen nicht. Da könnt ja jeder kommen und irgendwas zusammenbasteln, seine Einträge in die Datenbank schreiben und sich darauf berufen, dass er mehr grad nicht leisten kann. Da ist vielleicht jetzt etwas überzogen, aber so in etwa seh ich das. Das mal so als Rückmeldung, kannst Du nun mit umgehen wie Du willst. Ich hab auch ein paar Ideen die ich mal schnell umsetzen kann, aber aus Rücksicht auf die Datenbank mach ich das nicht. Wenn das so weitergeht dass jeder macht was er will wird sich das auch noch ändern.

Hallo Alle,
wir nehmen das “Parking”-Tag jetzt mal raus, bis wir technisch eine Lösung gefunden haben. Selbst auf der höchsten Zoomstufe kann man auf der Web- und iPhoneansicht bei uns keine Parkingspaces einzeichnen, ohne dass es den Nutzer überfordert bzw. Probleme mit der Datenbank macht. Wir entschuldigen uns für die aufgekommenen Frustrationen.

Hmmmmm - grübel
In OSM gibt es doch die “Spielregel”, daß Flächen (auch Parkplätze) immer dann, wenn sie aus irgendwelchen Gründen nicht als Fläche erfaßt werden können, mit einem Node angedeutet werden.
Was spricht dagegen, einen Behinderten-Parkplatz als Node einzutragen? Wäre das mit der wheelmap-Anwendung leistbar?
Erfahrene OSM-Mapper können diese Nodes in JOSM filtern und - falls Satellitenbilder mit ausreichender Auflösung vorhanden sind - nachträglich die Fläche eintragen.

Vielleicht mag ja mal jemand für ratsuchende stille Mitleser übersichtlich zusammenfassen, welche Schlüssel=Wert-Kombination an so einen Node gehören.

amenity=parking_space
acces=
.
.
erfahrene Mapper ergänzen vielleicht noch:
note=wenn die entsprechende Fläche eingetragen wird, diesen Node löschen und die Eigenschaften an die Fläche hängen

Genausogut könnte ich mir vorstellen, es bei den Nodes zu belassen. Aber das sehen einige sicherlich ganz anders.

Es gibt im wiki ausführliche Erläuterungen für das Gesamtsystem (Parkplatz, Parkhaus, Parkbuchten etc.) . Da durchzusteigen ist für so manchen Gelegenheitsmapper vermutlich zu kompliziert. Viele benötigen Vorlagen, die sie 1:1 übernehmen können. Wer mit der Kugel sucht, erhält im Moment dieses Ergebnis: http://www.google.de/search?q=osm+Behindertenparkplatz&ie=utf-8&oe=utf-8&aq=t&rls=de.web:de:official&client=firefox

An 2. Stelle der Ergebnisliste:
http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dparking

Mag jemand diese Wiki-Seite mit Beispielen ergänzen?

Gruß
tippeltappel

oder den node ggf. verschieben und als Punkt in den Umriss für die Fläche aufnehmen. Dann bleibt uns die Historie. Ich mach das (meistens) so bei Gebäuden usw…

Tja, selten was klügeres gelesen!! Man merkt jetzt dass es leichter ist, sich über etwas aufzuregen, als vorher nachzusehen wie so was gemacht wurde. Was glaubst du denn wie man die Plätze erfasst???

Ich habe bisher alle Behindertenplätze mit dem GPS angefahren und mittels Merkaartor mit amenity=parking und wheelchair=yes oder limited, die einzeln stehen, als Node erfasst. Seit einiger Zeit wurde es auch möglich Flächen zu erfassen.
Wenn allerdings Parkplätze innerhalb einer Parkfläche standen (Supermarkt etc.), wurde deswegen ein zusätzliches P mit angezeigt. Auch dies störte einige Leute! Deswegen hab ich diese Einträge zu
amenity=parking_space
umgewandelt. Das Ergebnis wird bisher leider nirgends angezeigt, weder bei OSM noch bei wheelmap.org.

Das, und nur das war bisher mein Grund, die Behindertenplätze mit dem tag name=xyz zu versehen.
Es ist traurig, dass diese ganze sinnlose Diskussion dazu führt, dass wheelmap.org die Parkplätze rausnimmt. Jetzt hat die Seite nur noch den halben Wert!!
Und gewonnen haben nur die Berufsmeckerer hier!!

@tippteltappel wir tragen momentan die parkplätze (amenity:parking) als nodes ein. aber offenbar ist das nicht so gern gesehen.

Das Problem an der Sache ist, dass unter amenity=parking ein Parkplatz verstanden wird und kein einzelner Stellplatz. Für einen einzelnen Stellplatz gibt es andere Tags. Zudem ist ein einfaches wheelchair=yes nicht ausreichend, weil der Parkplatz/Stellplatz eben nur von Behinderten genutzt werden darf. Ergo müsste man ein access=no und wheelchair=yes taggen.
Die Diskussion ist auch nicht sinnlos. Der name-Tag hat eine bestimmte Bedeutung und nach dieser Bedeutung wird er ausgewertet. Der Tag dient aber nicht dazu, dass jeder das auf eine Karte bringt, was ihm wichtig ist. Anstatt diesen Beitrag zu schreiben, hättest du den Leuten von wheelmap auhc schrieben können, dass sie in ihrer Auswertung amenity=parking_space mit ausnehmen sollen.

Das find ich persönlich voll ok. Was natürlich nicht gewünscht ist, ist Doppel-Tagging. Beispiel:
Ein Mapper möchte 5 Behindertenparkplätze detaillierter taggen und trägt sie als Fläche ein. Diese Fläche wird bei Wheelmap nicht dargestellt, weil die dortigen technischen Probleme seit längerer Zeit nicht gelöst sind. Das stört einen anderen Mapper, weil er ja gern seinen Parkplatz auch “sehen” will, und deswegen trägt er dort zusätzlich einen Node ein.

Das Ergebnis sind zwei unterschiedliche Objekte, zu denen z.B. auch getrennt geroutet wird. Deswegen ist diese Art zu taggen grundsätzlich nicht gewünscht. Die Lösung bestünde in einer Ergänzung der Wheelmap-Software. Das ist leider wegen der derzeit eingesetzten Datenbank (eben keine PostgreSQL) ein größeres Problem. Eine echte Kleinigkeit wäre aus meiner Sicht, auch “parking_space” zuzulassen.

So kann man es sagen. Im Prinzip müsst ihr euren Editor so erweitern, dass er zwischen Parkplatz und Stellplatz unterscheidet und generell den Zwang, ein name-Tag zu setzen rausnehmen.
Bei dem access-Tags müsstet ihr unterscheiden zwischen kann von Rollstuhlfahrern genutzt werden ( wheelchair=yes ) und darf nur von Rollstuhlfahrern genutzt werden ( access=no und wheelchair=yes ).

@aighes: wir werden den namezwang und die parkplätze rausnehmen. Denn die nutzer der wheelmap sind keine OSM-Profis und werden den Unterschied zwischen den Parkplatztypen nicht verstehen. D.h. er wird wahrscheinlich auch keine Flächen einzeichnen können…

Ob Fläche oder Punkt ist egal. Sicherlich wäre eine Fläche besser, aber nicht erforderlich. Sollte aber nicht beides vorhanden sein :wink:

Meinst du wirklich, dass eure Nutzer nicht den Unterschied zwischen Parkplatz und einzelnem Stellplatz verstehen? Kann ich mir ehrlich gesagt nicht vorstellen. Es wäre dann halt sinnvoll, wenn ihr beides auswertet, sodass der Nutzer auch bei einem Stellplatz sein Symbol bekommt und nicht wegen dem Symbol etwas anderes eintragen muss.

Zu dem access: Auch hier ist das recht einfach und verständlich umsetzbar. 3 Radiobuttons einer mit dem Text “rollstuhlgeeignet”, der zweite “darf nur von Rollstuhlfahrern genutzt werden” und der letzte “nicht rollstuhlgeeignet”

Evtl. fällt euch für den zweiten auch noch etwas kürzeres ein.

Da scheint mir ein Mißverständnis vorzuliegen.

Wie Dir die anderen Posts bereits bestätigten, ist das Eintragen von Nodes ok, solange das Objekt nicht bereits als Fläche existiert. Die Nodes können bei der Weiterbearbeitung der Daten gelöscht oder zum Erhalt der History in die Fläche eingebunden werden. An letzteres hatte ich nicht gedacht. Gute Idee. Bei der Weiterbearbeitung müssen die Tags natürlich vom Node auf den Way übertragen werden, also vom Node entfernt werden. Sonst kommt es zu Doppelanzeigen.

Zu den unerwünschten Mehrfachanzeigen kommt es auch, wenn nicht unterschieden wird zwischen amenity=parking und amenity=parking_space.

Wenn die Unterscheidung zwischen Parkplatz und einzelner Stellplatz in die Wheelmap-Software eingebaut ist und die Namensangabe ausschließlich beim Parkplatz und nicht beim Einzelstellplatz abgerufen wird, sollte sich dieser Fehler doch reduzieren lassen.

Oder?

Gruß
tippeltappel

EDIT
Ich kann mir nicht vorstellen, daß der Unterschied zwischen kompletten Parkplatz und einzelner Stellplatz nicht verstanden wird.

bis jetzt ist “wheelchair” immer so genutzt worden, dass damit das physische fortbewegungsmittel gemeint war. die einzige spezialbehandlung war der wert “limited” der dem key zugewiesen werden kann. ansonsten sind die access regeln die gleichen wie für alle anderen “transportation modes” auch.

ein wheelchair=yes bei einem klo oder einem restaurant bedeutet, dass man mit einem rollstuhl physisch rein kann. ein wheelchair=no auf einen highway=path, bedeutet, dass man auf einen (trampel)pfad mit einem rollstuhl nicht weiterkommt. “wheelchair” auf einen parkplatzstellplatz gemappt ist einfach falsch, weil man nicht mit dem rollstuhl drauf parkt, sondern weiterhin mit einem auto. access=no + wheelchair=yes würde demnach bedeuten, dass es ein stellplatz für einen rollstuhl, aber nicht für einen pkw wäre. bitte dreht die bedeutung der access tags nicht bei jedem element um wie ihr lust und laune habt, sonst wird es hier niemals eine saubere auswertung von access tags geben. benutzt lieber ein access:disabled=designated um zu signalisieren, dass es sich um einen autoparkplatz speziell für rollstuhlfahrer handelt (so wie auch im proposal für amenity=parking_space vermerkt).

beispiel eines kundenparkplatzes der stellflächen für behinderte und eltern hat:

Hab ich das irgendwo auf Parkplätze bezogen? Ich denke nicht. Da wäre wheelchair auch eher falsch, weil die Plätze ja allgemein für Leute mit Behinderungen gedacht sind und nicht nur für Leute mit Rollstuhl. Ich hab da irgendwas wie capacity:disabled= im Hinterkopf, kann aber auch falsch sein.

Ich hab mich mit der Materie nicht so detailliert beschäftigt, ich könnte mir aber vorstellen, dass es durchaus Orte gibt, die nur von Rollstuhlfahrer genutzt werden sollen.

Wo ich so drüber nachdenke fällt mir spontan ein, dass die Bank meines geringsten Misstrauens neben ihren Eingangsstufen einen Lift hat, der nur für Rollstuhlfahrer gedacht ist.

Ich habe mal geschaut.
Hier wird amenity=parking_space verwendet. Auch für den Fahrrad-Parkplatz. Aber auf der Karte werden überhaupt keine Parkplätze angezeigt.

Wie kann ich einen “Parkplatz - Nur für Behinderte” auch angezeigt bekommen?

Darum geht es auch bei Wheelmap. Deshalb nutzen sie die notes, ist für sie die “richtige” Methode. Durch osm-user könne diese auch in Flächen (amenity=parking_space) umgewandelt werden, mit den notes, damit Wheelmap sie auch weiternutzen kann. OSM müsste aber auch das anzeigen: “Parkplatz - Nur für Behinderte”. Warum geht es bei den “Fahrrad-Parkplätzen” so einfach?

indem du deine eigene karte renderst oder die mapnik-macher überzeugst das auf der slippy-map zu rendern.

und die wheelmap müsste eben auch einfach die vorhandenen tags als behindertenparkplatz rendern