[Talk-de] Höhennetz/Höhendatenbank

["Jonas Krückel (John07)"]

Markus schrieb:
> Hallo Frederik,
>
>   
>>>> Meiner Ansicht muessen Hoehendaten in eine eigene 
>>>> Gelaendemodelldatenbank, die ganz anders strukturiert ist.
>>>>         
>> eine Datenbank, die beliebige viele Hoehenmesspunkte mit 
>> lat/lon/ele festhalten kann und die daraus auf Anfrage Hoehenlinien, 
>> schattierte Kacheln oder Hoehenprofile einer vorgegebenen Geometrie 
>> berechnen kann, 
>>     
>  >
>   
>> plus ein dazu passender Editor
>>
>>  Starten koennte die Datenbank ja mit einem SRTM-Datensatz,
>> der dann schrittweise verfeinert werden koennte.
>>     
>
> klingt gut.
>   
+1
>   
>> erfordert pfiffige Algorithmen 
>> Auch die Editoren sind kein Zuckerschlecken
>>     
>
> Ja, das sind grössere Herausforderungen...
>
>   
>>> 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. 
>>     
>
> Das verstehe ich nicht.
> Ich will doch wissen, wie hoch ein Pass/Berg/See/Haus ist.
> Und wenn das Tal in der Höhen-DB differiert zum Fluss in der Objekte-DB, 
> das hängt doch dreidimensional unmittelbar zusammen - nur dass es halt 
> nach Deinem Vorschlag auf zwei DBs verteilt ist?
>   
Ja, und man braucht dann ein Programm, dass die beiden DBs lokal 
zusammenführen kann, also man lädt seine OSM-Datei und lädt die 
Höhendaten und kann dann in diesem Programm die Straße meinetwegen 
anklicken und das Programm errechnet dann ein Höhenprofil für die Straße 
(vgl. yournavigation.org bzw. das GSoC-Projekt, da funktioniert das so)
>   
>> 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.
>>     
>
> Ok. Aber damit werden die die verteilten Daten ja wieder zusammengeführt 
> und man braucht eine Regel, wie mit Abweichungen verfahren wird?
>   
Man führt sie aber ja nur lokal bzw. für den genauen Anwendungszweck 
zusammen, genauso wie wir es mit den SRTM-Daten auch machen.
Ich bin ebenfalls für eine 2. DB als ein Art Schwesterprojekt zu OSM, 
wir brauchen noch einen guten Namen, Vorschläge? ;-)

Gruß
Jonas