Wege und Flächen nicht verbinden

Wege und Flächen **nicht **zu verbinden ist eigentlich richtig.

Ich wurde jetzt von JOSM auf amenity=parking: parking=surface (Fläche)
in Verbindung mit highway=residential; … (Weg) als “andere” hingewiesen.

Ich betrachte die Verbindung als richtig, da der Parkplatz an der Straße liegt und von der Straße auf ihn aufgefahren wird - oder sollte man ihn doch trennen?

Geht der Parkplatz bis zur Straßenmitte?

Allerdings hat man bei einer Trennung dann wieder das Problem, dass Osmosis “unerreichbarerer Parkplatz” anmeckert …

Bei Wegen und Flächen kommt es drauf an, wie sie liegen und wo man sie verbindet. Wenn es in der Realität eine Verbindung gibt, dann am besten auch bei uns, z.B. sollte es eine Verbindung geben wo ein Weg in ein Gebäude führt (Eingang) (sofern man den Weg überhaupt mappt)

Flächen die neben Wegen liegen würde ich dagegen nicht verbinden.

Das ist wohl eine Sache der Betrachtungsweise.
Ein an der Straße liegender Parkplatz kann über das parking:lane dargestellt werden.
Problem: wird kaum gerendert.
Die Verbindung von Straße und dazu parallel liegenden Parkflächen ist ja eher weniger für die Darstellung, sondern für das Routing wichtig. Aber wer ohne Routinginformation Probleme hat, auf einen Parkplatz an der Straße zu fahren…

Mir ist kein interner Test in JOSM bekannt, der da meckern würde. Hast Du mal ein Beispiel?
Ein Parkplatz, der an einer Straße liegt, wird aber eh mit parking:lane (1) erfasst, oder?
(1) https://wiki.openstreetmap.org/wiki/Key:parking:lane

Beispiel: https://www.openstreetmap.org/way/230344578

parking:lane ist ein Parkstreifen, Beispiel: https://www.openstreetmap.org/way/468766522

Hinter dem linken Haus ist der Parkplatz im Bild:

EDIT: in JOSM “Straßenlinien haben gemeinsamen Abschnitt mit Gebiet” unter “Andere”

https://www.openstreetmap.org/way/230344575 dieser ist genauso - und wird nicht bemängelt.

Es liegt an der abgehenden “Auffahrt” - habe es probehalber getrennt. Dann wird nichts bemängelt.

Ist für mich erledigt - Danke.

Ich würde den Parkplatz entsprechend seiner Ausdehnung zeichnen, also nicht bis zur Mitte der Straße, sondern nur bis zum Rand.

Ah OK, ich bekomme da keine Meldung. Grund: Die beiden Wege haben nur drei gemeinsame Punte. Erst wenn ich noch einen hinzufüge, sehe ich die Meldung. Vielleicht hast Du das ja gerade in Arbeit?

Egal. Man könnte amenity=parking von diesem Test exkludieren. Oder sogar alle amenity=* ?
Für diverse Schlüssel wie building=* oder man_made=* wird das schon gemacht, sie Preference overlapping-ways.ignored-keys.

Habe es jetzt so hochgeladen - und “andere” ignoriert, da es an der abgehender Auffahrt liegt.

Das ist wieder das alte Problem, wenn Flächentagging und Linientagging aufeinandertreffen. Das ist ein ähnliches Problem wie bei Grünflächen oder Fußgängerbereichen neben der Straße oder beim Getrennt-Mapping von straßenbegleitenden Rad- oder Gehwegen.

Einerseits will man darstellen, dass Straße und Parkplatz über die ganze Länge verbunden sind (Router). Andererseits will man den Parkplatz nicht größer machen als er ist. Beides gleichzeitig geht nicht, wenn man die Straße mittels Linie in Straßenmitte taggt. Man muss sich entscheiden: getrennt oder zusammen mappen. Was das geringere Übel ist ist m. E. Ansichtssache.

Bei Kartendarstellungen sind - bei perfekten Renderern und Mapping - beide Varianten gleich gut. Die Parkplatzfläche wird in der richtigen Größe angezeigt, die Straßenlinie in der richtigen Breite. So werden sie direkt nebeneinander gezeichnet ohne Lücke dazwischen. Der “ungültige” Teil des Parkplatzes beim Zusammen-Mappen wird durch die Straße überdeckt.

