Ich würde diese strenge Interpretation von Parkplatzgasse eher so formulieren:
sind mit mindestens einer service Road aber keinen anderen Straßentypen verbunden (egal ob einseitig, beidseitig oder auch in der Mitte) - die wiederum mindestens über eine Nicht-Parkplatzgasse mit dem restlichen Straßennetz verbunden sein müssen.
Da hast Du meine Intention nicht ganz verstanden.
Ich meinte, dass es nicht wichtig ist, ob die Wege für den Durchgangsverkehr (insb. Fahrräder) nutzbar sind, weil sich das bereits dadurch ergibt, dass im weiteren Verlauf Wegebeziehungen gemapped sind (oder auch nicht). Im Grunde wäre das vergleichbar mit noexit=yes, das im Grunde nicht erforderlich ist (wie bekannt im Grunde eher für die “Ruhigstellung der Qualitätsprüfung”), weil der Router an einem Stummel sowieso nicht weiterroutet.
Und wenn b) zutrifft, dann würde auch ein anderes “service=*” nichts mehr retten, da der Router sich eigentlich an access halten sollte.
a) nehme ich persönlich mindestens für Rad- und Fußwegverkehr generell nicht an. Sonst wäre wohl kaum mehr ein Supermarkt oder viele Einsiedlerhöfe in den Bergen nicht mehr erreichbar.
Das finde ich ganz gut zusammengefasst, ja. Es entspricht auch dem, was auf der englischen Wikiseite steht. ZB hier Way: 259581105 | OpenStreetMap finde ich es ganz gut gelöst. Dann kann der Router einen bei der Fahrt vom Parkplatz runter auch so schnell wie möglich auf einen der Hauptwege schicken und es geht nicht einfach kreuz und quer durch die Parkgassen.
@pyram Ich denke schon wir meinen dasselbe, wobei ich deine Antwort als access muss explizit erfasst werden verstanden habe.
Mir ging es nicht um Sackgassen - weil die sind wie du schon sagst unkritisch sind - sondern um fehlendes access=destination oder falsches access=private (weil “Privatweg”) auf mehrfach verbundenen service-ways.
Darf, sollte oder muss ich bei driveway und parking_aisle per default ein access=destination für alle oder bestimmte Verkehrsarten annehmen?
Wenn ich das mit destination auch für Fußgänger und Radfahrer durchziehe dann gehen mir jedoch einige Verbindungen zu anderen Wegen verloren.
Z.b
- Fahrbahn zu sidewalk/cycleway, oder
- Verbindung zu einem Pfad, der von einer Grundstückszufahrt abgeht. Aber vermutlich ist dann Grundstückzufahrt hier auch noch zutreffend?
Es wäre natürlich eindeutiger, wenn das korrekte access explizit getaggt wäre.
Bei driveway ist es für mich im Grunde fast egal, ob access=private oder destination, aber implizit nicht zum durchrouten.
Bei parking_aisle ist es eigentlich immer foot=yes und bicycle=yes, wenn kein gegenteiliges access gesetzt ist. Nachdem ein Router wohl immer service ohne Zusatz dem parking_aisle den Vorzug geben würde (bzw. sollte), ist es auch egal, ob man Letzterem ein destination gönnen würde. Allerdings wäre das in der Regel auch falsch, da die Parklatznebenwege faktisch nie so beschildert sind und grundsätzlich auch zum Durchfahren genutzt werden, wenn es deutlich kürzer ist.
Beim hier diskutierten Fall ist es daher routingseitig eigentlich egal, ob mit oder ohne parking_aisle, weil als Sackgasse für keine Routingfunktion von großer Bedeutung. Alleine von der Funktion her wäre es mir persönlich aber mit dem Zusatz deutlich lieber, weil hier eigentlich nur Stellplätze erreichbar sind.
Auch auf Kartendarstellungen (“er hat Jehova gesagt”) würde ich den Stummel lieber unterdrücken.
1 Like
Von der Definition her, sollte es fast egal sein, weil ein driveway ja wohl in 99% aller Fälle eh eine Sackgasse ist. Oder seh ich das falsch?
1 Like
Gibt schon oft Hofzufahrten, die zu zwei Seiten sind und so zwei Straßen verbinden. Die bieten sich dann als Abkürzung bzw. Ampel-Umfahrung an. Aber driveway sollte eh schon stark benachteiligt werden bei der Ermittlung der Route, oder access=destination implizieren.
- Reine Grundstückseinfahrt aus dem öffentlichen Verkehrsraum heraus, ohne weitere Abzweigungen oder Fortsetzungen? Könnte ohne Verluste access=private getaggt werden? Dann service=driveway.
Hm, wenn ich eine Grundstückszufahrt habe, die zwischen Straße und Grundstück noch einen separat gemappten, baulich getrennten parallelen Fuß- und/oder Radweg kreuzt, muss ich da dann jetzt die Zufahrt aufteilen in hw=service ohne service zwischen Straße und Parallelweg und hw=service mit service=dw zwischen Parallelweg und Grundstück? Und wenn dann das Grundstück ein kleiner Parkplatz ist wie oben beschrieben, dann ist das letzte Stückchen auf dem Parkplatz selbst dann hw=service mit service=p_a?
1 Like
Ich setze immer den gesamten Weg auf service=driveway und splitte am Tor auf in operator:type=private + access=private + foot=destination. Wenn kein Tor, dann allerdings nur access=destination. Egal, wertet vermutlich kaum einer aus. Magic Earth allerdings mittlerweile.
1 Like
Ich meinte in meinem Beispiel, dass es nach den Stellplätzen nicht weitergeht. So ähnlich wie im folgenden Bild, wo sich die zwei Häuser die Auffahrt teilen. Ich hätte hier den Weg mit service=driveway versehen.
2 Likes
Ob Missverständnis oder nicht, ist irrelevant. Tags werden weiterentwickelt. Ich sehe keinen Nachteil, die Gasse eines eingassigen Parkplatzes mit service=parking_aisle zu versehen. Der Weg hat dann die gleiche, untergeordnete Bedeutung wie beim großen Parkplatz. Es nimmt dem großen Parkplatz die Beutung nicht weg. Warum hat der Tag dann seinen Sinn komplett verloren?
1 Like
Wenn das Tag den Sinn hat, dass der Renderer zwischen der Zufahrt zu einem Parkplatz und den davon abzweigenden Verteilerwegen auf dem Parkplatz unterscheiden kann, dann verliert es seinen Sinn, wenn du auch die Zufahrt so taggst. Scheint mir recht logisch und selbsterklärend zu sein.
Gegenfrage: Welchen Vorteil hat es denn, auch die Zufahrt zu einem Parkplatz service=parking_aisle zu taggen? Der Nachteil ist der, dass ich in den Zoomleveln, in denen parking_aisle nicht mehr dargestellt werden, nicht mehr sehen kann, wo ich von der Straße auf den Parkplatz abzufahren habe.
Die Tatsache, dass wir anhand der Geometrie sagen können, ob ein Weg in einem Parkplatz liegt oder nicht (bzw. dort durch geht), sollte uns davon abhalten, dies auch noch mit Tags zu unterstreichen, die exakt dasselbe aussagen sollen. Und genau deswegen fände ich es rein semantisch sinnvoller, eine Klassifizierung in Haupt/Nebenstraßen auf einem Parkplatz nur dort durchzuführen, wo es auch angebracht ist, eben weil vorhanden. Da schließe ich mich ganz @FraukeLeo an,
Genau, das ist driveway für mich. Auch wenn sich dort zwei Häuser/Ziele befinden. Andere verwenden dann schon highway=service ohne service=driveway, weil es keine Zufahrt zu einem Grundstück ist.
1 Like
Für mich haben diese kleinen Zufahrten nicht die Bedeutung von highway=service. Sehen wir uns das Beispiel an:
Da es sich um eine Grundstückszufahrt handelt (man denke sich gerne ein Haus auch weg, damit es auch wirklich nur ein Grundstück ist) wird das highway=service zu driveway herabgestuft. Nun nehmen wir die Häuser komplett weg und es bleiben nur die beiden Parkplätze. Jetzt wird die Straße plötzlich wichtiger und zu einem highway=service ohne Abstufung? Das passt doch nicht! Die Bedeutung wird doch eher geringer (nur noch Parkplatzzufahrt).
1 Like
Wenn das ein öffentlicher Parkplatz wäre, dann fände ich highway=service ohne service=* angebracht. Wenn es aber ein Privatparkplatz ist, dann würde ich das als Zufahrtsstraße zum Grundstück sehen und service=driveway ergänzen, weil die Bedeutung, und vor allem Wichtigkeit, eine andere ist.
2 Likes
Eben. Die Erklärungen von Kreuzschnabel sind ja ganz nett, aber eben nur für große Parkplätze und kleinere Zufahrten.
Problematisch finde ich auch den privat-Status auf dem driveway. Das sollte man bitte nicht als implizit access=private (also quasi no) verstehen. Ich würde den driveway eher als access=destination mit operator:type=private sehen wollen.
Wie man das kurze Stück von Fahrbahn über Radweg bis zum Fußwege ausnimmt ohne es explizit aufzuteilen und verschiedenen access zu verteilen bleibt Frage. Kann man das den Routern zumuten automatisch zu lösen? Vermutlich eher schwierig.
bzgl. parking_aisle würde ich sagen.
- Bei kleinen nicht öffentlichen Parkplätzen (Anwohnerparkplätzen auch Kundenparkplätzen) auf privaten Grund ist es die Grundstückszufahrt und damit service=driveway.
- bei kleineren öffentlichen Parkplätzen ist es keine Grundstückszufahrt. Ob nun parking_aisle oder ohne wäre mir ziemlich egal. (Ich muss eine kurze Parkplatzzufahrt von kleinen Parkplätzen nicht in kleinen Zoomstufen in der Karte sehen können. Dazu kann man reinzoomen oder das Navi benutzen.)
Bei großen Parkplätzen würde man ja nichts ändern. Ich hatte oben auch geschrieben, dass man dies auch bei kleinen Parkplätzen so handhaben kann. Die Zufahrt ist dann nur etwas absurd kurz: Der Weg von der Straße über den Bürgersteig bis zum Parkplatz. Um das Micromapping nicht zu erzwingen, könnte man bei kleinen Parklpätzen sich das explizite Zufahrtsmapping sparen.
Ein highway=service ohne Zusatz impliziert eine potentiell höhere/andere Verkehrsbedeutung als mit Zusatz. Der Weg über einen kleinen Parkplatz hat eben nicht die gleiche Bedeutung wie die Zufahrt eines großen Parkplatzes oder eines anderen Service-Weges ohne Zusatz.
Das sehe ich als “Vorteil”, da der parking_aisle-Weg des kleinen Parkplatzes genauso behandelt wird wie der gleich unbedeutende parking_aisle-Weg auf dem großen Parkplatz. Den will ich gar nicht auf niedrigen Zoomstufen sehen. Weiterhin gibt es auch noch Parkplatzsymbole, die zur Orientierung dienen können.
Zudem ist es Aufgabe des Renderers, ein sinnvolles Zoomlevel zu finden, ab dem parking_aisle nicht mehr sichtbar ist. Den Weg deswegen anders zu taggen, wäre das typische Mappen für den Renderer. Davon abgesehen: Bei OsmAnd ist der Kartenausschnitt auf meinem Handy (vertikal) über 4 km und die parking_aisle sind immer noch sichtbar. Erst ab der nächsten Zoomstufe (über 8 km sichtbar) werden sie ausgeblendet.
Das sehe ich hier auch so. Wenn es öffentliche Parkplätze sind, haben sie eine viel höhere Bedeutung, da viel mehr Menschen sie nutzen dürfen.