Am 03.11.2010 15:08, schrieb Peter Wendorff:
Am 03.11.2010 14:36, schrieb Carsten Moeller:
Am 03.11.2010 13:58, schrieb Peter Wendorff:

Aufhänger dieses Threads waren Fährverbindungen, dazugekommen sind
Autozüge.
In beiden Fällen geht es darum, dass die Zubringer eigentlich eben keine
Hauptverkehrsadern sind; die Routing-Fraktion aber die entsprechende
Verkehrsbedeutung betrachtet haben möchte.

Ich bin mir nicht sicher, ob das überall möglich ist, aber kann man
nicht die Route entsprechend anpassen?

Ich glaube schon, dass das möglich ist. Die Wege, egal ob Straße,
Schiene, oder Wasser müssen nur irgendwie "verbunden" sein.
Dann funktionieren alle Router.
gut ;)

Die Fährroute läuft eben nicht von Ufer zu Ufer, sondern von
Straßenabzweig, einschließlich aller service-highways,
warteplätze/schlangen und Co.
Warum dann nicht eine fähr/schiffsstrecke und eine Fähr-Route, die die
Schiffsstrecke enthält?
Letztere kann am Zubringer der Bundesstraße anfangen und aufhören und
bekommt ein Gesamtgewicht.

Meinst du damit, hier eine Relation anzulegen oder einen zweiten Weg?
Falls Relation, dann bitte bedenken, dass diese von Routern kaum
betrachtet werden, weil viel zu aufwändig und teilweise kaum
beherrschbar. (Speicher, Laufzeitverhalten, etc...)
Ich rede von einer Relation, ja; und ich halte das nicht für
unbeherrschbar, sondern im Gegenteil für eine Vereinfachung des Routings
(zumindest des Navigationsgraphen).
Dies betrifft auch die Topologie-Erstellung. Es ist schon ein halber
Beinbruch, überhaupt die Abbiegevorschriften hinzukriegen (Relation).
Abbiegevorschriften sind was anderes; dabei werden Beschränkungen
eingebaut.

Abbiegevorschriften sind technisch das Gleiche. Das sind auch nur Relationen mit einer Menge anderer Verweise, in diesem Fall meistens FromWay, ViaNode und ToWay. Ob nun noch zusätzlich ein no_left_turn oder no_right_turn folgt ist Hupe. Eine andere Vorschrift oder Zusatzinfo könnte genau so "grün", "blau", "Weltkulturerbestraße Russland-Atlantis" oder eben "Fährverbinder" heißen.


Ich stelle mir die hier vorgeschlagenen Routen eher so vor, dass sie als
"abkürzende Wegstücke" eingebaut werden können.
Eine Relation vom Typ ferry|car_train...., die zwei nodes mit
role=entrypoint (völlig willkürlich und nicht über die Formulierung
nachgedacht) enthält, lässt sich im RoutingGraph als Weg von entrypoint1
nach entrypoint2 und Gewicht n betrachten.
Abfragen kann man diese Routen recht einfach: Relationen mit
type=ferry|car_train.... abzufragen ist nicht schwieriger als highways
mit type=secondary.

Man muss allerdings dann alle Wege, die auf der Strecke sind finden und schlimmstenfalls über mehrere Gigabytes hinweg cachen, um sie dann irgendwann mal aufzulösen. Man will ja schließlich am Ende die Koordinaten haben, um die Route auch darstellen zu können. Ein herkömmlicher Rechner wird dies kaum leisten können, es sei denn er liest den Datenstrom zyklisch so lange, bis alles aufgelöst ist. Eine Datenbank (z.B. PostGIS) ist hier übrigens auch nicht schneller oder besser. Das sind alles Läufe, die nicht mehr in Stunden, sondern im 0,5-Tages-Intervall zu messen sind.


Wenn man dafür bei vollständigem tagging die Service-Wege außer acht
lassen kann, die ja von den Routing-Fetischisten hier als so böse
betrachtet worden sind, finde ich, ist das ein recht guter Kompromiss.

Das Routing über die service-Wege dazwischen ist vermutlich sowieso
nicht ohne weiteres möglich, weil das meiner Erfahrung nach oft über
Plätze und gesteuert von Einweisern geschieht.

Dem Algorithmus ist das Hupe, der fährt auf allem was da ist. Es ist
lediglich bei der Aufbereitung der Infos für ein Routing relevant:
Also nehm ich den Weg oder werfe ich ihn von vornherein weg. Dafür
müssen halt die Tags interpretiert werden. Und ganz wichtig: Hier
sollten die Tags innerhalb der Ways ausreichen und nicht erst
hintenrum über Relationen besorgt werden.
Eben: Du willst service wegwerfen, und ich bietet dir hier einen
Kompromiss, der durchaus sinnvoll ist; weil auch die Gewichtung von
service-wegen an den Zustiegspunkten einer Fährroute eine andere ist als
bei service=alley oder sowas.

Nein, ich will nicht Service wegwerfen, um Himmels Willen, ..., nur es muss was her, das a) entweder Services grundsätzlich ausschließt oder b) explizit einschließt. a) ist Gott sei Dank häufig anzutreffen und wird auch fleißig mittels der access-Tags restriktiert. Nur für b) gibt faktisch keine Vorschrift. Hier fehlt die Umkehrlogik, damit ich weiß, dass hier was Wichtiges zu berücksichtigen ist.

Die Alternative ist, für den Router falsch zu taggen ("aber wenn ich
Fähren benutzen will, ist die Verkehrsbedeutung doch viel höher" vs.
"das ist'n Parkplatz mit 'ner Warteschlange, die Zufahrt ist kaum
ausgebaut")
Gruß
Peter

_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de



_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Antwort per Email an