[PHP] Umrechnung vom Äquatorialsystem ins Horizontalsystem

Hellstorm

Registriertes Mitglied
Hallo allerseits,

mein Versuch ist an sich recht einfach. Ich möchte die Position eines Sternes vom Äquatorialsystem (also mit Rektaszension und Deklination) ins Horizonzalsystem (Azimut und Höhe) umrechnen.

Was astronomische Formeln angeht, bin ich ein Neuling und meine Mathematik-Kenntnisse sind in den letzten 10 Jahren doch sehr eingerostet. Nun habe ich folgendes Problem: Bei der Umrechnung erhalte ich die korrekte Höhe des Sterns, aber der Azimut liegt bei Werten, die jeglicher Logik entbehren. Im moment teste ich mit Stellarium. Suche mir da die RA/DE-Werte raus, und vergleiche mein Ergebnis mit denen von Stellarium.

Die verwendete Formel ist dabei das Nautische Dreieck aus der Wikipedia.

Zuerst braucht man hier ja das Julianische Datum mit Nachkommastellen. Das haut auch soweit hin. Anschließend berechnet man daraus die Orts-Sternzeit. Die stimmt auch.

Und dann kommen wir zu der Eigentlichen Formel: sin(h) = cos(delta)*cos(tau)*cos(phi)+sin(h)*sin(phi) sowie sin(a) = (cos(delta)*sin(tau))/cos(h)

Der erhaltene Wert für sin(a) ist gänzlich falsch.

Ich gehe wie folgt vo: ich rechne zuerst alle Variablen (die als Grad vorliegen) mit deg2rad() ins Bogenmaß um. Führe dann meine Rechnung aus. Anschließend berechne ich h mit h = asin(h). Dann kommt die zweite Formel, für a = asin(a). Und anschließend wieder rad2deg() (oder *180/pi, wenn so gewollt).

Hier mal der wohl relevante Code. $de ist die Deklination (delta), $t der Stundenwinkel (tau) und $lat die Breite (phi).
PHP:
$de = deg2rad($de);
	$t = deg2rad($t);
	$lat = deg2rad($lat);
	
	
	$sinh = cos($de)*cos($t)*cos($lat)+sin($de)*sin($lat);
	$h = asin($sinh);
	$sina = (cos($de)*sin($t))/cos($sinh);
	$a = asin($sina);
	
	$h = rad2deg($h);
	$a = rad2deg($a);

Wo ist hier der Fehler, dass die Werte nicht stimmen?
 

Bernhard

Registriertes Mitglied
Hallo Hellstorm,

da ist doch ein Flüchtigkeitsfehler in dieser Zeile:
PHP:
$sina = (cos($de)*sin($t))/cos($sinh);
Der letzte Term muss cos($h) lauten(?)

Gruß und Willkommen im Forum

EDIT: Was kann man mit dieser Umrechnung dann eigentlich so anstellen?
 
Zuletzt bearbeitet:

Hellstorm

Registriertes Mitglied
Thx :)

cos($h) hab ich schon getestet. Die Werte passen dann auch nicht.

Theoretisch sollte ich dann entsprechende Az/z Koordinaten erhalten, sodass man das dann in einen Kreis packen könnte und so eine aktuelle Sternenkarte erhält.
 

Bernhard

Registriertes Mitglied
... und so eine aktuelle Sternenkarte erhält.
Verstehe.

Da wäre meine erste Frage dann, wie der Beobachtungsort in die Gleichungen eingeht. Die angegebenen Formeln sehen auf den ersten Blick ganz vernünftig aus, aber so wie ich mich erinnere muss man bei der Berechnung von Azimut und Höhe vom geozentrischen System (mit RA und D) in das lokale System tranformieren. Es ist also eine Transformation zwischen zwei gegeneinander verdrehte Systeme mit Kugelkoordinaten. Vielleicht ist Dein Ansatz hier ungenügend.

Die korrekte Transformation wird in dem Buch von Oliver Montenbruck, "Grundlagen der Ephemeridenrechnung" sehr gut erklärt. Bilder zur Veranschaulichung gibt es dort auch. Vielleicht bekommst Du es ja in einer Bibliothek zum Ausleihen.
Gruß
 

Hellstorm

Registriertes Mitglied
Muss ich mal schauen! Vielleicht find ichs ja auch bei Amazon oder ebay als Taschenbuch-Version recht günstig. Ich hab auch einige Infos von hier: http://www.greier-greiner.at/hc/sph_dreieck.htm
Da kann ich aber nicht so präzise sagen, ob da auch noch weiter transformiert werden muss.

Edit: Mir geht dabei aber trotzdem nicht in den Kopf, warum die Höhe stimmt und nur der Azimut verrückt spielt ... :confused:
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
Zuletzt bearbeitet:

Hellstorm

