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

[Wolfgang]

Hallo,
Am Freitag 27 Mai 2011 10:52:51 schrieb 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.

ich glaube nicht, dass es möglich ist, ein Tool zu schreiben, dass den ständig 
in Bewegung befindlichen "OSM-Way-of-tagging" bändigen, verwalten oder aktuell 
auswerten kann. Dafür sind wir zu dynamisch, und das ist letzen Endes auch gut 
so, auch wenn einem die eine oder andere Tendenz gegen den Strich geht. Ein 
solches Tool würde zwangsläufig immer hinterher hinken und niemanden so 
richtig glücklich machen. 

Auch die heutigen Tools wie osmosis, osm2postgresql etc. haben (subjektive) 
Schwachstellen, die dem einen oder anderen Wünche übrig lassen. Für den 
Standardfall ("mal eben") sind sie Klasse, und manche Funktionen geradezu 
unverzichtbar, aber manchmal muss man eben selbst zur 132-Tasten-Maus greifen.

Was wir aus meiner Sicht brauchen, ist endlich eine benutzbare X-Api, mit der 
es möglich ist, im Vorfeld zu filtern, was man aus der DB braucht. Für eine 
weltweite Karte aller Eisenbahnverbindungen muss man zur Zeit das Planetfile 
laden, obwohl man nicht mal 1% davon braucht.

Mehrgleisige Strecken mit einer Relation zusammen zu fassen sollte nicht das 
Problem darstellen.

Wer eine Anwendung auf freie Inhalte aufsetzen will, muss neben vielen 
Vorteilen wie Aktualität und Kostenlosigkeit eben auch ein paar Nachteile wie 
Nachverarbeitung in Kauf nehmen. Wenn er das nicht will, soll er seine Daten 
kaufen - bei anderen Anbietern oder bei jemandem, der ihm unsere Daten 
aufbereitet.

Hier ständig ein Protestgeheul für die eigene Anwendung zu starten, nervt auf 
Dauer etwas (womit ich nicht meinen Vorposter meine).

Gruß, Wolfgang