Hallo,
>> Meiner Ansicht muessen Hoehendaten in eine eigene
>> Gelaendemodelldatenbank, die ganz anders strukturiert ist.
>
> Wie könnte das aussehen?
Naja, eine Datenbank halt, die beliebige viele Hoehenmesspunkte mit
lat/lon/ele festhalten kann und die Dir daraus auf Anfrage Hoehenlinien,
schattierte Kacheln oder Hoehenprofile einer vorgegebenen Geometrie
berechnen kann, plus ein dazu passender Editor, der es Leuten erlaubt,
die Datenbank zu veraendern. Starten koennte die Datenbank ja mit einem
SRTM-Datensatz, der dann schrittweise verfeinert werden koennte.
Ist aber nichts, was man mal eben an einem Wochenende entwickelt. Die
Datenbank ist trivial ("create table hoeheninfo (lat integer, lon
integer, ele integer);", fertig), aber aus beliebigen, nicht mal in
einem Raster angeordneten Hoehenpunkten eine stetige Oberflaeche zu
berechnen, erfordert entweder pfiffige Algorithmen oder endlos viel
Rechenzeit. Auch die Editoren sind kein Zuckerschlecken, man will ja im
Editor nicht einzelne Punkte veraendern, sondern die ganze Landschaft.
Wenn ich irgendwo 500m Hoehe gemessen habe und 3m nebendran ist ein
SRTM-Messpunkt mit 450m, dann will ich ja an der Stelle keine Steilwand
im Gelaendemodell...
> Wie würden die beiden DBs zusammenwirken?
Genau so, wie wir jetzt schon mit SRTM-Daten arbeiten. Schnittstelle
waere auf jeden Fall die Geometrie; die Hoehe haette mit OSM-Objekten
rein gar nichts zu tun. Wenn ich wissen will, wie der Hoehenverlauf der
Strasse X ist, lasse ich mir von OSM die 2D-Geometrie der Strasse geben
und frage dann die Hoehendatenbank nach einem Profil dafuer.
Bye
Frederik
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
