access-Tags nach Nutzerklassen rendern

Moin beisammen,

ich hab ne kurze Frage, und zwar bin ich auf der Suche nach einem Tool, das mir eine Karte rendert, die je nach vorher eingestellten Nutzerklassen (Fuß, Kfz, HGV, etc.) die Straßen, die für diese Nutzerklasse als gesperrt hinterlegt sind dementsprechend markiert.

Das ganze hätte für mich zwei große Vorteile:

Zum einen kann man easy für ein größeres Gebiet die korrekte Anwendung der access-Tags überprüfen, zum anderen erleichtert das die Orientierung in abgelegenen Gebieten, nämlich indem man sofort sehen kann, welche Straßen z.B. fürs Auto Tabu sind (vehicle=no wird ja z.B. von Mapnik nicht gerendert).

Gibt es sowas?

Viele Grüße,
hsimpson

P.S.: Warum ich für sowas ungerne den Router frage: Der schlägt dir nur die Route vor, die er, warum auch immer, als am Sinnvollsten erachtet. Warum eine andere Route nicht Sinnvoll ist erfährt man nicht und ob man sie überhaupt nutzen kann nur sehr umständlich, indem man wild Start, Ziel und Zwischenstopp variiert.

Was wäre denn für dich das Kriterium für “gesperrt”? gib bitte mal ein paar konkrete Beispiele.

Das geht beispielsweise mit Overpass-Turbo. Die Frage ist natürlich, wie komplex man das gestalten will. Solange man sich mit den Basis-Access-Tags begnügt und nicht eventuelle Conditional-Tags auswertet, hält sich der Aufwand in Grenzen. Hier Beispiele für entsprechende Abfragen (Link führt die Abfrage direkt aus, ansonsten Kartenausschnitt verschieben und erneut auf “Ausführen” klicken - Klick auf die markierten Ergebnisse in der Karte zeigt direkt die Tags des jeweiligen Weges an):

Fußgänger:


way[highway][foot]({{bbox}})->.a;
(
  (way[highway][access][access!="yes"][access!="permissive"]({{bbox}}); - way.a;);
  way.a[foot!="yes"][foot!="designated"][foot!="official"][foot!="permissive"];
);
out body;
>;
out skel qt;

Radfahrer:

way[highway][vehicle]({{bbox}})->.a;
way[highway][bicycle]({{bbox}})->.b;
(
  (way[highway][access][access!="yes"][access!="permissive"]({{bbox}}); - (way.a; way.b;););
  (way.a[vehicle!="yes"][vehicle!="permissive"]; - way.b;);  
  way.b[bicycle!="yes"][bicycle!="designated"][bicycle!="official"][bicycle!="permissive"];
);
out body;
>;
out skel qt;

PKW:

way[highway][vehicle]({{bbox}})->.a;
way[highway][motor_vehicle]({{bbox}})->.b;
way[highway][motorcar]({{bbox}})->.c;
(
  (way[highway][access][access!="yes"][access!="permissive"]({{bbox}}); - (way.a; way.b; way.c;););
  (way.a[vehicle!="yes"][vehicle!="permissive"]; - (way.b; way.c;););  
  (way.b[motor_vehicle!="yes"][motor_vehicle!="permissive"]; - way.c;);
  way.c[motorcar!="yes"][motorcar!="permissive"];
);
out body;
>;
out skel qt;

Um es erst einmal nicht zu kompliziert zu machen, habe ich komplett ignoriert, dass bestimmte Wegarten implizit für bestimmte Nutzerklassen tabu sind (beispielsweise, dass ein Auto nicht auf highway=footway fahren bzw. ein Fußgänger nicht auf highway=motorway laufen kann). Ausnahme davon ist nur, wenn jemand trotzdem Access-Tags verteilt hat, die eine entsprechende Einschränkung explizit vornehmen.

Ferner wird so etwas wie frei für Lieferverkehr (access “delivery”) o. ä. wie gesperrt gehandhabt. Nur “yes”, “permissive” und bei Fußgänger/Radfahrern zusätzlich noch “designated” und “official” habe ich als “frei” gewertet.

Die Problematik ist nun noch, dass die Access-Tags hierarchisch organisiert sind und immer nur das speziellste für den jeweiligen Nutzer Gültigkeit hat. Am Beispiel für PKW sei nun die Idee erläutert damit umzugehen: Zunächst werden alle Highways, die vom Access-Elternelement ein spezielleres Access-Tag in Richtung Motorcar haben, in Mengen gespeichert, weil sie innerhalb der Abfrage mehrfach benötigt werden. Anschließend werden alle Highways, die ein allgemeines Access-Tag haben, welches keinen freien Zugang impliziert, in die darzustellende Wegemenge eingebracht, es sei denn, es gibt bei diesen Highways auch noch ein spezielleres Tag (vehicle, motor_vehicle oder motorcar - das waren die vorher angelegten Mengen .a, .b und .c). Denn wenn es ein spezielleres Tag gibt, ist das allgemeinere Tag zu ignorieren. Danach werden alle Highways mit einem vehicle-Tag (Menge .a), welches keinen freien Zugang impliziert, hinzugenommen, es sei denn, dass wiederum ein spezielleres Tag (motor_vehicle oder motorcar - Menge .b und .c) dort vorhanden ist. Anschließend kommen die Highways mit nicht freien Zugangstag für motor_vehicle (Menge .b) hinzu, von denen die mit einem speziellen motorcar-Tag (Menge .c) abgezogen werden. Zum Schluss kommen noch die Highways mit einem nicht freien motorcar-Tag (Menge .c) hinzu.

