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

[Peter Wendorff]

Am 27.05.2011 13:47, schrieb Garry:
> Am 27.05.2011 10:52, schrieb Peter Wendorff:
>>
>> 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.
> Eine Lösung könnte auch eine layerorientierte Ausrichtung sein:
> landuse-Layer         (entspricht Flächennutzungsplan)
> Cover-Layer            (beschreibt die vorgefundene Bodenbedeckung)
> Traffic-way-Layer    (beschreibt nur die Verkehrsverbindungen ohne auf 
> verkehrsrechtliche Details einzugehen)
> Routing-Layer          (beschreibt fahrspurdetailiert die Verkehrswege)
> Building-Layer
> usw..
> Wobei die Layer nicht in der Datenbank auftauchen sollten sondern in 
> den Editoren durch entsprechende Filter erzeugt werden.
> Bestimmte nodes dürfen dabei nicht layerübergreifend verwendet werden.
Die Idee gabs schon mehrfach.
Probleme dabei:
1) Wer definiert die Layer? Einerseits müssen die wegen der Evolution 
des Taggingschemas irgendwann geändert werden, andererseits müssen sie 
konstant bleiben, damit die Anwendungen nicht in die Falle tappen
2) Welche layer bietet man an? Routing-Layer: Mit oder ohne Fußwegen? 
was ist mit Rollstuhl-Routing-Eigenschaften? Adressgenau, oder nur die 
Fahrwege?

Nodes nicht layerübergreifend verwendbar?
Bei welchen Layern und warum? Ich befürchte, Gegenbeispiele gibt's da 
immer - es sei denn, man trennte die layer komplett voneinander, was 
dann aber schnell zu inkonsistenzen führt.

Gruß
Peter