On Mon, 16 Feb 2009 17:25:32 +0100, Torsten Leistikow <de_m...@gmx.de> wrote:
> Frederik Ramm schrieb:
>> Was ich von einer Hoehendatenbank will ist: Zu einer gegebenen Position
>> die Hoehe erfahren.
>>
>> Sonst nichts.
>
> Das sehe ich anders. Ich habe einen Weg, der vom Punkt A ueber B nach C
> verlaeuft. Und fuer diesen Weg will ich nun wissen, in welcher Hoehe der
> Weg an den drei Punkten ist.
>
> Ob einer der Punkte nun 5m nach Osten verschoben ist, ist mir dabei
> erstmal egal. Es darf aber nicht passieren, dass sich durch diese
> Verschiebung die Hoehe um ein paar hundert Meter aendert (siehe das
> Beispiel mit der Staumauer).
>
> Insofern braucht meine nicht einfach eine Datenbank, die fuer
> Lat-Lon-Positionen einem jeweils einen Hoehenwert liefert (das kann SRTM
> ja an den meisten Stellen hinreichend gut). Was man braucht, ist eine
> Datenbank, die fuer die einzelnen Objekte die jeweilige Hoehe liefert.
Wenn ich mich mal kurz einschalten darf...
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.
> Und eben wegen diesen Zusammenhang zwischen Hoehe und Objekt, macht eine
> getrennte Hoehendatenbank in meinen Augen auch keinen Sinn.
Der Zusammenhang ist doch über Lat/Lng gegeben.
OK, in Höhlen und unter felsforsprüngen gibt es Probleme, aber die Vorteile
überwiegen IMHO bei Weitem...
Gerrit
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
