http://osmand.net/go?lat=50.81179&lon=6.97578&z=19
Diese Parkplätze werden doch mit
https://wiki.openstreetmap.org/wiki/DE:Key:parking:lane
eingetragen und nicht mit
Die Unterscheidung und Diskussion über richtig oder falsch würde ich nicht führen.
Das Problem hier, wie auch bei vielen anderen Sachen, parking:lane ist halt auf Grund der fehlenden Visualisierung (außer in JOSM, und ehemals parkinglane auf openstreetmap.de) einfach nicht Populär genug, letztendlich ist es aber auch ein Henne-Ei-Problem.
Die Polygon-Darstellung von Parkflächen ist einfach leistungsfähiger bzw. genauer.
So haben Parkbuchten häufig einen anderen surface als die Fahrbahn,
oft alternieren Parkplätze mit Straßenbegleitgrün wie Bäumen,
mitunter liegt zwischen Fahrbahn und Parkfläche ein Rad- oder Fußweg,
oder ein derartiger Weg verspringt auf der fahrbahnabgewandten Seite um eine Parkbucht … usw.
Wenn man ernsthaft kleinmaßstäblich arbeitet zeichnet man Parkflächen,
die sich von der Fahrbahn absetzten,
auch als Flächen ein, die sich von der Fahrbahn absetzen - ganz einfach.
Meine Fresse, wer hat die Seite denn geschrieben? Das ist nicht nur furchtbar getextet, da hat auch einer noch nicht verstanden, was mit :forward bzw. :backward gemeint ist.
–ks
Dann schreib uns doch mal, was du denkst, dass derjenige NICHT verstanden hätte? Weil aktuell verstehe ich deinen Einwand nicht. Der Verfasser hat doch plausibel dazu geschrieben, warum nicht forward/backward sondern left/right… und hat das sogar noch verlinkt
Richtig ist, dass :left und :right in diesem Fall einzig sinnvoll sind.
Falsch ist, dass sich :forward und :backward auf die Fahrtrichtung bezögen – noch untermauert durch die Behauptung, dass :backward in einer Einbahnstraße überhaupt keinen Sinn ergäbe. (Gegenbeispiel: Einbahnstraße als oneway=-1 getaggt, dann ergibt nur :backward einen Sinn.)
–ks
ohne jetzt zu offtopic zu werden
Macht es ja eigentlich auch nicht, wenn man endlich mal den englischen Abschnitt, der eindeutig oneway=yes mit der korrekten “Wegrichtung” empfiehlt auch ins deutsche bringen würde.
Aber zurück zum eigentlich Thema: beides ist definitiv kooexsistent, das eine (parking:lane) ist eher wie highway abstrakter Natur, parking-Flächen analog zu area:highway dann eben für Micro-/Detailmappings
Dann einmal auf diesen Note klicken:
http://osm.org/go/0NGAY2p98–?layers=N
Wenn sich jemand vor Ort für "eine “Mappingart” entscheidet, sollte man es auch akzeptieren.
Mir ging es vor Jahren so - da wurde auf die parking:lane=* verwiesen. Wenn man aber sieht, was und wie viele Schlüssel heute an einem hw hängen, ist mir das auch etwas zu abstrakt (- und trotzdem mache ich es “teilweise” so …).
Ja, da sieht man gut, wie erst die Parkflächen-Darstellung die räumliche Situation (Standort des Straßenbegleitgrüns, Lage der Fußwege) klärt und erfahrbar macht - schwer vorstellbar, vergleichbares durch Straßentagging zu erreichen.
Erschreckend (nicht nur aus Sicht des Mappers der vor 3 Jahren die Arbeit investierte) ist die Reaktion des Publikums:
Der Erste will gleich wieder abreißen, der Zweite macht sich lustig und offenbart dabei nur, dass er sich mit der Arbeit des Mappers gar nicht beschäftigt hat: Dieser hatte die capacity der Flächen nämlich schon 2 Jahre vorher eingetragen.
Generell gibt es einen zunehmenden Trend zum immer genaueren Mapping (das muss noch nicht mal Micromapping i.e.S. sein). Das hat auch einfach mit den besseren Luftbildern u.a. Quellen zu tun. Während „früher“ parking:lane=* sicher mehr als ausreichend war, kann es heute, da mehr und mehr auch Straßenbäume, Straßenlaternen, Mülleimer u.a. Details im Straßenraum gemappt werden, durchaus sinnvoll sein, straßenbegleitende Parkflächen als Flächen zu mappen. Das ist doch etwas Ähnliches wie die Gehsteige/Bürgersteige/Trottoirs: Manche halten die Wiedergabe durch Tags an der Straße immer noch das Beste, aber auch das separate Mapping mit eigenen highway=footway, footway=sidewalk hat seine Vorteile.
Also lassen wir doch den Dogmatismus in der Schublade! Es gibt, wie so oft in OSM, keine „reine Lehre“, an die sich alle halten müssten; und auch was im Wiki steht und was nicht, ist nur von Menschen geschrieben. Am besten lassen wir in allen diesen Fällen beide Möglichkeiten zu. Wichtig sind doch nur zwei Dinge:
-
Wie auch immer man es macht, es muss richtig gemacht sein – z.B. sollte bei separatem Mapping der Bürgersteige das Zusatztag footway=sidewalk nicht fehlen, das erlaubt es den Renderern, Bürgersteige wegzulassen bzw. erst in höheren Zoomstufen darzustellen. (1)
-
Entlang einer Straße, noch besser: innerhalb eines Wohngebietes oder Viertels sollte am besten jeweils nur eine der Möglichkeiten konsequent angewendet werden. Wenn man Parkflächen mit parking:lane=* und separat gemappt einträgt, oder beides direkt nebeneinander abwechselnd, verwirrt das nicht nur andere Mapper, sondern macht auch den Datenauswertern das Leben unnötig schwer; am Ende werden die Parkflächen dann vielleicht doppelt gezählt.
Genau das – Streit und gegenseitiges Löschen – sollte es nicht geben.
(1) Ob die Renderer bzw. Kartenstile das wirklich endlich mal umsetzen, ist nicht mein Problem, dafür bitte an die Betreuer der Renderer und Kartenstile wenden. 
Und was ist, wenn man nach einen Parkplatz sucht, z.B. in OsmAnd~ (bietet es an, wenn man am Ziel angekommen ist) und an jeder Straße entlang ist ein Parkplatz eingetragen und die werden alle als Möglichkeit angezeigt? Dann ist die Funktion nicht mehr hilfreich. Daher sehe ich es nicht zielführend, straßenbegleitende Parkflächen als Parkplatz einzutragen. Man darf nicht nur an die grafische Darstellung denken, sondern muss auch an Anwendungen denken und was die Folgen davon sind. Abgesehen davon wird es auch auf einer Karte nicht hilfreich und übersichtlich sein, wenn neben den meisten Straßen Parkflächen gerendert werden. Vielleicht ist das der Grund, warum parking:lane=* nicht dargestellt wird.
Mit fortschreitendem Microtagging werden Applikationen lernen müssen zu generalisieren.
Edit: Quote gekürzt
Wie wäre es, wie schon wohl teilweise gemacht, straßenbegleitende Parkplätze nicht mit dem Tag für große Parkplätze (amenity=parking) zu taggen, sondern mit amenity=parking_lane? Das kann ja auch auf Karten dargestellt werden, aber das von mir in Post #11 beschriebene Problem würde man damit lösen.
Tordanik hat dazu etwas passendes geschrieben:
https://forum.openstreetmap.org/viewtopic.php?pid=639433#p639433
Naja, Tordanik schrieb dass man das eben nicht machen sollte, da zB GIS Auswertungen wie “wieviel Prozent der Wohnstraßen haben Parkstreifen” viel schwieriger sind.
Mappen wir für
Wir sollten uns an Daten wie sie vor Ort zu finden sind orientieren - Spezialfälle abstrahieren können die Auswerter.
+1
Ich möchte auch noch auf die dazugekommen “Detail-Erweiterungen” an den highways selbst hinweisen z.B. lanes, surface, width, …
Ist die Auswertung von OSM-Daten nicht schon kompliziert genug? Man kann nicht unendlich viel Magie und Glaskugellesen in die Auswerter stecken. https://www.openstreetmap.org/way/463858784 ist als normaler Parkplatz getaggt, woher soll der Auswerter wissen dass es sich um einen straßenbegleitenden Parkplatz handelt? Nur weil er parallel zu einer Straße verläuft? Das kann auch bei einem regulären Parkplatz der Fall sein. Ein Renderer hat das gleiche Problem. Würden wir alle straßenbegleitenden Parkplätze als amenity=parking einzeichnen dann würde die Karte aus lauter Ps bestehen.
Ich finde die Geometrie bei straßenbegleitenden Parkplätzen äußerst uninteressant. Daher bin ich dafür, diese mittels parking:lane einzutragen. Auch das Argument über die Oberflächenbeschaffenheit greift hier nicht, diese könnte man beispielsweise via parking:surface:both bzw. left/right eintragen. Das wäre analog zu sidewalk und cycleway, würde also zu den restlichen Daten passen.
OpenStreetMap soll eine Karte für möglichst viele sein. Daher müssen wir immer sowohl die Editierbarkeit/Verständlichkeit als auch die Auswertbarkeit der Daten im Auge behalten. Es nützt nichts eine Karte zu haben die sich leicht editieren lässt aber schlecht auswertbar ist. Andersherum nützt eine schwer zu editierende Karte natürlich auch niemandem.
Wie sollen die straßenbegleitenden Parkflächen denn jetzt taggt werden, wenn man sie als Fläche mappen will?
Ich habe sie in meiner Stadt vor kurzem von amenity=parking zu amenity=parking_lane umgetaggt. Eine andere Möglichkeit wäre amenity=parking & parking=lane. parking=lane scheint wesentlich populärer zu sein als amenity=parking_lane.
http://files.homepagemodules.de/b563523/pictures_u1056_TYuhNgsE.jpg
- sehe ich den Parkplatz (als amenity=parking) nicht richtig (detailiert) gemappt. Er verläuft direkt an der Straße (und wie es aussieht auch linksseitig der Straße).
Also müsste der rechte
amenity=parking
parking=lane
lane=perpendicular
…
und der linke
amenity=parking
parking=lane
lane=parallel
…
sein. Wichtig ist m.E. auch noch das access=* und eventuell Zeitbegrenzung.
-
Könnte es eine amenity=parking_lane sein,** WENN** das eben dann auf der “Karte” erscheint - entweder kein Parkplatz oder alle Parkplätze. Und Parkräume sind heute innerstädtisch ein Problem. Da bin ich froh, wenn ich einen Parkplatz auf der Nebenstraße finde (ob straßenbegleitend oder extra), der ordentlich als begrenzter Zeit-Parkplatz oder privat (Anwohner) ausgewiesen ist.
-
Ich bin für die detaillierte Version 1 (habe aber selbst auch welche als amenity=parking_lane. eingetragen). Am hw sollten die Tags, die die Straße betreffen und das sind nicht wenige (bei detaillierter Erfassung).
Danke! Ich bin ja durchaus der Meinung, dass es sich Auswerter nicht zu beqem machen sollten (siehe z.B. meine Meinung zu Gebäuderelationen), aber es gibt eben einen Unterschied zwischen Information, die man mit etwas Aufwand berechnen kann, und Information, die schlicht und einfach nicht in den Daten drin steckt und bestenfalls erraten werden kann.
Man muss auch nicht mal zu statistischen Auswertungen schauen, um Probleme bei der Auswertung zu finden. Beispielsweise definiert das parking:lane-Taggingschema ja auch Tags dafür, ob quer, diagonal oder parallel zur Straße geparkt wird. Um das z.B. fürs Rendering sinnvoll zu nutzen, braucht man aber wieder den Zusammenhang zur zugehörigen Straße.
Die Diskussion um andere Tags für die Flächen geht von daher auch ein bisschen am Kernproblem vorbei. Die Tags können zwar die Information wiedergeben, dass es sich um einen straßenbegleitenden Parkplatz handelt (was schon mal besser ist als ein bloßes amenity=parking), aber welche Straße denn nun begleitet wird, bekommt man allein mit Tags an einer separaten Geometrie nicht ausgedrückt.
Ich bin zwar kein “Auswerter” - aber allein das teilen zweier nodes mit dem hw kann doch als “Bezug” des Platzes zur Straße genutzt werden - z.B. straßenbegleitend zum Südermannweg.
Ist er nicht mit dem hw verbunden sondern über einen Parkplatzweg angeschlossen ist er nicht straßenbegleitend
Wir sollten die Daten eintragen wie in der Wirklichkeit vorhanden. Und da ist der Eckpunkt des Parkplatzes … m vom Schnittpunkt mit der Straße entfernt (und hat somit andere Koordinaten).
Das ist beim taggen an den hw nicht der Fall, weil ich eine Fläche mit einem Tag an einem Way darstellen soll.
Wenn die Straßen als Fläche getaggt werden, wie tragen wir dann die “Parkstreifen-Flächen” ein?