Moin!
nur zum Verständnis, weil ich es auch nach dem Wiki nicht ganz eindeutig verstanden habe.
In einem Way ist ein Barrier=gate.
Zugewiesen ist noch
foot=no und
bicyle=No
Frage: dürfte ein Routing für Fahrzeuge dadurch verlaufen?
CoMaps hat es gemacht - es ist ein Tor, das als Notabfahrt für ein Parkplatz dient.
OsmAnd benutzt das Gate nicht und die Org-Webseite kann ich nicht mehr testen, weil ich sicherheitshalber jetzt ein locked=yes hinzugefügt habe.
Gruß Jan
Ich glaub access=private ist universeller.
Ich tagge das jedenfalls, auch wenn etwas nicht abgeschlossen sein sollte, das sagt dann ja expliziter “hier nich lang”.
(Die Kombination abgeschlossen und nicht-privat bedeutet ja irgendwas anderes, z.b öffnungszeiten fehlen oder so.)
Die access-Tags gehören meiner Meinung nach an den way.
Für Tore gibt es locked=yes/no.
beides wird mit access tags getaggt, unabhängig voneinander
Es gibt beide Ansätze. Ich halte es nicht für sinnvoll, die access-Tags redundant an Tor und Weg zu erfassen.
Das Tagging für solche Notwege wird auch gerade hier diskutiert. Aktuell gibt es da nichts.
es ist nicht redundant
Erklär mal.
Für Fußgänger und Radler: nein, für Autos hängt es vom Router ab, was der als Default annimmt.
locked=yes wird noch nicht von allen Routern unterstützt. GraphHopper ja, OSRM nein.
Und ein foot=yes “überstimmt” beim Graphhopper ein locked=yes, was IMO eine gute Idee ist.
Stmmt. Man kann ja rüberklettern.
Im Ernst: wenn jemand sein Tor verschließt, dann bedeutet das wohl, das man da nicht durch darf. locked=yes + foot=yes wäre wohl ein Fehler.
Als ich es das letzte mal getestet hatte wurde einfach nur locked=yes, ohne irgendein access=* am Tor von allen drei Routern auf osm.org ignoriert und munter durchgeroutet. Erst mit access=no gings außen rum.
Die access-Tags nur am Weg, aber nicht am Tor selbst macht aber auch nicht immer Sinn, da es Situationen gibt, in denen man problemlos auf beide Seiten eines verschlossenen Tores gelangen kann, man muss halt nur außen rum gehen. Hier ein Beispiel aus Kiel-Holtenau, auf der einen Seite der Ort, auf der anderen das ehemalige MFG-5 Gelände. Das Gelände ist seit 2013 aufgegeben und für die Öffentlichkeit zungänglich, trotzdem ist das Tor nach wie vor verschlossen.
Wenn man da wie von dir vorgeschloagen die access-Tags nur am Way erfasst, dann müsste man ein kurzes Stück Straße unterm Tor raustrennen um dort die acces-Tags zu erfassen. Da macht es mehr Sinn access direkt am Tor selbst zu erfassen. Und redundant wäre in diesem Falle auch nichts.
Hab mal einen Mapper angeschrieben der so ein Tor gemappt hat.
Die Kombi gibt es hunderte mal in Deutschland.
Beispiel: OpenStreetMap
ein geschlossenes Tor hat keine Aussage für die Wege auf beiden Seiten, und nur weil es abgeschlossen ist bedeutet das nicht zwangsläufig dass das ist weil es verboten sein muss da durchzugehen, mir fallen spontan mehrere Stellen ein wo es abgeschlossene Tore gibt man aber auf beiden Seiten Zugang hat, weil es noch mehr Tore gibt die offen sind.
Entferne dich gedanklich von der Vorstellung dass da “jemand” “sein” Tor abgeschlossen hat.
???
locked=yes am Tor heisst: Tor verschlossen, nur der Eigentümer hat den Schlüssel.
foot=yes heisst: Öffentliche Fußgänger können das Tor nehmen.
Somit ziemlich deutlich ein Widerspruch.
Hier in den Wäldern und am Kanal gibt es unzählige Schwingtore und ähnliches, die verschloßen sind, aber Fußgänger und teilweise sogar Radfahrer dürfen da vorbeigehen.
Ok, in dem Fall, dass ein Wegabschnitt zwei oder mehr Zugänge hat, stimmt Dein Argument.
Ansonsten bedeutet ein verschlossenes Tor für den dahinter liegenden Weg genau das: access=private. Das verschlossene Tor übernimmt die Funktion eines Schildes “Zutritt verboten”.
Wenn man durch ein Tor gehen kann, weil es nicht verschlossen ist: locked=no
Wenn ein Weg um das Tor herumführt, dann sollte man diesen separat eintragen:
Das halte ich für die sauberste Lösung.
So etwas kenne ich von etlichen Stellen: Der Weg / die Straße ist durch Gatter/Schranke versperrt, der (markierte) Wanderweg geht seitlich daran vorbei.
Nicht unbedingt. Könnte beispielsweise auch access=customers sein, wenn man sich erst an der Rezeption den Schlüssel/die Keykarte holen muss, um das Tor öffnen zu dürfen.
Wodurch das Tagging nicht redundant wird, denn mindestens der Umkehrschluss gilt nicht: Nur weil ein Tor locked=no ist, ist der Weg dahinter nicht automatisch öffentlich zugänglich.
