Fußgängerzone als Fläche - bzw. Routing über Flächen

Communities Deutschland (Germany)
41

Navis können diese Abspiegespuren nutzen - eben weil es reale Objekte sind. Und sie sind wie Fahrbahnen gebaut.

  • ist m.E. auf alle Fälle besser als
    turn:lanes=slight_left|slight_left;slight_right|slight_right
    destination:lanes=A|A;B|B

Aber wollen sie es?

Eben - aber warum verwenden sie lanes (und siehe oben) - weil kein (passender) highway vorhanden ist?
Oder wir verwenden für alle “Verbindungsspuren” highway=*_link → highway=footway_link in den Flächen?

(Ich habe nichts gegen lanes - solange sie die Anzahl der Spuren auf der (gleichen) Fahrbahn angeben.)

42

Und das Navi weiß woher, dass du von einer Spur auf die andere wechseln darfst? Einer der Gründe, warum nur baulich getrennte Fahrspuren als separate Highways erfasst werden, ist doch, dass man ansonsten zwischen den Spuren wechseln kann.

43

In dem es wie ein Routingprogramm die nächsten Routenpunkte einbezieht - aus der Linksabbiegerspur darfst du nur verkehrswidrig in eine andere Spur wechseln - es sei denn, du meinst es gibt zwei Linksabbieger und ich kann wählen in welche ich möchte - hier wäre lanes=2 richtig an einem highway=*_link -(falls es nicht vorgegeben ist, die ganz linke zum Wenden oder in eine andere Fahrtrichtung wie die andere Linksabiegespur).

Ich kenne nur Karte und Router - was und wie Navis rechnen, weiß ich nicht.

44

Ich frage, weil Du oben schriebst, Du wollest die Dinger auch für Fahrspuren einsetzen und da sehe ich - genau wie bei Abbiegespuren - keinen Sinn, eben weil man, so lange man munter wechseln kann, die einzelnen Lanes nicht trennen darf.

45

Hm. Hm. Widerstrebt mir immer noch irgendwie (weil es das Zeug in der Realität nicht gibt). Aber ich trag weiter meine Bedenken mit mir rum, und ihr baut einfach tolle Router :slight_smile:

Man muss ja nicht immer einer Meinung sein. Ein Veto leg ich garantiert nicht ein (selbst wenn ich eins hätte, nicht).

46

Ich bin auch nicht begeistert. Der Anreiz für eine automatische Lösung im Router wird dadurch auch gemindert.
Gegen ein durchdachtes Proposal hätte ich aber erstmal nichts einzuwenden.

47

Wir haben hier zwei Problemklassen:

  • Ein highway=* als Fläche, damit kommen Router insoweit klar,
    als dass sie den Rand als Route verwenden.
    Das kann man mit viruellen Wegen verbessern.
  • Flächen wie Strand, Wiese, Geröll, Gletscher, die ein Router normaler
    weise nicht mal als Umriss zum Routen verwendet. Hier braucht es einen
    virtuellen Weg, damit der Router überhaupt etwas zum Routen hat.

Für den ersten Fall kann man auf eine algorithmische Lösung hoffen. Für den zweiten Fall ist das in noch weiterer Ferne als es beim ersten Fall bereits ist.

Beide Fälle kann man mit virtuellen Wegen als Provisorium für die Zwischenzeit überbrücken.

Edbert (EvanE)

48

Dann schau dir die Situation mal genau an, zoome heraus auf den Berg.
Richtig böse ist, wenn genau diese logische Wegverbindung fehlen würde
und einen Bergwanderer 1 km Umweg laufen lässt (wenn er so dumm ist, sich alleine auf OSM-Routing zu verlassen).
Ein Holzplatz ist noch nicht automatisch begehbar. Der könnte ja auch voller Holz gestapelt sein.

