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

[Garry]

Am 27.05.2011 14:16, schrieb 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.
Ich weiss..
> 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
Eine Layerdarstellung in den Editoren ändert zunächst einmal nichts am 
Tagging-Schema.
Mittelfristig soll aber bewirkt werden dass eine saubere Trennung 
zwischen Bodenbedeckung, "landuse"(Flächennutzungsplan?), Verkehrswege etc.
einzug hält.
> 2) Welche layer bietet man an? Routing-Layer: Mit oder ohne Fußwegen? 
> was ist mit Rollstuhl-Routing-Eigenschaften? Adressgenau, oder nur die 
> Fahrwege?
Im Routing-Layer sollte alles angezeigt werden was routing-relevant ist, 
gegebenfalls vom user einzelne Elemente ausblendbar die er gerade nicht 
benötigt,
in dem Fall aber mit einer Verriegelung/Warnung wenn sich eine Änderung 
auf die ausgeblendeten Elemtente auswirken würde(So wie jetzt schon in 
Josm wenn man etwas ändern möchte was nicht vollständig geladen ist).
>
> 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.
Z.B. sollten Verkehrswege keine gemeinsamen nodes mit landuse / 
Bodenbedeckung haben. Meist stammen die Daten aus unterschiedlichen
Quellen mit unterschiedlicher Genauigkeit. Bei gemeinsamen nodes würden 
eine Positionsänderungen im einen Layer (aus welchen Gründen auch immer)
die Daten im anderen Layer beeinflussen und unter Umständen hochgenaue 
Daten verschlechtern.

Garry