Pufferzonen Berechnung

Hallo!
Ich bin hier gerade neu und habe schon gute Infos erhalten...
Auf diesen aufbauend, will ich un meine Frage formulieren:

Ich möchte gerne zu einem gegebenen Punkt (im WGS84 Format) eine Pufferzone berechnen. Sinn dieser Pufferzone ist es, in einem großen Datenbestand nicht alle Daten betrachten zu müssen, sondern nur solche, die in einem Umkreis von z.B. 2km liegen.

Meine Idee ist nun, anhand der Berechnungen, die ich bei http://www.movable-type.co.uk/scripts/LatLong.html gefunden habe, mittels

lat2 = asin(sin(lat1)*cos(d/R) + cos(lat1)*sin(d/R)*cos(brng))
lon2 = lon1 + atan2(sin(brng)*sin(d/R)*cos(lat1), cos(d/R)−sin(lat1)*sin(lat2))

Die Punkte zu berechnen, die von meinem Starpunkt 2km entfernt liegen und ein Bearing von 45°, 135°, 225° und 315° haben.

Dann erhalte ich ja ein Rechteck um meinen Punkt.
Und nun kann ich nur solche Koordinaten betrachten, die zwischen den beiden Längen und Breitengraden liegen.

Meine Frage ist nun, ob diese Ansatz korrekt ist und aus was sich die Formel herleitet!
Wenn jamand eine Antwort hätte, fände ich das klasse!

Wesentlich einfacher und schneller dürfte es sein, nicht so genau auf die 2km zu bestehen und einfach zu den Koordinaten einen Offset von x grad dazu zu addieren bzw. abzuziehen, um die vier Eckpunkte für die Pufferzone zu bekommen. Damit ändert sich die Größe der Pufferzone je nach geographischer Lage des Zielpunktes aber es sind keine Fliesskomma-Berechnungen nötig, die massiv Rechenzeit kosten. Da die Daten eh noch weiter analysiert werden, sollte die schwankende Größe der Zone keine Rolle spielen oder sehe ich das falsch?

Tiger

Der Ansatz ist korrekt. Die Formeln kommen aus der sphärischen Trigonometrie. Bei der ersten Formel handelt es sich um den Seitencosinussatz, die zweite kenne ich nicht, die Länge lässt sich stattdessen auch mit dem sphärischen Sinussatz berechnen. Was du da berechnest, nennt man Poldreieck. Weitere Hinweise findest du z.B. hier.

-tiger- hat natürlich Recht: es geht auch billiger:

Winkel (in Radiant), der einem Bogen der Länge s entspricht: w=s/Erdradius

dLänge=w/cos(Breite) (wegen der Meridiankonvergenz)
dBreite=w

Für die Grenzen des Puffers musst du dLänge und dBreite einmal von deinem Punkt abziehen und einmal hinzufügen - du erhälst dann einen fast rechteckigen Bereich der ungefähren Seitenlänge 2*s um deinen Punkt herum. Die nördliche Begrenzung des "Rechtecks" ist ein wenig zu kurz, die südliche dafür ein wenig zu lang. Für cos(Breite) kannst du eine Konstante einsetzen, wenn sich die Breite nicht allzu sehr ändert.

Viel Erfolg wünscht
Chris

Herzlichen Dank für Eure Antworten!

Also zu der Idee des Poldreickes ist meine Frage nur, ob die Menge der Daten, die man dann erhält und auswerten muss, nicht so viel größer ist, dass es sich gleich lohnt die Fliesskommaberechnungen durchzuführen...

Dieses Forum beginnt ja langsam Spass zu machen. Nur um noch mal einen Vorschlag zu machen: Man könnte auch die ganze Tabelle um zwei Felder erweitern und zusätzlich einmalig die GK-Werte einrechnen.
Dann kann man folgendes tun: Einmal grob alles rausselektieren was eh nicht in Frage kommt, weill Hoch-/Rechtswert <-2000 oder >+2000, danach mit dem alten Phythagoras noch mal nachfassen.

Hallo meonk,

meinst Du mit GK Gauss Krüger?

Ja. Die Umrechnung ist aufwändig, aber sie muss ja nur einmal gemacht werden. Dafür sind Deine Ergebnisse dann sehr genau.

Hm...

Ich habe das nun mal in C++ umgesetzt:


Und als latX und longY werden: 52.378890991210938 und 9.6863698959350586 übergeben.
Das Ergebnis lautet dann: 1.0280191502909932 und 9.6858527430615684

Ich befürchte da habe ich noch etwas übersehen?
Muss ich irgend ein Wert noch umrechnen?

Ich hab nicht alles einzeln überprüft, auf jeden Fall fehlt aber die Umrechnung der Winkel in Bogenmaß. Die Winkelfunktionen erwarten das Argument immer in der Einheit Radiant:

Also erstmal rechnen latXRad=LatX/180.0*PI und so weiter.
Mit latXRad kannst du dann in die Formeln hinein gehen. Das Ergebnis bekommst du natürlich auch in Radiant.

Außerdem solltest du deine Variablen besser als double deklarieren, anstatt als float. Float hat nur eine 7-stellige Mantisse, das könnte bei den großen Zahlen zu unerwünschten Rundungen führen. Bei float sparst du sowieso nichts ein, weil bei der Übergabe an die Winkelfunktionen implizit in double umgewandelt wird.

Eine Grundregel: Benutze niemals float !!!

Das Förmelchen sieht aber ziemlich kompakt aus. Ich kenn nur das was ich immer in meinen Excel-Tabelle habe und das ist deutlich unhandlicher, also mit e², N und diversem mehr.

moenk schrieb:

Das Förmelchen sieht aber ziemlich kompakt aus. Ich kenn nur das was ich immer in meinen Excel-Tabelle habe und das ist deutlich unhandlicher, also mit e², N und diversem mehr.

Zum Vergrößern anklicken....

Na ja, du rechnest auf dem Ellipsoid, er auf der Kugel.

Das Problem: Bei geodätischen Linien auf dem Ellipsoid gibt es keine geschlossenen Formeln wie auf der Kugel. Deine Formeln sind so unhandlich, weil das Näherungslösungen unlösbarer Integrale sind (Reihenentwicklungen o.ä.).

Bei kurzen Entfernungen sollte es in unserem Genauigkeitsbereich keinen messbaren Unterschied machen, aber schon bei einer Projektion von 10 km kann der Unterschied zwischen Kugel und Ellipsoid eine Differenz von 30 m bewirken. Das hat bei diesem (ansonsten tollen) Cache eine ziemliche Verwirrung verursacht.

Einen sehr informativen Kommentar dazu hat xylanthrop geschrieben.

Warum stehen diese interessanten Freds eigentlich ganz unten in der Liste und sowas "wichtiges" wie die Wiese so weit oben?