Wenn du mal genau hinschaust,
https://maps.google.de/maps?q=47.6934+12.3702&hl=de&ll=47.688832,12.366781&spn=0.001461,0.002387&sll=47.6934,12.3702&sspn=0.023369,0.038195&t=h&z=19
dann ist es einfach nur ein logischer Weg, der so einen Platz durchkreuzt.

Man mappt so, dass die Welt möglichst logisch beschrieben wird.

Das einzige Manko ist hier die Optik, dass man den logischen Weg nicht über den
Platz gezeichnet haben will. Also eine “visible=no” Eigenschaft ist gewünscht.

Es gibt viele Fälle, in denen Plätze von Wegen durchkreuzt werden.
Auf Marktplätzen werden die manchmal nur im Pflaster durch eine Vertiefung angedeutet.
Es macht also Sinn, sowohl diese angedeuteten Wege zu mappen
als auch den ganzen Platz, der rechtlich genauso befahrbar ist.
Ein Router könnte sich dann daraus die beste Routing-Strategie herauspicken.

Man könnte nun eine neue logische Klasse der virtuellen Wege einführen,
oder einfach das bewährte Schema (mit allen Features) belassen und nur
die Sichtbarkeit für bestimmte Segmente deaktivieren.

Ein Sichtbarkeit-Flag hätte den Vorteil, dass es generell für jeden Objekt-Typ anwendbar wäre
(Fußpfad, Fahrradweg, Gebäude) und die normale Logik erhalten bleibt.
Man muss dann nicht für jeden Fall eine eigene virtuelle Klasse einführen
(virtuelle Fußwege, virtuelle Straßen, virtuelle Gebäude, virtuelle Flüsse, virtuelle …).
Das muss ja auch alles wieder irgendwie verwaltet und differenziert werden.
Ein einfacher Sichtbarkeits-Ein/Aus-Schalter wäre praktischer und weniger aufwendig
(nur ein Flag im Renderer). Der Renderer muss sowieso bei jedem Objekt Entscheidungen treffen,
ob es in bestimmten Situationen, Konfigurationen oder Zoom-Leveln erscheint oder nicht.

49
50

Natürlich soll in erster Linie der “Style” des Renderers entscheiden wie und ob etwas sichtbar ist. Dafür braucht er aber gute “Ausdrucksmöglichkeiten” in Form von Tags. Eine davon wäre eben so ein “Not-Aus” Flag, als “Empfehlung” dieses Objekt “i.d.R.” nicht darzustellen. Wenn ein Renderer sich nicht darum schert und eine schlechtere Optik riskiert ist das sein Problem. Man hat ihn gewarnt … Es wäre eben konsequenter als Tags zu fälschen oder immer Neue zu erfinden, die bis auf die Sichtbarkeit nichts anderes bedeuten als die Originale. Bei den Stimmbezirken gab es nur die Wahl, eine Auswertesoftware mit falschen Tags in die Irre zu führen (“x-name” oder “name-dontshow”) oder die Optik der Karte zu ruinieren. Der Mapper hat sich zumindest für eine City für die Zweite Möglichkeit entschieden. Es wäre eben alles viel einfacher, wenn man die Ausdrucksmöglichkeit hätte, solche Sonderobjekte “in der Regel”, also für “normale” Karten visuell zu unterdrücken.

Kennst du das nicht von Word: “weiche” zu “harte” Formatierung? Generell wird empfohlen, Formatvorlagen zu nehmen, damit ein Dokument später leichter wieder in eine andere Vorlage gepresst werden kann. (z.B. Überschrift 1 solle dann für ein anderes Doc kursiv statt fett dargestellt werden, geht ruckzuck mit einer Vorlagenformatierung). Trotzdem macht es immer noch Sinn, harte Formatierungen zuzulassen, wenn der Autor eben bestimmte Worte ganz diktatorisch anders formatieren will, als die Vorlage es sonst macht. Manche Dinge können Maschinen eben nicht gut entscheiden. Man kann harte Formatierung natürlich missbrauchen, in meinen Augen aber kein Grund, diese Ausdrucksmöglichkeiten nicht zuzulassen.

