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