[Talk-de] Bahnstrecke vs. Gleis

[Felix Hartmann]

>
>> -- Weil etwa eine Zugverbindung nicht alle Gleise benutzt, sondern 
>> wie genereller Verkehr, nur bestimmte Gleise der "Bahnstrecke" 
>> (Bahnstrecke gleich die Zusammenfassung aller Einzelgleise). Sprich 
>> nur weil man Sachen einzeln mappt, wird es nicht korrekter. Karten 
>> sind Abstrakte der Wirklichkeit.
>
> Voellig richtig, und wenn wir hier eine Karte im Illustrator malen 
> wuerden, waere das was anderes. Aber die Abstraktion soll bitte der 
> Renderer vornehmen und nicht der Mapper. Ich moechte naemlich 
> irgendwann schon gern ein Draisinen-Routing haben, bei dem mir der 
> Router genau sagt, ob ich das linke oder rechte Gleis fahren soll ;)
>
> Das Problem des Masstabs haben wir uebrigens bei Bahnhoefen auch 
> schon; wenn ich jetzt die Kursbuchstrecke Basel-Hamburg als Relation 
> eintrage, bin ich gezwungen, die an ein ganz bestimmtes Gleis zu 
> haften und an einen ganz bestimmten Bahnsteig in jedem Bahnhof, obwohl 
> das natuerlich meistens eine operative Entscheidung ist und nicht in 
> Stein gemeisselt. Es muesste also tatsaechlich die Moeglichkeit geben, 
> eine Trasse und einen Bahnhof auf einem abstrakteren Niveau 
> anzusprechen als ein konkretes Gleis.
>
> Manchmal denke ich, wir sollten solche Relationen erst dann 
> einfuehren, wenn mindestens zwei verbreitete Editoren damit auch gut 
> umgehen koennen. Wir haben im Moment eine Situation, wo sehr viele, 
> meist auch logisch irgendwie sinnvolle, Relationen angelegt werden, 
> aber ich fuerchte, immer weniger Leute blicken da durch.
>
Ich bin mir sicher, dass es einfacher wäre, die "abstrakteren" Level 
up-to-date zu halten. Fakt ist derzeit kann man aus OSM Daten keine 
vernünftige Weltkarte rendern. Auf Rasterbasis mag das noch irgendwie 
gehen, aber als Vektorkarte ganz sicher nicht. Dabei könnte man so eine 
Weltkarte, als Einzelperson, wohl locker innerhalb von 2-3 Wochen von 
Yahoo Bildern / OSM Grundlayer erstellen. Dazu noch 1-2 Zwischenlayer, 
und es würde die ganze Sache viel einfacher machen. Auch weil es 
bestimmte Konflikte über Detailgenauigkeit lösen würde (wer jeden Baum 
einzeln taggen möchte, der könnte das dann ohne Schaden machen, wo die 
absolute Genauigkeit da bleibt, ist dann halt fraglich). Und es würde 
viele der Relationen deutlich vereinfachen.

Man könnte sogar überlegen, ob es nicht Sinn macht, die Datenbank viel 
stärker aufzubröseln. Damit man sich nur noch die Sachen holt die man 
braucht. Das ein Topf wo ich alles reinschmeiße Modell, funktioniert 
einfach immer schlechter. Etwa je genauer Straßen gemapped werde, in 
desto mehr Einzelteile werden sie zerlegt, aber fast immer ohne eine 
Straßenrelation zu erstellen (ist ja irgendwie auch dumm, dass es sowas 
braucht). Und desto mehr Einzelteile, die man maximal in 90% der Fälle 
korrekt logisch verbinden kann, desto schlechter wird das Routing.

Und es gibt derzeit keinen Editor, der wirklich gut mit Relationen 
umgehen kann (sprich, der halbwegs intelligen erkennt, wenn jemand eine 
Relation doppelt einträgt, oder der intelligent die Relation anzeigt, so 
dass der User sieht dass sie schon existiert). Solange man nicht bei 
klicken auf "Fahrradroute", alle Fahrradrouten im Editorausschnitt 
hervorgehen sieht (aber restliche Relationen unsichtbar bleiben), wird 
es auch nicht klappen. Damit unser derzeitiges immer detaillierter 
werdendes Mapping irgendwie funktioniert, bräuchte es viel mehr 
Userbasierte Presets. Sprich das komplette Kartenrendering und 
Editorpresetlayout verändert sich, wenn ich anklicke "taggen als 
Wanderer" oder "taggen als Autofahrer". Das ist zwar umsetzbar, aber 
richtig viel Arbeit. Und solange die Editoren in ihren 
Vektordarstellungen nicht 1-2 Generationen besser werden (bezogen auf 
"Presets für die Darstellung" wie auch technische Möglichkeiten der 
Darstellung, wird es auch nicht Userfreundlich.


OSM ist so groß geworden, dass es einfach eine Fragmentierung braucht 
(klar braucht das viel Input/Zeit um eine Interoperabilität der 
Fragmente zu gewährleisten). Wenn dies nicht passiert, wird OSM einfach 
an Bedeutung verlieren, weil Spezialgruppen ihre Interessen nicht mehr 
umsetzen können (und das ist das was OSM wirklich ausmacht, weil nur 
freie Kartendaten gibt es eh mehr und mehr) ohne andere Gruppen vor den 
Kopf zu stoßen.
Highway:area=* wäre etwa ein Fall, der ganz einfach in eine separaten 
Datenbankteil gehört.

Wenn hier nichts passiert, werden andere Userbasierte Kartendatenbanken 
interessanter werden und es würde sich alles zersplittern (womit aber 
die größte Stärke von OSM, die Verkreuzung verschiedenster sonst so 
nicht registrierter Daten, abhanden käme).