[Talk-de] Routerhärtetest - Topologie oder STVO?

Heiko Jacobs heiko.jacobs at gmx.de
Fr Jun 26 15:15:29 UTC 2009


Moin

Kam die Tage nicht zu ausschweifenden Antworten, daher erst heute ;-)

> Die Rheinbrücke ist ein Spezialfall, da ist Streit vorprogrammiert.

In der Tat ;-)

> Aber ich sehe es so wie Sven, Martin und Du: Speziell an der Rheinbrücke bin 
> ich der Meinung, dass es bei getrennten Wegen bleiben sollte. Und das sollte 
> Heiko respektieren. Wenn die Diskussion hier nicht dazu führt, dass in 
> Potlatch fleissig die Taste »u« gedrückt wird, war sie, äh, vergebens :) .

Schaun mer mal. Im Moment lerne ich gerade viel bzgl. Routing dazu
anhand der Brücke, diese Fortbildungsmaßnahme will ich mir durch
spontanes zurücktaggen nicht verbauen ;-)

> Heiko möchte, soweit ich ihn verstehe, gerne die Radwegesituation in unseren 
> Daten verbessern. Das ist mehr als wünschenswert.

Das ist irgendwo ein mittel- bis langfristiges Ziel, ja.
"Kurzfristig" habe ich mir schon abgeschminkt ;-)

> Vor diesem Hintergrund stellt sich die Frage, was wir primär abbilden wollen: 
> Die Topologie ("Hier ist ein extra Radweg") oder die STVO ("Hier ist ein 
> straßenbegleitender Radweg"). Da ich das Projekt viel mehr als Geodatenbank 
> und weniger als nur ein (Staßen)kartenprojekt auffasse, komme ich zu dem 
> Schluß, dass primär die Topologie und sekundär die STVO abgebildet werden 
> sollte.

Beides gehört irgendwo zusammen. Die StVO (und Waldgesetze etc.) hat
einen Einfluss darauf, wer wo fahren darf. Nur mit dieser kommt man
in speziellen Fällen zu einer korrekten Topologie bspw. für Radfahrer.

Und es hängt auch von der Definition der Topologie ab, wann sie korrekt
abgebildet ist oder nicht.
Bspw. bei
highway=path foot=designated bicycle=designated segregated=yes
highway=trunk lanes=3
haben wir ja "in klein" die selbe Topologie für diesen Weg, wie "in groß" für
highway=trunk cycleway=yes
d.h. man fasst was zusammen und betrachtet diese dann topologisch
als Einheit "Bordsteinweg" oder "Fahrbahn" im kleinen oder "Straße"
im großen.

> Unsere Daten verfeinern sich immer mehr. Manche beschreiben das mit "Zumüllen 
> der Datenbank". Ich sehe dem relativ gelassen entgegen. Im Falle eines 
> straßenbegleitenden Radweges heißt das, dass jemand auch den Grünstreifen 
> zwischen Fahrbahn und Radweg einzeichnen können soll. Eine gute Sache, trotz 
> der Fragen (speziell bezüglich des Renderings) die das aufwirft.

Rendern würde nur in höchsten Vergrößerungen Sinn machen...

> Ich persönlich komme daher zu dem Schluss, dass in einer Geodatenbank die 
> Topologie wichtiger ist als die STVO, die wie eine Glasglocke über die 
> Topologie gestülpt ist. Relationen sind eine umständlich zu handhabende 
> Sache. Dennoch tendiere ich aus obigen Gründen dazu, dass die STVO durch eine 
> Relation zwischen dem Radweg und der Straße abgebildet werden sollte, so 
> ähnlich wie das ja auch bei Abbiegeverboten gehandhabt wird.

Man könnte eigentlich jedes Modell erweitern.
Im "Straßenraum"-Modell generalisiert:

highway=trunk
cycleway=track

dann näher spezifiziert z.B. für die halbe Rheinbrücke
(andere Hälfte negativ, 0 als Mite):

0.segregrator=crash_barrier
1.landuse=green
1.width=0.5
2.lane=trunk
2.width=3
3.segregrator=dashed_line
4.lane=trunk
4.width=3
5.segregrator=dashed_line
6.lane=trunk
6.width=3
2-6.surface=asphalt
7.segregrator=curb
7.segregrator=crash_barrier
8.lane=cycleway
8.foot=no
8.width=1.5
9.segregator=solid_line
10.lane=footway
10.bicycle=no
10.width=1.5
11.segregrator=handrail
12.water=deep ;-)

Oder man macht alles als separaten way:
- Das Grün in der Mitte als area, die Leitplanke darauf als line
- jede Fahrspur einzeln, wie die gestrichelte Linie dazwischen
- Leitplanke zwischen Radweg und Fahrbahn
- Radweg
- Gehweg
- ...

... und packt alles in eine Relation Straßenraum zusammen, in
der wiederum womöglich durchnumeriert werden muss, damit man weiß,
was neben was liegt etc.

... oder macht Mischlösungen:
- die 2 Fahrbahnen als je ein way, aber mit spurabhängigen tags, evtl.
wie oben, und den Geh- und Radweg als 2 ways, auch ggfs. wieder
mit spurabhängigen tags für Geh- und Radweg.

> Ich bin daher auch kein Freund davon, einen Weg zu zerhaken, nur um eine 
> Geschwingigkeitsbeschränkung (oder auch eine einfache Brücke) zu modellieren.