51

Moin,

Mal abgesehen davon, dass man hier bei deinem “Wahlkreis”-Beispiel auch mit einem"visible"-Flag nichts ausgerichtet hätte (*) - ein Namespace virtual: würde genau die Möglichkeit bieten:

  • Es dient als Marker für in der Realität nicht vorhandene Objekte.
  • Die bisher vorhandenen Möglichkeiten des Taggens (und Auswertens) bleiben erhalten.

Ein neuer Key oder Namespace hat die positive Eigenheit, dass alle Auswerter sich explizit mit der Problematik befassen müssen, während eine bloße zusätzliche negierende Eigenschaft beim Ignorieren zu ungewollten Ergebnissen führt.

Ein Router kann ganz bequem virtual:xyz wie xyz behandeln - ein Renderer wird sie per se erstmal ignorieren.

Gruß
Georg

(*) Der Renderer hat ja bereits die Möglichkeit genutzt, das Objekt anhand dessen Objekt-Keys zu ignorieren - aber eine einzelne Eigenschaft trotzdem gerendert.

52

Ich hab mal eine Karte mit flächigen Fusswegen in meiner Gegend gemacht, nur um mal ein Gefühl dafür zu kriegen, wie das Problem aussieht. Geduldige Menschen finden sie hier. Noch geduldigere können auch einen Layer mit einem herkömlichen Routing-Graphen anzeigen, der kommt inzwischen sogar mit Relationen zurecht (manchmal zumindest…).

Aus den Flächen wurden bisher nur Gebäude, Wasser, Bäume (Standardbäume erzeugen 2x2m-Löcher) und Parkbänke (1x1m) ausgeschnitten (1). Und natürlich alle Flächen, die schon der Mapper rausgenommen hat.
Einige Fussgängerzonen zeigen wie wichtig eine Lösung wäre. Bei den wirklich bizarren Umrissen wurden aber oft schon hilfreiche Wege durch die Fläche eingetragen.

Grüße, Max

Edit: (1) Strichförmige Hindernisse (Hecken, Mauern…) sind noch Gegenstand intensiver Überlegungen.

53

Nahmd,

Sehr schön.

Lässt sich das (mit vernünftigem Aufwand) noch um die Anschlusspunkte erweitern, also die Stellen, wo Wege anschließen?

Gruß Wolf

54

OT: Bizarr sind an der Stelle nur die Gebäude. Wenn die und ein paar Gebäude weiter nördlich ordentlich in 3d dargestellt werden, kann das 3d mapping als weitgehend ausgereift gelten. 3dr:type=8.7, angedacht ist es also durchaus.

Baßtölpel

55

Erst dachte ich, “Ja”, aber nach dem ersten Versuch… “Nein, eher nicht”. Wege und Flächen schneiden sich nämlich gelegentlich mehrmals. Manchmal sogar richtig oft, falls ein Weg eine Begrenzung eines Multipolygons ist… Mal sehn…

56

Nahmd,

Mein Ok für 3D gibts erst, wenn der Kölner Dom ordentlich wiedergegeben wird. :stuck_out_tongue:

Gruß Wolf

57

alos ich trage das ein damit es besser aussieht

UND

manche die immer wieder schreiben <<<wir arbeiten nicht für die Renderer.>>> achten mehr bei anderen darauf wie bei sich selbst.
und mal ganz unter uns beiden, wen stört es denn wenn man in der Karte auch mal was angezeigt bekommt :sunglasses:

58

So funktioniert aber rendern nicht. Der Renderer möchte das Objekt so gut wie möglich beschrieben haben und an Hand dessen malt er es oder eben nicht. Dein allgemeines “visible=no” hilft da dem Renderer überhaupt nichts. Das sagt ihm nur, dass da draußen mindestens ein Mapper ist, der der Meinung ist, das Objekt ist unsichtbar. Es verrät aber nicht den Grund. Wenn der Grund ohnehin schon anderweitig getaggt ist, braucht der Renderer auch kein zusätzliches “visible=no”. :wink:

