[Bugfix] Azimutberechnung

Hallo,
hier die Lösung zum hier berichteten Bug:

betroffen
Datei „<ipsverzeichnis>\web\modules\weather\weather.ips.php“
function „public function azimut ($bKarte, $lKarte ) {“

Folgender Abschnitt ist zu ergänzen:


    //Berechnung Azimut
//    $azi =asin(cos($x1) * sin($x2) / cos($sh));
//    $azi1 = 180 + rad2deg($azi);
// Debug Azimutberechnung im NW- und NO-Sonnenquadranten / gw 23.01.2008
    $op = 0;           // Ostpunkt
    $wp = 0;           // Westpunkt
    $tw = 0;           // Tageswinkel
    if (tan($x3) != 0) {
      $op = -1 * acos(tan($x1) / tan($x3)) ;
      $wp = acos(tan($x1) / tan($x3)) ;
    }
    if (cos($x3) * cos($x1) != 0){
       $tw = rad2deg( acos( (sin(-0.833) - sin($x3) * sin($x1)) / (cos($x3) * cos($x1)) ) );
    }
    
    
	//echo "Tageswinkel / Ost- / Westpunkt:".($tw)." / ".($op)." / ".($wp)."
";

    $azi = rad2deg( asin(cos($x1) * sin($x2) / cos($sh)) );
    $azi1 = 180 + $azi;       // SO- u. SW-Quadrant
    if ($x2 < $op) {          // NO-Quadrant
       $azi1 = 0 - $azi;
       //echo "NO
";
    } elseif ($x2 > $wp) {    // NW-Quadrant
       $azi1 = 360 - $azi;
       //echo "NW
";
    }
// ENDE Debug Azimutberechnung im NW- und NO-Sonnenquadranten / gw 23.01.2008

    $azi1s = sprintf("%1.2f",$azi1);


Hintergrund:
Die vorher verwendete Berechnungsvorschrift macht lt. Quelle eine Unterscheidung / erfordert eine abschließende Wertekorrektur hinsichtlich der Himmelsquadranten, in der sich die Sonne befindet. Das fehlte bisher im Script.

Im Original wird ein Verfahren verwendet, dass (gültig im Bereich der Breitengrade < -23,4° bzw > 23,4°) unterhalb des „Ostpunktes“ bzw. oberhalb des „Westpunktes“ eine Wertekorrektur erfordert. Das in der Literatur beschriebene Verfahren kollidiert jedoch mit der hier im WIIPS schon vorgenommenen Koordinatentransformationen (generell +180°), die aber eben nur für die „beiden Sonnenquadranten links und rechts von Mittag“ korrekt war, für die im Original gar keine Korrektur erfolgte (0° dort in Süd statt wie hier in Nord).

Folge war, dass morgens und abends, konkret bei Azimutwerten <90° oder >270° diese nicht errechnet wurden, sondern „die Sonne wertemäßig nachts über Süd nach Osten zurücklief“.

Die o.g. Korrektur (< Ostpunkt 0 - Rohwert; > Westpunkt: 360 - Rohwert, sonst 180 + Rohwert) ist ebenfalls nicht das in der Literatur verwendete Verfahren (< Ostpunkt: -180 + Rohwert; > Westpunkt: 180 - Rohwert / sonst = Rohwert), sondern beinhaltet bereits die Anpassung an die hier verwendete 0°-Korrektur nach Nord.

Was soll das ganze?

Beispiel 1: Sonnenstandsanzeiger im Designer
Azimut = waagerechte Trackbar von Nord über Ost, Süd, West bis wieder N bei 360,
senkrecht Deklination und Sonnenwinkel mit Mitte=0=Horizont für „Grad der Tiefe“ der Nacht bzw. des (wohl nur noch theoretisch existierenden) Winters

Beispiel 2: Cam-Steuerung / Schutz
um z.B. ganz praktisch zu verhindern, dass eine bewegliche und nachführbare Webcam in die Sonne schaut und dabei Schaden nimmt.

Beispiel 3: Sonnen-Einstrahlberechnung auf Fenster eines Hauses, um z.B. (ob überhaupt Sonne zusätzlich per WS2000-Helligkeitssensor getriggert) bei direkter Sonnenbestrahlung Jalousien nachzuführen

Dafür braucht man diesen Wert aber gerade auch Früh und Abends sauber, um gerade in Horizontnähe reagieren zu können.

Den ebenfalls zusätzlich aufgenommenen Tagwinkel habe ich im Script stehen lassen, falls der für jemanden interessant sein sollte. Zuerst wollte ich darüber die Ost- und Westpunkte berechnen (an Süd einfach halbieren), jedoch stimmen die durchaus nicht mit Auf- und Untergangspunkt der Sonne überein, sondern sind offenbar reine Rechenwerte für die Quadrantenkorrektur (wann sind Azimut = 90 bzw. =270° erreicht)!

Gruß Gerd