-- 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).
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de