Automatische Lösungen des Routers sind immer (aktueller Erfassungsgrad) Ratespiele. Das kann gut gehen, kann aber auch in einer Route durch die Kirche in der Platzmitte führen. Der Mapper kann sagen: So-Fr kann man am besten direkt über den Marktplatz gehen, Sa ist Markt, da muss man einen Bogen machen.

Den Druck auf die Router gibt es ja nun auch schon seit vielen Jahren mit dem bekannten Resultat: Wer “gutes” Routing will, zeichnet einfach highways drüber und fertig.

59

Sehe ich auch so.

Hier meine Überlegungen zu dieser etwas theoretischen Diskussion :wink:

  1. Virtuelle (oder sonstige) Ways über Flächen helfen bei der Bildung von einfachen Relationen. Daher werden sie immer wieder gemappt werden. Siehe http://www.openstreetmap.org/browse/way/23113737

  2. Dem Router kann es egal sein, ob die Fläche auch mit einzelnen Ways zusätzlich gemappt ist. Er kann unabhängig davon einen kürzeren Weg über die Fläche suchen.

  3. Der Renderer kann sich raussuchen, ob er Wege, die auf/unter einer Fläche liegen nicht darstellt. Im einfachsten Fall malt er einfach die Fläche zuletzt. Man darf nämlich nicht vergessen, dass nicht jeder Anwender ein Computer-Vollprofi ist. Die Wege über der Fläche müssten halt nur am Flächenrand anfangen und enden.

  4. Hier: http://www.openstreetmap.org/#map=19/49.40725/11.14525 kann man eine kreativen Umgang des Renderers sehen. Die Fläche wird je nach Zoomstufe als Fläche oder als turning_circle dargestellt. Hier: http://osm.org/go/0D63P46u4 wird es für den Router schwierig zu erkennen, dass man da umdrehen kann.

  5. KISS. Die Daten sollten nicht nur von Vollprofis genutzt werden können. Wie mache ich eine “Drahtgitter-Karte” von Wegebeziehungen oder eine einfache Darstellung eines Wegenetzes? Siehe Punkt 1, dargestellt als “Radfahrerkarte”.

  6. Wie mappe ich eine Fußgängerzone, auf der es nur eine Fahrspur auf den Platz gibt, die für den Lieferverkehr/Fahrradverkehr freigegeben ist (und diese natürlich auch Fußgängerzone ist)? Doch nicht als zwei Flächen!?

Es sind doch genau genommen zwei verschiedene Denkweisen (Fläche<->Way). Einerseits mappen wir die Wegebeziehungen als Achsen der “wichtigsten” Nutzer, andererseits sind alle Straßen doch Flächen. Hier: http://osm.org/go/0D6zmqw1L– verläuft die Straße im Zickzack, weil das die Achse für die Autos ist. Fußgänger laufen gerade an den Häusern entlang. Also müsste entsprechend der Fußgängerzone hier auch die Straße im Ganzen als Verkehrsfläche gemappt werden und der Router berücksichtigen, dass es für die Fußgänger kürzer als für die Autos ist :wink:

Zusammenfassend würde ich einfach Beides unter der Bedingung von 3. (letzter Satz) gleichzeitig dulden.

Area=yes ist meiner Meinung nach doch für eine Unterscheidung ausreichend.

60

Moins,

Mein Oranger Assistent behauptet, dass die (Basis-)Lösung für die Erzeugung virtueller Wege über Flächen mit Hindernissen ebenso trivial ist wie Routensuche oder Erreichbarkeitsanalyse. Die Herausforderung liegt in der Bereitstellung der Daten (Platz und alle sich mit dem Platz überschneidende Hindernisse) und nicht im Erzeugen der Wege.

Soll ich den vorlauten Kerl machen lassen oder ihn lieber ins Regal setzen?

Gruß Wolf