Bei üblichen Renderern wird die Breite der Straße in unteren Zoomstufen nicht entsprechend width- & placement-tags gezeichnet, hier ist die Frage, welcher daraus entstehende Fehler schlimmer ist.

  • Beim Getrennt-Mappen ist der Parkplatz in hohen Zoomstufen irgendwann freischwebend ohne Verbindung zur Straße, was nicht korrekt ist. Dafür wird seine Größe weiterhin korrekt gezeichnet.

  • Beim Zusammen-Mapping ist der Parkplatz in jeder Zoomstufe, mit der Straße verbunden, was korrekt ist. Dafür ist der Parkplatz in dem Maße größer als draußen vorhanden, in dem die Straße zu dünn gezeichnet wurde. Das ist aber ein Fehler des Renderers, der in hohen Stufen das width-Tag nicht verwendet und ließe sich relativ leicht vermeiden, indem genau das getan wird.

Wenn die Straße nicht zusätzlich als Fläche gemappt wurde finde ich das Zusammen-Taggen - also das Heranziehen bis an die Straße - als das geringere Übel, da die üblichen Anwendungen (Router und Kartendarstellungen) gut damit klarkommen. Beim Getrennt-Mappen ist das nicht der Fall, weil Router die Verbindung von Parkplatz und Straße nicht erkennen können und ich die Lücken in hohen Zoomstufen als sehr falsch empfinde.

Ich hoffe dann, dass kein Protoxenus in der Nähe ist, der meinen “Unfug” wieder zurückbaut :wink: .

es führt dazu, dass Sachen zwischen Parkplatz und Straße bzw. auf der Straße, dann auch auf dem Parkplatz liegen. Und dass man den Parkplatz größer schätzt als er ist.

Genau. Nur ist das - für mich - das kleinere Übel, da der Fehler sich den Großteil der Nutzer wie beschrieben nicht offenbart.

Bei einer Datenabfrage “wieviel Parkfläche haben wir in Dresden” würde es die Werte verfälschen (die wären allerdings wegen nicht vollständigen Parkplatzmappings eh ziemlich falsch.)

Die fehleden Verbidnung zu Straße beim Getrennt-Mapping offenbart sich aber ziemlich schnell. Sollte z. B. am Ende des Parkplatzes ein Weg beginnen, wäre der für den Router nicht erreichbar. Man müsste als Workaround Linien einzeichnen, die es so garnicht gibt.

kritischer ist die Lage bei Flächen die umzäunt sind, weil da die Umfriedung entweder nicht am Rand liegen würde oder in der Mitte der Straße.

Auch ist es ein oft gesehenes Problem dass unerfahrene Mapper Straßen mit den Flächen verbinden anstatt mit anderen Straßen, wenn man die Flächengrenze und den highway überlappt

Diese Verbindung sollte man meines Erachtens sowieso einzeichnen, da Routing über Flächen nach wie vor nicht funktioniert. Das ist dann zwar ein virtueller Weg, doch arbeiten wir alle permanent mit solchen virtuellen Wegen. Jeder an eine Straße angebundene Fußweg ist ja ab Straßenrand bis zur in Straßenmitte verlaufenden Straßenlinie quasi ein virtueller Fußweg.
Ich füge daher selbst bei Parklätzen, die nicht in Stellplätze und Flächen zum Fahren unterteilt sind, in solchen Fällen eine “virtuelle” Zufahrtsstraße dort ein, wo für gewöhnlich die Autos herfahren, wenn sie dort parken wollen. Und an diese virtuelle Zufahrtsstraße binde ich dann den auf der anderen Seite wegführenden Fußweg an.

Eine Parkfläche, die durch einen Zaun etc. von der Straße getrennt ist und bei der nur an einer bestimmten Stelle der Wechsel von der Straße auf die Parkfläche möglich ist, sollte genau an dieser Stelle mit einer Zufahrt an die Straße angebunden werden und somit auch nicht als Fläche an die Straßenlinie geklebt werden.

Ist der Parkplatz aber über die gesamte Seitenlänge von der Straße aus zu erreichen, wäre eine solche Verklebung meines Erachtens nicht so schlimm. Ich sehe dann aber auch keinen Nutzen darin. Jedes Routingprogramm sollte den wenige Meter neben der Straße liegenden Parkplatz als solches erkennen und bis zur Straße neben dem Parkplatz routen können. Das machen Routingprogramme ja auch bei Häusern. Dort wird auch hingeroutet, obwohl die Häuser nicht direkt mit der Straße verbunden sind. Daher bin ich auch bei neben der Straße liegenden Parkflächen dafür, die Fläche am Straßenrand enden zu lassen.

