[Talk-de] Höhenmesser: Die Post war da :- )

[Frederik Ramm]

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