Das Teilen von Nodes würde wohl in der Tat ermöglichen, den Zusammenhang wieder zu ermitteln. Allerdings hatte ich bisher den Eindruck, dass es Ziel des Flächenmappings sei, die Geometrie der Stellplätze so abzubilden, wie sie in der Realität ist. Wenn die Fläche künstlich bis zur Straßenmitte verlängert wird, ist das ja nicht mehr der Fall?
Beim area:highway-Tagging soll die Straßenfläche ja den Way nicht ersetzen, sondern zusätzlich eingetragen werden. So würde ich das auch mit dem Parkstreifen handhaben:
Zum einen gibt es den Straßenway, an dem mit parking:lane und den Subtags die Informationen zum Parkstreifen getaggt werden.
Zusätzlich kann die Straßenfläche als area:highway und innerhalb der Straßenfläche auch noch eine Fläche für den Parkstreifen gemappt werden. Durch die umschließende Straßenfläche ist dann auch die Zuordnung wieder möglich.
Das hieße: Parkstreifenflächen-Mapping ginge nur, wenn auch die Straße schon als Fläche gemappt ist.
Wenn unser Ziel ist, das Flächenmapping und die Semantik unter einen Hut zu bringen, wäre das zumindest mal eine eindeutig auswertbare Lösung, die zudem auch rückwärtskompatibel ist (d.h. man kann die Flächen ignorieren und weiter nur den Way auswerten, ohne dass Information verloren geht). Damit könnte ich mich durchaus anfreunden.
In meiner Stadt sind die straßenbegleitenden Stellflächen oft insofern von der Straße getrennt, dass sie Pflastersteine als Oberfläche haben (statt Asphalt) und durch Baumbeete und Fußgängerüberwege durchschnitten werden. Sie wirken wie Einbuchtungen im Bürgersteig. Ich würde diese Parkflächen nicht als Teil der Straße ansehen.
Weil die Straße als Linie gemappt wird - historisch bedingt. Mappen wir als Straße die Straßenfläche wird ja wiederum abstrahiert die Mittellinie (für Routing?) benötigt.
Was bringe ich den alles unter an der Mittellinie der Straße?
lane, surface, widht, … sind alles keine Liniebeschreibungen sondern die Beschreibung einer “Fläche” - abstrahiert. Mittlerweile wird aber mehr detailliert. Und ich finde das auch gut.
Das ist nun in OSM so, das es “gemischte Daten” gibt. Und wenn jemand eine Straßenzuordnung der Parkstreifen benötigt (warum?) kann er es m.E. aus den “gemischten” Daten ableiten, falls sie “richtig” eingetragen sind.
Ein Problem ist auch immer die Darstellung in Mapnik - welches als Hauptkarte angesehen wird. Ich kann nicht einen Parkplatz anzeigen und einen Parkstreifen nicht.
Liegt aber bspw. auch einfach an den Editoren dass es schwierig ist das zu editieren. Wenn man bspw. in JOSM die einzelnen Tags nach bestimmten Kriterien aufteilen und übersichtlicher anzeigen würde, dann könnte man es auch leichter editieren. Ich lade also ein paar Daten runter und dann lasse ich mir nur die Parkplatz-Tags anzeigen und kann diese dann einfach editieren. Das wäre denke ich auch schone eine große Hilfe.
Das ist eine sehr eingeschränkte Sichtweise. Das berücksichtigt weder das Ziel von OSM noch dass die Daten dargestellt und ausgewertet werden müssen; die Daten sollen ja auch verwendet werden, nicht nur eingetragen.
Wie sinnvoll ist es, Straßenlaternen, Bäume, Mülleimer … einzutragen? OSM hat ja einen Zeck, vor allem eine Karte zu sein, mit der man sich orientieren kann, und die Daten für Routenplaner verwendet werden können. Man sollte nichts machen, was kontraproduktiv ist. OSM ist nicht einfach dafür da, ALLES bis auf das letzte Detail einzutragen. Es soll keine detailgetreue Abbildung der Realität sein, eher eine Abstraktion. Man trägt ja nicht jeden Stein eines Weges einzeln ein, sondern den Weg. Bei Straßenlaternen kann man am Weg auch einfach eintragen, dass der Weg beleuchtet ist; zum Orientieren und Navigieren sind die Straßenlaternen nicht wichtig. Möchte man allerdings eine 3D-Darstellung, könnte man die schon anzeigen, also ein Eintrag ist nicht kontraproduktiv, er muss ja nicht auf der Slippy Map dargestellt werden, kann dann aber in einer 3D-Darstellung angezeigt werden.
Wenn alle fünf Meter Mülleimer stehen, wird auch niemand, der einen Mülleimer sucht, erst auf eine OSM-Karte schauen, wo ein Mülleimer steht, sondern einfach den nächsten nehmen, dann braucht man keine Mülleimer einzutragen, ebenso bei Bänken. Allerdings habe ich schon mal in OsmAnd nach einem Mülleimer gesucht, als ich in einem Park keinen gesehen habe und habe dann auch einen eingetragen. Man sollte nicht einfach platt sagen, dass man einträgt, was vorhanden ist.
Daten müssen es auch ermöglichen, dass sie von Programmen verwendet werden, daher muss man sich überlegen, wie man es taggt, so dass es von Programmen möglichst einfach verwendet werden kann, denn je komplizierter, desto länger dauert die Bearbeitung durch die Programme und desto weniger haben Programmierer Lust, das zu berücksichtigen.
Trägt man straßenbegleitende Parkplätze anders als große, eigenständige Parkplätze, können Programme sie unterscheiden und nur bei Bedarf anzeigen.
Das können Programme natürlich auch mit parking:lane=*
Mir ist es egal, ob straßenbegleitende Parkplätze mit parking:lane=* oder amenity=parking_lane eingetragen werden, es sollte nur nicht identisch mit eigenständigen, großen Parkplätzen sein. amenity=parking und parking=lane sind vermutlich beliebter, weil sie dann dargestellt werden (was mappen für den Renderer wäre).
Ich möchte noch mal auf das Problem aufmerksam machen, dass OsmAnd bei Erreichung des Ziels eine Parkplatzliste anzeigt. Wenn an der Straße nun jeder Stellplatz mit amenity=parking einzeln eingetragen ist, sind das sehr viele Parkplätze, welche in der Liste von OsmAnd stehen, welche man dann aus dem Auto auch sowieso direkt sieht. Die Funktion von OsmAnd ist ja sinnvoll, aber sie wird kaputt gemacht, wenn man straßenbegleitende Stellflächen einzeln mit amenity=parking taggt.
Nebenbei:
Man kann auch die Breite der Straße mit width=* angeben, leider kenne ich keine Karte, welche das width=* berücksichtigt.
Und Mapnik ist keine Karte, sondern eine Software, welche verschiedene Karten, die Slippy Maps, generiert:
Auch wenn ich selbst OsmAnd verwende, es ist aber nur EINE Routingsoftware/-app. Und noch steht meines Wissens der Grundsatz, dass wir nicht für Renderer mappen, ich versuche es mal so zu präzisieren: zumindest nicht für die individuellen Bedürfnisse EINES Renderers.
Von daher kann ich dies als Grund nicht akzeptieren (auch wenn ich parking:lane selbst häufig tagge).
Jeder, der die Daten nutzen will, sollte auf >einfache Weise< unterscheiden können, ob es sich um einen Parkplatz handelt (wie auf “klassichen Karten” sichtbar) - oder nur um irgendeine sonstige Abstellmöglichkeit von Autos am Straßenrand. Letztere könnte man dann ja wie einen Parkplatz auf der Hauptkarte gelb darstellen, aber das “P” weglassen. Nicht, weil ich das bräuchte oder schön fände, sondern weil viele letztendlich doch nur für den Renderer mappen
Irgendwie erinnert mich das an den Bedeutungswandel von natural=tree (für vormals landschaftsprägende Bäume, wie sie in topographischen Karten von Bedeutung waren). In OSM-generierten Topo-Karten musste man wieder “bei Null” anfangen und warten, bis natural=tree mit Zusatztags wieder ausreichend genau einen >bedeutenden< Baum beschrieb.
Wird das jetzt bei Parkplätzen genauso? Dass sehr viele Parkplätze gar nicht öffentlich nutzbar sind (Anwohnerparkplätze/Firmenparkplätze etc.) macht hier die OSM-Daten ohnehin nur sehr beschränkt nutzbar (persönliche leidvolle Erfahrung). Und dass mann innerorts am Straßenrand parken darf ist keine wirklich hilfreiche Information - insbesondere, da dort in den Städten meistens ohnehin kein Parkplatz frei ist
Wenn man Daten so einträgt, dass die Verwendung nicht mehr möglich ist, also die Daten nicht sinnvoll verwendet werden kann, dann ist das nicht zielführend. Damit die Daten verwendet werden können, müssen sie sinnvoll eingetragen werden. Nicht einfach stumpfsinnig „so eintragen, wie es in der Realität ist“.
„Die Redewendung „Don’t tag for the renderer“ (Attributiere nicht für den Renderer!) hat bei OSM eine lange Geschichte und bedeutet: Nicht absichtlich falsche Attribute vergeben, nur weil diese zur gewünschten Darstellung führen.“ http://wiki.openstreetmap.org/wiki/DE:Tagging_for_the_renderer
Genau das wird aber gemacht, wenn man amenity=parking für straßenbegleitende Parkmöglichkeiten missbraucht. Es ist „mappen für den Renderer“.
Ich sehe bei amenity=parking keinen Bedeutungswandel, sondern einen Missbrauch, damit es auf Karten dargestellt wird.
Dann wird aber auch das Verkehrszeichen “Parkplatz” missbraucht.
Wie gesagt lässt sich die Straßenbegleitung aus gemeinsammen nodes ableiten und dem “auszeichnen” ableiten. Dann sollte vielmehr auf das eintragen der “Realität” gedrungen werden:
amenity=parking
parking=surface
surface=asphalt
parking:condition:maxstay= 2 h
parking:condition:time_interval=Mo-Fr 08:00-18:00; Sa 08:00-13:00
parking:lane=parallel
operator=Stadt Dresden
access=*
website=*
lit=*
fee=*
description:de=*
Das zeigt dem Renderer mehr und er kann entscheiden ob er z.B. parking:lane nutzen möchte und wie (eventuell wie von pyram vorgeschlagen: ‘Letztere könnte man dann ja wie einen Parkplatz auf der Hauptkarte gelb darstellen, aber das “P” weglassen.’).
Das sind m.E. Daten der Realität - die Daten die jeder (nach seinem Bedarf) sinnvoll verwenden kann. Wer eine “reine” Parkplatzkarte erstellen will kann dann nach fee, lit, access, … weiter unterscheiden.