Für mich ergibt sich die Logik daher das Navigation/Routing nur auf Wegen stattfindet die ein “highway=*” tragen. Alles andere sind POIs - d.h. auch ein Parkplatz ist nur ein POI der über Straßen “erreichbar” im Sinne von “Man kann nah herranfahren” ist.

Auf der Fläche des Parkplatzes, oder dessen aussenkante findet kein Routing statt.

Deshalb löse ich diese dinge ab - d.h. ich setze keine gemeinsamen Nodes. Das Osmosis da meckert halte ich für einen Fehler und sehe da keine Begründung drin.

Flo

Ich bin der Meinung, dass hier viel zu viel auf das Kartenbild geschaut wird.
Wir sollten uns prinzipiell angewöhnen, das in die DB zu bringen, was auch wirklich vorhanden ist. Da sich aber über die Jahre eingebürgert hat, dass man so kartiert, das es im Kartenbild “schön” aussieht, ist dadurch ein Trend entstanden, der sich schwer wieder umkehren lässt.

Der Ball liegt hier bei den Renderern, das in der DB vorhandene auch endlich richtig in die Kartendarstellung zu bringen.

Wie JochenB schon schrieb, wird es endlich Zeit , dass

  • in den hohen Zoomstufen die Straßen-und Wegebreiten richtig gerendert werden. Wenn diese nicht angegeben sind, kann man auch default-Werte nehmen. Wenn das richtig im Kartenbild dargestellt wird, gibt es auch einen Anreiz, dass die Breite der highways mit erfasst wird.

  • Fuß- und Fahrradwege, die an die Straßen gemappt sind, im Kartenbild dargestellt werden.

  • Parkplätze, die als parking:lane kartiert sind, im Kartenbild dargestellt werden.

Und, ja, ein Parkplatz längs zur Straße ist mit dieser verbunden, aber nicht mit der Mittellinie, sondern mit dem Straßenrand.

Die Frage, die sich mir immer noch in diesem Zusammenhang stellt, ist, warum ein solcher Parkplatz unbedingt routbar sein muss. Wenn ein Haus 10m neben der Straße steht und es keinen kartierten Fußweg zum Haus gibt (Privatgelände, nicht einsehbar), gibt sich jeder mit der Information, die die Routingsoftware in der Karte darstellt, zufrieden. Das Routing endet auf dem nächsten routbaren Weg in kürzester Entfernung zum Haus. Warum geht reicht das nicht bei Parkplätzen an der Straße?

Zum Problem routing über Flächen, über die keine sichtbaren Wege führen, hat sich Galbinus hier schon geäußert. Und wenn diese Routen übers Wasser führen, ist es auf einmal völlig in Ordnung, dass sie auf der Karte erscheinen.

Edith: Rechtschreibung

Ich würde ja sagen, wenn man sich schon die Mühe macht den parallel zur Straße verlaufenden Parkplatz flächig zu mappen, kann man dabei auch gleich die Straße mit flächig mappen.

Da flächig gemappte Straßen in Carto nicht gerendert werden, fühlen sich einige Leute nicht “belohnt”, d.h ihre Arbeit wird quasi nicht anerkannt.

Osmarender bei tiles@home, Friede ihrer Asche, konnte das, habe ich damals höchstpersönlich eingebaut, wenn auch nur etwas rudimentär, weil man nicht linker/rechter/beidseitiger Radweg unterscheiden konnte, es gab nur die Möglichkeit eine dickere Linie (bis dahin nur der “Straßenrand”, danach eben auch Radwege und auch motorroad=…, auch etwas, was Renderer dringend darstellen sollten) unter eine dünnere Linie (Straßenklasse) zu legen.

Seit wann denn das? Ich kenne die Regel für andersartige Flächen - also kein landuse an Verkehrsinfrastruktur.

Gleichartige Flächen muss mal ja ofta mit Linien von Wegen verbinden. Jedesmal wenn man einen Platz in eine Stadt einzeichnet, muss man den ja sinnvollerweise mit den Verkehrswegen verbinden. Eine flächig gemappte Fußgängerzone braucht auch Zuwege… Etc… Etc…