Da man Relationen nun sortieren kann (in potlatch anscheinend noch nicht?)
wäre der Vorschlag, der kürzlich zu lesen war von irgendwem (vergessen,
wer's war), mit Relationen von Knoten zu Knoten für bspw. Brücken
statt unterteiltem way eine nette Idee.
Router brauchen diese Infos nicht, Renderer könnten damit evtl.
eines Tages besser zeichnen.
Mit
node 1 role=Fahrbahn1
node 2 role=Fahrbahn1
node 3 role=Fahrbahn2
node 4 role=Fahrbahn2
node 5 role=Geh-Radweg
...
könnte man per Relation gleich die ganze Brücke erfassen anstatt
dass wie heute 4 separate Brücken gezeichnet werden
(den Nachteil des Separat-Modells habe ich ja ganz vergessen ;-) )

Die Frage ist: was passiert, wenn der way auf der Brücke durch
weitere Knoten verfeinert wird, dann fehlt der ja in einer
Nur-Node-Relation...

> Wäre die Unterstützung für Relationen in unseren Editoren besser, würde ich 
> für die im Verlaufe der Diskussion schon erwähnten "Segmented Tags" plädieren 
> (mit denen könnten übrigens auch straßenbegleitende Radwege recht gut 
> beschrieben werden, aber das vielleicht besser nur am Rande ;-) .

Womöglich wäre das auch eine Lösung, ja...

> Jeder von uns mappt, ob er will oder nicht, natürlich auch für "den Router" 
> und "den Renderer". Dagegen ist erstmal nichts einzuwenden. Aber die Comsumer 
> sollten IMO nicht zur obersten Maxime beim Mappen werden. Ob Mapnik 
> Osmarender, openrouteservice.org, gosmore oder Navit heute mit unseren Daten 
> zurechtkommen oder nicht, ist zweitrangig. Das lernen die schon noch. Und 

Z.B. anhand der Rheinbrücke ;-)
Nicht überall achten da so viele Leute drauf wie in KA, daher
sollten sie derzeit mit beiden erlaubten Modellen zurecht kommen.

> zwar umso schneller, je einheitlicher das Radwegemapping umgesetzt wird. 

In der Tat.

> Wer eine Verbesserung erreichen möchte, muss sich mit einer Reihe von Leuten 
> zusammensetzen, die eine halbwegs einheitliche Vorgehensweise erarbeiten, 
> vorschlagen und aktiv in den Daten und (vor allem) den Consumern umsetzen 
> können.

Da ist ein gewisser Flaschenhals bei den "Consumern" Renderer,
weil keiner von denen Geometrien verändern kann.

Entweder brauchen wir völlig neue Renderer, ansonsten können
wir vernünftiges Radwegerendering vergessen (in beiden Modellen,
einseitige im einen Modell, nichtüberlappend im anderen Modell)
und kommen auch bei anderen Verdrängungen (Tram in der Mitte,
Anliegerfahrbahnen, Gebäude am Straßenrand, Sackgassen kurz vor
Hauptstraße, ...) nicht weiter

Oder wir bräuchten eine Art Vorprozessor, der aus den OSM-Datenbestand
heraus diese erstmal für verschiedene Router und Renderer aufbereitet,
eben auch geometrisch. Das kam mir noch als weitere Idee.
Ein osm2osm also, das für's rendern und/oder routen
- entweder highway=trunk cycleway=track trennt in 2 ways und
- getrennte Wege "vereinigt"
und aus beidem zwei ways macht, deren Lage abhängig von der Zoomstufe
ist, da ja der Radweg, damit er erkennbar bleibt, immer einen anderen
(Mindest-)Abstand zur Fahrbahn haben muss.
Das ganze ggfs. anhand von Relationen oder auch automagisch
(d.h. Relationen auch vorschlagend, die man manuell nacharbeiten kann)

> Genau so haben wir es in Karlsruhe mehrfach gemacht (komplexe 
> Kreuzungen, Hausnummern, ÖPNV) und andere haben es übernommen.
> 
> Ich glaube ehrlich gesagt kaum, dass ein solcher Vorschlag zur Modellierung 
> von Radwegen zu Zusatztags an Trunks raten würde. Aber ich lasse mich da 
> gerne vom Ergebnis eines Workshops überraschen. Es sei denn, Heiko wäre der 
> einzige Teilnehmer ;-) .

Ich würde sagen, man kann beide Modelle aufbohren, evtl. muss man
sogar beide Modelle aufbohren, da ja auch 2 ways für trunk und cycleway,
wie oben gezeigt, nur "Mischlösungen" sind, wenn man genauer
spezifizieren möchte, wie nun die einzelnen Spuren genutzt werden
(Lkws incl. Tempolimits bspw. auf der Rheinbrücke!) oder Rad- und
Gehweg zueinander stehen oder wie genau die Trennungen aussehen.
Und ob man sich da ein völlig auf separates Mappen aufbauendes
Modell antun will... Ich weiß ja nicht... Also brauchen wir auch
ein Modell, bei dem man Fahrspuren bzw. Geh- und Radweg geometrisch
zusammen mappen kann, aber trotzdem getrennte Informationen erfassen kann.
Dann ist es fast egal, wie weit man ein solches Modell bis an seine
Extrema ausreizt (30 ways für die Rheinbrücke, für jede Linie auf
der Fahrbahn einen eigenen way, oder nur ein way mit 30 Nummern.
Und wenn ich einziger Teilnehmer wäre, würde das nix dazu implizieren,
was für ein Modell dann rauskäme ;-) Dort bspw.
http://www.openstreetmap.org/?lat=49.09079&lon=8.4455&zoom=18
habe ich brav das Getrennt-Modell gelassen und verfeinert, weil
solche Situationen anders nicht abbildbar sind.

Wahrscheinlich müsste man erstmal eine Idee für die geometrische
Umarbeitung haben, bevor man sagen kann, wie man diese füttern muss,
ob eher Modell 1 oder 2 oder beide wahlfei oder ein ganz anderes
dafür passen.

Gruß Heiko "Mueck" Jacobs





Mehr Informationen über die Mailingliste Talk-de