[Talk-de] Konzept für Daten, Karte und Renderer

[Peter Wendorff]

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
> Talk-de at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>