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
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