PS: Wer sich wundert, warum im Beispielgebiet so viele Wege für Fußgänger gesperrt sind - ein Klassiker-Fehler: “access=agricultural”.

Dieser Fehler führt bei uns (Freizeitkarte) des öfteren zu Beschwerden von Kartennutzer, da wir auf diesen Wegen das Routing für Fußgänger und Radfahrer verbieten. Dies gilt analog für “access=forestry”. Wer in seinem Gebiet also solche Wege hat, sollte die mal überprüfen und im Negativfall entsprechend korrigieren.

Gruß Klaus

“access=agricultural” + “foot=designated” ist hingegen korrekt. http://osmtools.de/traffic_signs/?signs=239,1026-36 oder http://osmtools.de/traffic_signs/?signs=240,1026-36

Abgesehen davon, dass ich diese Kombination noch nie gesehen habe - was mir an dem Beispiel nicht gefällt: Wenn ein highway breit genug ist, dass ein Traktor darauf fahren kann, ist es ein track oder service und kein path. Land-/Forstwirtschaftlicher Verkehr unter 2 m Breite ist mMn nur theoretisch relevant.

Häufigerer Grund für gesperrte Wege dürfte sein “access=agricultural/forestry” statt “vehicle/motorvehicle=agricultural/forestry” bei Zeichen 250/260 + Zusatz, also z.B. http://osmtools.de/traffic_signs/?signs=260,1026-36

@seichter: Beispiel: http://mapillary.com/map/im/EhbuS3DYxPgnyHpf99PJ6Q. Ich sehe in solchen Fällen auch eher ein track als ein path. Die Anmerkung war auch nur dahingehend gedacht, dass “access=agricultural” unter Umständen doch korrekt sein kann.
@Kontinentalverschieber: Danke für die Overpass-Abfragen. Ich habe sie für mich aber noch um z.b. “[bicycle!=use_sidepath]” erweitert.

Hi Kontinentalverschieber, danke für diese Abfragen, ich denke damit kann man schonmal etwas anfangen. Conditionals würden hier in der Tat zu weit gehen.

Wambacher: Damit ist gemeint, dass das Tagging der Straße impliziert, dass die gewählte Nutzerklasse dort nicht zugelassen ist. Beispiel: Rad/Fuß - motorroad=yes; Auto - highway=footway; Fuß - foot=no; Rad - bicycle=use_sidepath; etc.

Darauf bin ich gekommen, weil ich zum einen letztlich nach einer Orientierung auf der Hauptmap in einem Zeichen 250 hängen geblieben bin, wo sich bei der anschließenden Kontrolle rausstellte, dass dieses auch korrekt mit vehicle=no eingetragen war. Nur rendert mapnik sowas halt nicht. Zum anderen bin ich in letzter Zeit häufiger über Dinge wie z.B. ein access=no gestoßen, obwohl nur ein Zeichen 250 vorhanden war.

Grüße!

Hi, ich habe mal testweise eine kleine Online-Karte gebastelt: https://osm.wno-edv-service.de/access

derzeit funzt nur das 1. Datenlayer “Check foot access” (wer ne bessere Bezeichnung hat, her damit).

Die mMn fehlerhalten Highways werden rot angezeigt und ein Klick auf das Objekt sollte die Tags als Popup zeigen.

Zugrundeliegende Query:


select osm_id,
       array_to_string(hstore_to_array(tags),',') tags,
       way
  from planet_osm_line
 where highway in('path','footway','steps')
   and (access not in ('','yes','permitted','permissive' or
        tags->'foot' not in ('','yes','designated','official','permissive'))
       );

Problem für mich ist, wie ich access=private einordnen soll. Derzeit ist es halt nicht erlaubt und wird daher rot dargestellt.

(Nur) falls Interesse besteht, kann ich noch die beiden anderen Datenlayer aktivieren und im Popup einen Edit-Button einbauen. Und die Regeln natürlich auch überarbeiten. Z.B. was ist bei highway=path, access=agricultural - aber kein foot=yes?

Gruss
walter

BTW: Mit dem nächsten Carto-Update werden die gesperrten Wege übrigens weniger prominent dargestellt … grau statt rot.

Gruß Klaus