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

In der Mailingliste ist das Thema übrigens gestern auch aufgetaucht. Nur wandern die dort über Strände statt über Fussgängerzonen…

Moins,

Der Algorithmus produziert genau die Ways, die es erlauben, zwischen Beliebigen der Anschlusspunkte auf kürzestem Wege den Platz zu überqueren. Und ja, man läuft (außer auf konvexen Plätzen ohne Hindernisse) durchaus im Zickzack: stell Dir einen Platz vor in Form eines Z (natürlich mit fettem Pinsel gepinselt, damit es flächig wird), Anschlusspunkte oben links und unten rechts. Und jetzt lauf von einem Anschlusspunkt zum anderen über den Platz… :slight_smile:

Das ist korrekt. Um die Menge virtueller Wege zu erzeugen, muss man die Flächen zuerst verbinden. Spannend wird es bei unterschiedlichen Access-Regeln: die flächengrenzenüberschreitenden Wege müssen dann mit der Vereinigung der access der beiden Teilflächen versehen werden. Das ist dann nach der Pflicht die Kür :slight_smile:

Lineare Fußgängerzonen/Einkaufsstraßen wie die Hohestraße in Köln würde ich auch als Linien erfassen, etwas wie die Domplatte oder den Bahnhofsvorplatz aber flächig.

Wenn es eine Verbindung gibt, darf die auch in der Karte dargestellt werden.

Virtuelle Ways für besseres Routing über Flächen kann und sollte man während der Vorverarbeitung der Routing-Daten erzeugen. Die haben in der DB nichts verloren.

Das ist eine Überlegung wert. Da man beim “Disablen” ohnehin eine neue Version der Objekte erzeugt, kann man ein beliebiges Tag ändern. Ich schreibe in solchen Fällen ein “x-” vor das Haupttag. Ein Beispiel: es hatte mal jemand offensichtlich einen Track in einen OSM-Way umgewandelt und in die DB gespeichert. Und das verwendete Tool hat jeder node einen Namen gegeben. Sah in der Karte nicht wirklich gut aus. Deshalb hab ich aus den “name=” jeweils “x-name” gemacht. Vorteil: alle existierenden 598712659278365872 Renderer kommen ohne Anpassung damit zurecht.

Gruß Wolf

OpenTripPlanner kann wohl über Plätze routen, siehe Blog “b-roll: David solves the plaza problem, with help from de Berg and Matt Conway”. Dort ist auch der Ansatz etwas beschrieben. OpenTripPlanner ist Open Source (LGPL) und in Java. Da ÖPNV-Routing integriert ist, gibt es aber leider wohl nur regionale Installationen.

Gruß,
Norbert

Nahmd,

Genau das haben wir oben diskutiert. Laut Beschreibung nutzen die alle Ecken aller Löcher, da kann man sich aber auf die konvexen Ecken beschränken. Dazu kann man alle Ways streichen, bei denen am Zielpunkt die beiden Segmente der Beschränkungslinie auf unterschiedlichen Seiten des Ways liegen, dann löst sich auch das Problem mit dem hochaufgelösten Kreis in Wohlgefallen auf.

Jetzt muss nur noch jemand den Area-Routing-Code herausoperieren, und schon kann er den von maxbe gewünschten Preprozessor bauen.

Gruß Wolf

Im Gegenteil. OSM verwendet ein für das Routing optimiertes Datenmodell. Straßen werden trotz endlicher Breite als Liniennetz gemappt, Fährlinien als way einer typischen Fahrstrecke.
Selbst 500m breite Flüsse werden als Linie erfasst, einmündende Gewässer bis zur Mittellinie des Hauptstroms ergänzt (obwohl das Wasser in der Realität nicht zur Strommitte fließt).

Die Ergänzungen durch “area:highway” oder “riverbank” kamen später.

Es gibt funktionierende “dirty hacks” und elegante Lösungen. Letztere würde ich bevorzugen.
Falls die Funktion gewünscht wird, fallweise bestimmte Elemente nicht anzeigen zu lassen,
kann man das sauber über ein visibility-Tag definieren. Es darf ruhig die Ausnahme für Sonderfälle
bleiben. Man ist nicht gewungen, jedesmal die Sichtbarkeit zu setzen.
Ich fände es eleganter als die Tag-Namen umzufrisieren, in falsche oder nichtexistente Namen,
nur um den Renderer auszutricksen. Das wäre “Mappen für den Renderer”.

Ich sehe es auch so, dass man Fussgängerzonen (wie alle anderen Strassen auch) normalerweise als Way und nur da wo es eher ein Platz ist als Fläche erfassen sollte. Und wenn man die Fläche dazu haben möchte die eben zusätzlich als “area:highway”=*.

Das ist mal leicht dahergesagt. Aber für wen willst du denn Mappen? Nicht für gerenderte Karten? Nicht für Router?
Für wen denn? Als reine Beschäftigungstherapie?

