Hallo Markus.
Inwieweit das ein Thema für ein Treffen von ein paar Stunden oder Tagen
sein kann, weiß ich nicht, denn das ist 'ne ganz schön große Kiste, die
du da als Thema hinstellst.
Nichtsdestotrotz sind die Fragen aber, denke ich, ziemlich richtig.
Auf der einen Seite sollten die Daten sauber sein, auf der anderen Seite
fordert das für Renderer immer komplexere Gebilde.
Auf der einen Seite sollen die Daten handhabbar bleiben, auf der anderen
Seite ist es schön, genau das Detail zu finden, das ich wirklich grade
brauche.
Ich denke, eigentlich fehlt trotz vieler Bemühungen immer noch ein
Zwischenschritt in der Pipeline, die das OSM-Universum bildet:
(a) Wir haben Mapper,
(b) wir haben Daten, die wir Anwendern geben können,
(d) es existieren Anwendungen wie Renderer/Karten, Router,
Kunstanwendungen, Suchmaschinen und so weiter.
c hab ich bewusst ausgelassen - da fehlt irgendwie noch was: Eine gut zu
verwendende Verarbeitungsschicht, die man Anwendungsentwicklern an die
Hand geben kann, ohne dass die erst monatelange Einarbeitungszeit brauchen.
Osmosis gehört in diese Kategorie und ist zweifelsohne ein extrem
nützliches Tool.
Es gibt allerdings auch für osmosis diverse Anwendungen, die immer
wieder vorkommen und nützlich wären:
- Wie generiere ich aus einem planet oder Gebietsextrakt einen
Routinggraphen? Ich bräuchte eine halbwegs passende osmosis-Pipeline und
vermutlich ein SQL-Script zur Datenbank-Nachbearbeitung, um einen
einfachen Graphen zu erzeugen - das Speziellere Erzeugen für bestimmte
Anwendungen, die Bildung von Contraction-Hierarchies oder sonstwas meine
ich hier nicht.
- Ich hätte gerne ein generalisiertes Eisenbahn-Netz (ja, das wäre genau
das collapsing von parallelen Strecken - aber genau darum geht es mir
ja: Wieso soll sowas von jedem Renderer extra unterstützt werden?)
- Analog zur Generalisierung von Flächen (Häuser zu landuse=residential
zusammenfassen und so weiter)
Im Grunde gibt es zwei Ansätze, die man da fahren kann:
Man kann weiter so taggen, dass die Renderer, die bereits existieren,
damit ohne Änderungen umgehen können - und damit die Datenbank
entsprechend begrenzen, oder man setzt eben bei den Renderern selbst
oder zwischen Renderern und Datenbank an.
Ich würde letzteres bevorzugen.
Gruß
Peter
Am 27.05.2011 09:19, schrieb Markus:
Ich möchte gern mal über "quo vadis" sprechen...
Einerseits lässt unsere Datenbank beliebige Detailliertheit zu
(Mikromapping, Einzelgeleise, Vorhausgärten, Parkplätze, Bäume, etc)
Andererseits brauchen wir kartografisch sinnvolle Generalisierung,
und routentechnische Berechnungseffizienz.
Einerseits gibt es das Credo: "wir arbeiten nicht für den Renderer",
andererseits geschieht genau dies permanent, denn der Benutzer
beurteilt Qualität anhand dessen was er sieht.
Zunehmend werden komplexe (und auch nicht so komplexe) Zusammenhänge
in Relationen abgebildet, die sowohl vom Benutzer als auch vom
Renderer nur schwer zu handhaben sind. Fehler werden dadurch drastisch
zunehmen.
Zunehmend geht die Nutzung von Punkten und Flächen und Namen wirr
durcheinander.
Vor allem für neue Benutzer (es werden immer mehr :-) ) scheint es m.E
dringend erforderlich, ihnen für sie nachvollziehbare Empfehlungen
incl. erklärender Begründung an die Hand zu geben.
Dabei müssen wir darauf achten, dass wir die Freiheit (die Intelligenz
der Masse) bewahren - denn sie ist eine unserer grössten Ressourcen
und Qualitäten.
Ich könnte mir gut vorstellen, dass wir uns dazu mal treffen und
gemeinsam Lösungen suchen:
Daten-Spezialisten, Kartografen, Routing-Spezialisten, Generalisten...
Wäre das nicht ein Thema für ein nächstes Treffen im Linux-Haus?
Gruss, Markus
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
