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

MKnight · 2013-11-06T00:56:05.000Z

Schina02:

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

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?

Netzwolf · 2013-11-06T01:47:54.000Z

Nahmd,

MKnight:

Schina02:

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

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?

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

peb12345 · 2013-11-06T11:16:41.000Z

MKnight:

Schina02:

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

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?

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

MKnight · 2013-11-06T12:58:53.000Z

oh, danke, ganz übersehen.

seawolff · 2013-11-06T17:49:17.000Z

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 …”

Netzwolf · 2013-11-06T18:08:12.000Z

Nahmd,

seawolff:

Der Taggingvorschlag “highway=virtual” mit passenden access-Tags [1] gefällt mir am besten.

[×] 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

geri-oc · 2013-11-07T10:29:04.000Z

Netzwolf:

… 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.

maxbe · 2013-11-07T10:50:32.000Z

geri-oc:

Netzwolf:

… aber “highway=virtual” ist besser.

Ich finde highway=virtual auch konkret einsetzbar für Fahrspuren (besser als die unsichtbaren, maschinenlesbare lanes) …

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

Oli-Wan · 2013-11-07T10:52:43.000Z

maxbe:

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.

Gleiches Schema wie bei construction: highway=virtual, virtual=footway.

chris66 · 2013-11-07T11:06:15.000Z

geri-oc:

Ich finde highway=virtual auch konkret einsetzbar für Fahrspuren.

Das heißt bei Fußgänger-Areas sollen Navis diese nutzen, bei Abbiegespuren aber nicht?

Da wird mir zuviel in einen Topf geworfen.

Abbiegespuren sind reale Objekte, aber eben** keine Fahrbahnen**.

Tordanik · 2013-11-07T11:26:07.000Z

seawolff:

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.

Das finde ich einen vertretbaren Kompromiss - zumindest wäre ein eigenes Tag deutlich erträglicher als die Zweckentfremdung bestehender Tags. (Allerdings würde ich virtual:highway=* vorziehen, vergleichbar mit der neuen disused-Syntax, aber das ist eher eine Detailfrage.)

Idealfall ist meiner Meinung nach dennoch der Einbau in die Router. In dieser Diskussion wurde einmal die “kombinatorische Explosion” als Argument gegen eine Automatisierung angesprochen. Ich sehe das im Gegenteil als Argument gegen manuelle Einträge - es werden ziemlich viele virtuelle Ways nötig, die eine Software deutlich effizienter produzieren kann als ein Mapper.

Ich würde diese Hilfswege daher eher als temporäre “Stützräder” sehen, bis gängige Router es von selber können.

slint · 2013-11-07T11:56:56.000Z

Netzwolf:

Für den Router taggen ist böse.

Gibt’s eigentlich kein passendes Tag für einen Holzplatz?
Die können Teilweise schon richtig groß sein und sind nur weiße Flecken hier

EvanE · 2013-11-07T12:55:29.000Z

Tordanik:

seawolff:

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. …

Das finde ich einen vertretbaren Kompromiss - zumindest wäre ein eigenes Tag deutlich erträglicher als die Zweckentfremdung bestehender Tags. (…)

Idealfall ist meiner Meinung nach dennoch der Einbau in die Router. In dieser Diskussion wurde einmal die “kombinatorische Explosion” als Argument gegen eine Automatisierung angesprochen. Ich sehe das im Gegenteil als Argument gegen manuelle Einträge - es werden ziemlich viele virtuelle Ways nötig, die eine Software deutlich effizienter produzieren kann als ein Mapper.

Ich würde diese Hilfswege daher eher als temporäre “Stützräder” sehen, bis gängige Router es von selber können.

Nun ja, nicht jedes Blumenbeet oder anderes Hinderniss auf einer Fläche ist zur Zeit bei OSM eingetragen. Von daher kann ein Mensch mit seiner Kenntnis + einem guten Luftbild, da oft einen besseren Job machen.

Es gibt übrigens durchaus auch den Fall, wo Vorzugswege auf einer Fläche explizit hervorgehoben oder markiert sind. In so einem Fall würde ich die Wege explizit mit ihrem üblichen / normalen Wert eintragen.

Eine ‘kombinatorische Explosion’ braucht es nur, wenn man die kürzesten Wege ermitteln will. Ein Mensch wird eher dazu neigen, einfache statt kürzeste Wegführungen zu erfassen. Dabei wird er zum Beispiel auch die Marktstände berücksichtigen, die dort mehrmals in der Woche stehen. Ein Automatismus, kann das nur, wenn die alle als erkennbares Hindernis eingetragen sind.

highway=virtual + virtual=path/footway/service/… scheint mir eine gute Lösung zu sein.
Gegen virtual:highway=path/footway/service/… hätte ich aber auch keine Einwände.

Edbert (EvanE)

geri-oc · 2013-11-07T14:07:33.000Z

chris66:

…
Das heißt bei Fußgänger-Areas sollen Navis diese nutzen, bei Abbiegespuren aber nicht?

Da wird mir zuviel in einen Topf geworfen.

Abbiegespuren sind reale Objekte, aber eben** keine Fahrbahnen**.

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?

Da Router sonst relativ wenige Möglichkeiten haben, Wege zu unterscheiden sind sie auf highway schon sehr angewiesen.

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.)

Nadjita · 2013-11-07T14:24:59.000Z

geri-oc:

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

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.

geri-oc · 2013-11-07T14:49:51.000Z

Nadjita:

geri-oc:

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

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.

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.

Nadjita · 2013-11-07T14:54:33.000Z

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.

gormo · 2013-11-07T16:16:12.000Z

EvanE:

highway=virtual + virtual=path/footway/service/… scheint mir eine gute Lösung zu sein.
Gegen virtual:highway=path/footway/service/… hätte ich aber auch keine Einwände.

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

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

chris66 · 2013-11-07T16:25:26.000Z

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.

EvanE · 2013-11-07T18:49:27.000Z

gormo:

EvanE:

highway=virtual + virtual=path/footway/service/… scheint mir eine gute Lösung zu sein.
Gegen virtual:highway=path/footway/service/… hätte ich aber auch keine Einwände.

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

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)