OpenStreet"Map" ist von der Grundidee her eine Karte, die natürlich weitaus mehr bietet, also Themenkarten (Geschichte, Denkmäler etc), Routing auf Karten, Einkaufsführer, Restaurantführer, internationales Straßenlampenverzeichnis etc.

Es gibt dabei häufig genutzte Anwendungen, z.B. als topografische Karte, Stadtplan oder Routing-Karte,
und eher seltene Anwendungen (Wahlkreise, politische Karten? ).

Die OSM-Datenbasis muss eben all den Anwendungen eine gute Grundlage bieten,
vor allem natürlich den häufig genutzten. Man mappt also dass der Renderer alles schön
darstellt, dass der Router gute Routen findet etc.
Das heisst nicht, dass man “dirty hacks” zur Politik erklärt, aber wenn der
Router eine bestimmte Logik im Verbindungsnetz benötigt, warum sollte man
nicht “routerfreundlich” taggen? Es ist schon ein großer Fortschritt, dass man routingfähige
OSM-Karten erzeugen kann. Das war früher nur mit kommerziellen Karten möglich.

Wenn Router heutzutage Probleme mit den Flächen haben, kann man ruhig punktuell
an Problemstellen etwas nachhelfen. Was ist so böse daran? Wichtig ist doch, dass
OSM-Routing in der Praxis funktioniert (also mit Gerät vor Ort und nicht nur theoretisch).

Nahmd,

Nun ja.

Ich verwende das System der “x-”-Prefixe, das im Internet seit Jahrzehnten bewährt ist, das System ist selbsterklärend, ich kann jedes Feature einzeln ein- und ausschalten, und das Beste: das System ist mit allen existierenden Auswertern und Renderern kompatibel. :slight_smile:

Das “display=no” ist nicht selbsterklärend – es könnte auch bedeuten, das der Laden eine Auslage hat –, ich kann damit nur gleich das ganze Feature ausschalten, und keiner der existierenden Auswerter oder Renderer versteht es. :frowning:

Wer gewinnt die Ausschreibung? :stuck_out_tongue:

Gruß Wolf

Aber bei den unsichtbaren Wegen über Flächen würde das nicht gehen, oder?
Der Tagname wird umdefiniert und ist dann auch für den Router nicht mehr zu nutzen.

Ein ähnlicher Fall bei den Stimmkreisen: dem Mapper war es selbst peinlich, eine ganze Stadt auf dem Plan zugekleistert zu haben. Er wollte aber auch nicht das name-Tag umbenennen, weil dann die Funktion beinträchtigt wird. Die Renderer haben das Darstellungsproblem nicht gelöst (bzw. ihre Policy geändert), also hat er dann aus Verzweiflung die ganzen Objekte wieder gelöscht. Es wäre einfacher gewesen, diese temporären election boundaries gleich als unsichtbar zu deklarieren. Also als Kennzeichnung “wird regulär nicht dargestellt”, mit der verbleibenden Möglichkeit von Spezialprogrammen, diese geografischen Objekte doch auszuwerten. Man kann so also Semantik verbauen, ohne die Optik einer Karte zu beschädigen.

Kennst du MathML? Bei Formeln gibt es eine duale Beschreibung. Es gibt die semantische Beschreibung, die die Beziehungen der Terme ausdrückt. Formeln können so in Software automatisch verarbeitet und berechnet werden. Daneben gibt es noch eine “presentation” Auszeichnung, wie eine Formel auf Papier aussehen soll. Erinnert mich irgendwie auch an OSM beim Problem sematische Auszeichnung vs. Präsentation auf Karte.

Nahmd,

Die “unsichtbaren Wege” sind eine Krücke fürs Routing, die wird man bei der Aufbereitung der OSM-Daten fürs Routing erzeugen und dann integrieren, aber keinesfalls in die DB schreiben. Da haben die nichts zu suchen.

Du hast fleißig durch Relevanzdiskussion dazu beigetragen.

Ich hätte die Relationen erhalten und das “type=boundary” gegen ein “type=x-boundary” ausgetauscht; das beruhigt die Kartennutzer und man hat die Zeit, das Problem in Ruhe anzugehen.

Aaaaaaaber: ich arbeite so, andere arbeiten anders. Ich will niemanden von irgendwas überzeugen. Gerade bei OSM gibt es zumeist mehrere Wege zum Ziel.

Das funktioniert jetzt schon, indem Du Schlüssel benutzt, die von Renderer und/oder Routern nicht ausgewertet werden.

Ich sehe keinen Gewinn bei einem neuen Tag. Ich sehe aber die Probleme, die Du haben wirst, alle Verwalter von Karten davon zu überzeugen, das Handling Deines neuen Tags zu integrieren. Weil es Aufwand macht und keinen Vorteil bringt. Meine Kristallkugel sagt mir, dass Dein Versuch in großer Frustration enden wird. :confused:

Aber wie immer: ich will Dich natürlich nicht davon abhalten. Arbeite ein Konzept aus, stell es vor, mail alle Verwalter von Karten an, und versuche, jeden einzelnen davon zu überzeugen. Viel Glück!

Gruß Wolf

Als Beispiel wie es aussieht wenn über den Platz auch noch (beschriftete) Straßen laufen: http://www.openstreetmap.org/#map=19/48.90506/9.08086

Nicht von mir, hab es aber auch nicht rausgemacht, da mir die Problematik doch irgendwie einleuchtete. Und das mit der Beschriftung der Straßen wäre halt eben auch noch ein Problem. Vielleicht sieht man die Straße nicht, aber irgendwo her sollte ja auch noch der Name kommen. Ob der Router weiß, dass er diesen von der einschließenden area holen soll? :slight_smile:

Komisch, wenn ich nichts übersehen habe ist das genauso getaggt wie hier: http://www.openstreetmap.org/#map=19/50.97938/11.32984
Wird aber unterschiedlich gerendert. Kann ma jemand mein Brett abnehmen?

Nahmd,

Im ersten Fall haben die Straßen eine größere Id als die Fläche, im zweiten hat die Fläche die größere Id.
Liegt es möglicherweise an der Zeichenreihenfolge?

Gruß Wolf

Beim einen haben die Wege Namen, beim anderen nicht.
Unbenannte Wege werden auch von Mapnik noch nicht beschriftet (muß ein Bug sein).

oh, danke, ganz übersehen.

Moin,

ich würde es vorziehen, dass ein Netz virtueller Wege über einen Platz vom Mapper und nicht vom Präprozessor erstellt wird:

  • ob ein Präprozessor alle Fälle abdecken kann, ist unklar (aneinandergrenzende Flächen, Hindernisse in der Platzfläche, Treppen, die im Inneren des Platzes beginnen).
    Für überbreite Freitreppen haben wir noch nicht einmal ein etabliertes Datenmodell.

  • viele innerstädtische Plätze haben so viele Beete, Stadtmöbel, Brunnen, Felder von Fahrradbügeln, etc., dass praktisch nur wenige Wege benutzt werden

  • ein zusätzliches Tag ist einfach in die Router zu integrieren. Ein vorgeschalteter Präprozessor erfordert viel größere Anpassungen in der Datenverarbeitung.

  • das Konzept der virtuellen Wege ist auf andere Probleme anwendbar (Wanderwege über den Strand, Almwiese, u.ä., Querungen von Grünstreifen zwischen Straße und Fußweg, Treppen in der Mitte eines Bahnsteigs). Auch für Wasserwanderwege braucht man manchmal eine Verbindung zwischen Einsetzpunkt am Ufer und der Flussmitte.

Der Taggingvorschlag “highway=virtual” mit passenden access-Tags [1] gefällt mir am besten.
Für Router genügt es, diesen Wert analog zu “highway=path” zu behandeln, alle anderen Anwendungen wären nicht betroffen.
Für nachfolgende Mapper ist es vermutlich selbsterklärend.

[1] 4.11.13 Wolfgang Hinsch in talk:de - “path am Strand fuer den Router …”

Nahmd,

[×] dafür

Ich hatte an “highway=pathless” gedacht, aber “highway=virtual” ist besser.

Es braucht allerdings ein bisschen™ Zeit, bis die rund 150.000 highway-Flächen in der OSM-DB mit virtuellen Wegen ausgestattet sind. Deshalb spricht auch nichts gegen Preprocessing für Routing-Anwendungen. Das verträgt sich sogar sehr gut, wenn sobald in einer Verkehrsfläche Wege gefunden werden, keine weiteren Wege ergänzt werden.

Gruß Wolf

Ich finde highway=virtual auch konkret einsetzbar für Fahrspuren (besser als die unsichtbaren, maschinenlesbare lanes) Dann könnten NAVIS diese ignorieren - Router und Karten würden es “Menschen lesbar” anzeigen. Und auch bei der Ergänzung von highway:area dürften keine Probleme auftreten.

Wenn man das highway-Tag dafür nutzt, verliert man aber die Möglichkeit, den Typ des Weges nochmal zu unterscheiden. Wenn ich mit Routing z.B. auf “highway=path” wandern möchte, auf “highway=footway” aber nicht (oder service, track… oder was sonst so als Fläche eingetragen ist), stehe ich bei “highway=virtual” ziemlich ratlos da. Da Router sonst relativ wenige Möglichkeiten haben, Wege zu unterscheiden sind sie auf highway schon sehr angewiesen.

Alternative hab ich aber auch keine anzubieten, weil ich eigentlich auch keine Tags mag, die andere für ungültig erklären (also sowas wie “existiert_aber_gar_nicht=yes”)

Grüße, Max