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.
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.
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.
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.
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.
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.
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…
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
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”.
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.
Hier meine Überlegungen zu dieser etwas theoretischen Diskussion
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
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.
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.
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”.
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
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.
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?
hier gibt’s ein Paper “Shortest Paths in the Plane with Polygonal Obstacles”. Die Abbildungen auf Seite 987 (im Pdf Seite 6) sehen ja schonmal ganz nett aus.
solve (Ring[] outers, Node[] points, Ring[] obstacles1, Line[] obstacles2, Node[] passages)
returns Line[]
outers ← definieren die Fläche[n]
points ← Zugangspunkte auf dem Rand der Fläche, und
← zu erreichende POIs im Inneren der Fläche
obstacles ← flächenhafte und linienhafte Hindernisse
passages ← Durchgänge durch Linienhindernisse (Gatter im Zaun)
Ob die folgende Implementierung etwas taugt, weiß ich noch nicht. Auf jeden Fall ist da schonmal von Obstacles, Start und Ende-Knoten und Visualisierung die Rede…
So, hab die Hausaufgabe4 mal installiert und laufen lassen. Das Ergebnis sieht dann so aus:
Im Vergleich zu der Liste oben fehlen wahrscheinlich die linienhaften Hindernisse und Durchgänge. Weiß nicht, ob das besonders schwierig ist nachzurüsten.
Natürlich hätte das geholfen. Der Renderer war mit den neuen Stimmkreisgrenzen irritiert und hat den ganzen Stadtplan damit beschriftet. Die meisten von euch haben es wohl gar nicht bemerkt, weil das nicht flächendeckend war, sondern regional auf Hotspots beschränkt. Da war es katastrophal. Straßen wurden umbenannt (mit der election boundary), Wälder in kleine Parzellen gestückelt und mit Stimmkreisnamen beschriftet. Es ist klar, dass irgendwann auch Renderer das begreifen werden. Hätte man die Ausdrückmöglichkeit einer visibility könnte man solchen Problemen von vorneherein aus dem Weg gehen, weil so etwas nie in normalen Karten erscheint. Es war nur ein Beispiel. Das visibility-Flag würde halt generell überall funktionieren. Nicht dass es zur Regel wird, aber eben für Problemzonen. Es zwingt keinen es umzusetzen, aber es erleichtert Mainstream-Renderern, die Weisheit des Mappers optisch umzusetzen. Am Ende genießt man das OSM-Werk in erster Linie optisch als Karte und nicht durch Lektüre von Datenbank-Dumps. Jemand der Spezialkarten, z.B. der Wahlkreise, oder beliebiger anderer OSM-Objekte erstellt, kann natürlich solche “üblicherweise unsichtbaren” Objekte explizit rendern.
Das Konzept der “virtuellen Wege” halte ich auch für sehr interessant. Die stellen auch unsichtbare “Objekte” dar, die aber lediglich Hilfskonstruktionen sind, um logische Verbindungen von Wegen irgendwie computerbasiert erfassen und verarbeiten zu können. Ich sehe es nicht als Konkurrenz zum Sichtbarkeits-Konzept, sondern als eigenständige Kategorie.
Beides macht Sinn. Virtuelle Wege sind da angezeigt, wo in Wirklichkeit überhaupt nichts in Richtung Weg angedeutet wird. Z.b. große Plätze ohne angedeutete Straßen. Die virtuellen Wege dienen hier lediglich der logischen Verknüpfung von Zugangswegen, damit Router damit arbeiten können. Die Datenstruktur muss eben so ausgelegt sein, dass sie automatisch verarbeitbar ist. Beispielsweise, zwei Gebäude zwischen denen ein Durchgang existiert, aber keine Informationen über Türen/Tore etc. vorhanden sind. Statt irgendwo falsch einen Durchgang hinzusetzen könne man die einfach durch einen logischen Weg verknüpfen. Ein Fußgänger-Route könnte die Information nutzen und Abkürzungen vorschlagen. Es gibt viele große öffentliche Gebäudekomplexe mit Durchgangsmöglichkeiten. Nicht immer kann oder will man da ins Gebäude echte Wege einzeichnen.
Andererseits gibt es viele Fälle in denen Wege real existieren, man sie aber nicht in der Karte sehen will. Beispiel wieder ein Marktplatz, wo schwach angedeutete Wege drübelaufen, z.B. für den Lieferverkehr, z.B. mit abgesenktem Kopfsteinpflaster. Oder der zuvor zitierte Bergpfad, der über eine Holzstapel-Fläche führt. Es ist nur logisch, diese Wege nach traditionellem Konzept zu erfassen. Als Fußweg, Lieferweg, verkehrsberuhigte Straße etc. Nicht nur um dem Router zu helfen, sondern weil es einfach so logisch ist. Trotzdem möchte man oft solche Wege nicht in der Karte sehen. Statt ein Sonderobjekt “virtueller Weg” würde ich hier den normalen Weg bevorzugen, der als “bitte dieses Segment nicht zeichnen” ausgedrückt wird. Es wäre eine saubere Lösung. Was man zuvor gehört hat, dass eine Fläche den sowieso überblenden würde, falls die ID höher ist. Gut, das mag funktionieren, ist aber weder logisch noch elegant.
Zu diesem Themenkomplex fände ich 3 Auszeichnungsmethoden interessant, die man alle unterstützen könnte (sowohl von der Mapper-Seite als auch in der Programmierung der Renderer und Router):
der “virtuelle Weg” für Wege die nur der logischen Verknüpfung wegen angelegt werden, um Straßen oder Gebäude/-teile zu vernetzen.
Das dient in erster Linie Routern um es zu nutzen, Renderern die damit schönere Karten machen, vielleicht anderen …
display=yes/no: Sichtbarkeit generell ein/ausschalten, z.B. reale Wege über einen Marktplatz, wo der ortskundige Mapper eine Entscheidungshilfe liefert, dass diese konkreten Wegesegmente im Stadtplan nicht gut aussehen würden
active=yes/no: Schalter, um Objekte grundsätzlich deaktivieren zu können.
Deaktivieren mit active=no könnte man so nutzen: z.B. die Stimmkreise/Wahlkreise gelten nur für eine Wahl, sind vielleicht für die nächste Wahl nur geringfügig modifiziert. So könnte man die Objekte in der Datenbank lassen, sagt aber dazu, dass sie momentan nicht aktiv sind. Ähnlich, wenn man auf einer Großbaustelle (z.B. Berliner Stadtschloß) schon einmal die Baupläne in OSM mappt, aber ausdrücken will, dass diese derzeit noch nicht in Anwendungen genutzt werden sollen.
Im Normalfall muss der Mapper keins dieser Tags setzen. Das sind alles Sonderfälle, die aber bei falscher Umsetzung in Karten negativ auffallen würden. Auswertesoftware ist frei, diese “Empfehlungen” der Mapper umzusetzen oder nicht. Im Normalfall wäre es gut, sie zu berücksichtigen (z.B. im Default-Renderer auf der OSM-Homepage). Wenn nicht, braucht man auch nicht über die Mapper zu schimpfen, sondern um die schlechte Umsetzung der Empfehlungen (der Weisheit der Mapper). Natürlich kann i.d.R. der Rendering-Stil die meisten Entscheidungen selbst treffen. Wie eine Autobahn gerendert wird entscheidet er selbst. Es gibt aber immer Sonderfälle, in denen ein Computer keine intelligenten Entscheidungen trifft, wo der Mensch eingreifen muss. Dazu müssen Ausdrucksmöglichkeiten bzw. Entscheidungshilfen in Software vorgesehen werden.
Die typische Situation in Fußgängerzonen und Marktplätzen ist vermutlich nicht so komplex und leichter durch echte oder virtuelle Wege darzustellen. In der Theorie schaut das ganz nett aus, aber ob das auch so direkt umsetzbar ist? Von der Performance her könnte das problematisch werden. Das sind schon deutlich mehr virtuelle Wege als man sonst real in Karten einzeichnet. Das Memory-Limit der Smartphones wird schon jetzt bis an den Rand ausgereizt. Ist auch die Frage ob man das wirklich so exakt routen muss, oder ob der Fußgänger mit einem groben Wegenetz auch den richtigen Weg vom Marktplatz aus in die Ausfallstraße findet.
Damit automatisches Routing funktioniert müssen auch alle Details stimmen. Beispielsweise, wie hängen mehrere nebeneinander gezeichnete Polygone zusammen? Wenn die einzeln begehbar sind, kann man die dann auch queren? Brauchen wir dann doch virtuelle Wege dazwischen? Und dann muss das noch alles konsequent von Mappern umgesetzt werden.
Die Kunst der Kartographie ist doch, Karten gut zu generalisieren und nicht Landschaftsmalerei zu betreiben. Die Kunst des Weglassens. Man könnte natürlich auch noch die ganzen Blumenkübel mappen. Aber irgendwann wird es doch zu unübersichtlich auf einer Karte. Ich finde es gut, dass Wege in Einheitsbreite gerendert werden, die Pfade nur 1 Pixel breit auf dem Smartphone. Nur so kann man übersichtlich zeichnen. Auf dem Smartphone ist die Vektorkarte schon jetzt relativ langsam und teilweise auch unübersichtlich.