Registriertes Mitglied
Arrrr... Irgendwie hab ich sowas befürchtet. Na dann werd ich mir dahingehend mal noch alle weiteren Formeln zusammensuchen! - War mir halt nur etwas suspekt gewesen, dass eine Seite trotzdem stimmte - zumindest wenn man versucht, sich das Ganze bildlich vorzustellen.
 

Bernhard

Registriertes Mitglied
War mir halt nur etwas suspekt gewesen, dass eine Seite trotzdem stimmte - zumindest wenn man versucht, sich das Ganze bildlich vorzustellen.
Die Höhe wird bei der Gesamttransformation weitgehend geometrisch bestimmt. Trotzdem braucht man auch da den korrekten "Nullpunkt", der in diesem Fall über mehrere Definitionen festgelegt wird. Man muss sich in diese Thematik tatsächlich etwas einarbeiten und vergisst ohne permanente Übung dann auch wieder die Details. Die meisten Hobbyastronomen lassen das einfach weg und nehmen fertige Sternkarten wie z.B. Cartes Du Ciel oder das bereits bekannte Stellarium. Ganz generell muss man sich bei Sternkarten aber immer Gedanken darüber machen, wie Erdposition, Geographische Position des Beobachters, Datum und Uhrzeit zusammenhängen. Interessant wird die Sache, wenn man Sternkarten z.B. für Australien berechnet, weil bei den denen der Sternhimmel auch in der Realität tatsächlich auf dem Kopf steht. Wenn die Software das dann richtig darstellt, weiß man, dass man die Grundlagen gut umgesetzt hat.

BTW: Nette Homepage. Beschäftigst Du Dich auch mit Lösungsalgorithmen für Rubiks Cube oder geht es Dir dabei eher um das Rendern von Grafiken?
Gruß
 

Hellstorm

Registriertes Mitglied
Ich mach eigentlich alles querfeldein. Mein Spektrum an Hobbys umfasst das Erstellen von Grafiken, oder auch physikalische Simulationen im Rahmen der 3D-Software, Klavierspielen, Diablo II+III ( :D ) und eben jede Menge Astronomisches. Einen Rubiks hab ich immer in der Jackentasche, aber mathematisch hab ich den bisher noch nicht betrachtet. Ich hab momentan auch einige PHP-Projekte nebenbei laufen (eine minimalistische Template-Engine, CMS, diverse kleine Berechnungen...) aber ich will auch nicht komplett verneinen, dass ich nicht irgendwann mal auf die Idee käme, irgendeinen Rubiks-Algorithmus in PHP auszuprobieren :D

Momentan muss ich aber diesbezüglich auch erstmal wieder meine Mathematik-Kenntnisse auffrischen. Das letzte mal, dass ich schulisch etwas mit Integralrechnung usw. zu tun hatte, ist auch schon teilweise an die 10 Jahre her.
 

Bernhard

Registriertes Mitglied
aber ich will auch nicht komplett verneinen, dass ich nicht irgendwann mal auf die Idee käme, irgendeinen Rubiks-Algorithmus in PHP auszuprobieren :D
Na da hast Du ja einiges vor :D . Nein im Ernst. Algorithmus wird zwar bei den Würfelfans gerne als Bezeichnung verwendet, aber letztlich hat das mit Mathematik recht wenig zu tun. Wenn Dich das näher interessiert schau Dir mal die Lösungsmethoden bei http://www.speedcubers.de/ an. Es gibt auf YouTube ebenfalls gute Anleitungen, wie z.B. für die intuitive Friedrich-Methode. Damit kann man den Würfel zumindest prinzipiell schon recht schnell lösen.
 

Hellstorm

Registriertes Mitglied
Da ich den Würfel als vorbeugende Maßnahme gegen Langeweile löse, achte ich nicht so auf die Zeit. Ich nehm da meistens die modifizierte Spiegelvariante. Die braucht zwar doch recht viele Drehungen, aber dauert dafür auch "immerhin" zwischen 2 und 3 Minuten. So geht die Zeit vorbei ohne dass ich das Ding zig mal verdrehen und entdrechen muss! :D
 

Bernhard

Registriertes Mitglied
Ich nehm da meistens die modifizierte Spiegelvariante.
Was verstehst Du da unter modifiziert?

Mir wäre die reine Anfängermethode (auch SPIEGEL-Methode) auf Dauer zu langweilig. Gerade das Bilden der Friedrich-Pärchen auf der untersten Ebene finde ich immer wieder recht spannend, weil es da etliche verschiedene Möglichkeiten gibt. Die dritte Ebene dauert bei mir auch ziemlich lange.
Gruß
 

Hellstorm

Registriertes Mitglied
Da müsste ich wohl mal den Link dazu rauskramen. Es gibt ja eine Lösungsmöglichkeit, die vor einigen Dekaden mal im Spiegel abgedruckt war. Und davon gibt es ja mittlerweile Abwandlungen, die an einigen Stellen (soweit ich weiß vorallem in der untersten Ebene) einige Drehungen einsparen.
 
Oben