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