On Mon, 16 Feb 2009 18:09:49 +0100, Torsten Leistikow <de_m...@gmx.de> wrote: > Gerrit Lammert schrieb: >> Szenario: >> >> x u >> A-----B >> w \ >> y \ C z >> >> So wie ich es verstehe, soll die Straße (A-B-C) in OSM liegen. Die >> Punkte u..z liegen in einer seperaten DB und besitzen Höhenangaben. >> Wenn Du also die Höhen von A, B oder C (oder anderer Punkte) haben >> möchtest, gibts Du der anderen DB die Koordinaten und diese berechnet >> "Zwischenwerte" als Höhe von A,B,C. Um so mehr Werte vorhanden (und >> um so näher diese an den abgefragten liegen), um so genauer. ich sehe >> keinen Vorteil darin das in die bestehende DB zu matschen. > > Das Problem entsteht dann, wenn die Hoehenaenderung zwischen A und B > bzw. B und C nur sehr klein, zwischen w und x, y und u und y und z aber > sehr gross ist. Wenn man dann ueber die Lat-Lon-Koordinaten aus einer > anderen Datenbank die Hoeheninformationen holt, erhaellt man als > Ergebniss nur Muell, egal wie eng das Netz von u..z ist. > Und unangenehmerweise ist der von mir geschilderte Fall nicht nur rein > theoretisch. In den Bergen ist es naemlich der Normalfall, dass die > Strassen nahezu senkrecht zum Hoehengradienten verlaufen. Bei einer > Strasse, die sich in Serpentinen einen Hang hinauf schlaengelt, erhaelt > man als Ergebniss dann keine konstante Steigung, sondern bestenfalls > eine Treppe, weit relaistischer allerdings einen ansteigenden Saegezahn. > (Das kann man z.B. bei den Top50-Karten von der Landesvermessung mal > ausprobieren.)
Ist mir im Prinzip klar. Aber woher hätte denn das integrierte Modell genauere Daten? Wenn es (woher auch immer) genaue Daten für einen Knoten gibt, gäbe es die doch in beiden Systemen. Und wenn es halt keine genauen Daten gibt, könnte das zweite System (da spezialisierter) besser interpolieren und damit in 99% aller Fälle realistische Höhen "generieren". Gerrit _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
