Astro-Daten

[mimi]

Ich weiß das das Thema alt ist, aber ich wollte jetzt auch nicht extra ein neuen Thread dazu aufmachen.

Ich nutze inzwischen die neue Unit unter Lazarus.

Bei der neuen, wie bei der alten, gibt es bei Sun_Rise Abweichungen.
Heute z.b. sollte laut Refernezn Quellen im Internet die Sonne um 07:04 Uhr aufgehen, aber laut Unit um 05:34. Rechnet man 1 Stunde und 30 Minuten hinzu passt es wieder.
Wie kommt es zu dieser "Abweichung"?

Code:

procedure TForm1.BitBtn1Click(Sender: TObject);
begin
  writeln('ctAstronomical: ',DateTimeToStr(Sun_Rise(Now,+53.143889,+8.213889,ctAstronomical)));
  writeln('ctNautic: ',DateTimeToStr(Sun_Rise(Now,+53.143889,+8.213889,ctNautic)));
  writeln('ctZivil: ',DateTimeToStr(Sun_Rise(Now,+53.143889,+8.213889,ctZivil)));
  writeln('ctGeneral: ',DateTimeToStr(Sun_Rise(Now,+53.143889,+8.213889,ctGeneral)));
  writeln('ctNull: ',DateTimeToStr(Sun_Rise(Now,+53.143889,+8.213889,ctNull)));

end;

Ich habe die Position für Oldenburg(Oldenburg) Angegeben.
Oder mache ich noch was Falsch?

[jfheins]

Ich tippe auf
1. eine Stunde weil wir aktuell Sommerzeit haben. Winterzeit wäre der Sonnenaufgang schon um 6:04
2. eine halbe Stunde, weil Oldenburg nicht in der Mitte der Zeitzone liegt. Die Astro-Zeit ist dann die "tatsächliche, lokale" Zeit, Oldenburg liegt mit 8° schon weit von der Mitte (15°) entfernt.

[mimi]

Währe auf jedenfall eine Erklärung.

Wie könnte man das "Ausgleichen"? Sommerzeit/Winterzeit könnte man ja noch hinzurechnen das wäre nicht das Problem, aber die Halbestunde. Müsste ich jetzt die angeben koordinaten weiter anpassen?

Ach ja: Ich kann auch die Werte aus der uTable unit nehmen, dass ist das gleiche...

[jfheins]

Du müsstest wissen, welche Zeitzone dort herrscht, das ist schon mal ein Thema für sich. In diesem Fall MESZ, also UTC+2.

Für jede Stunde UTC+ rechnest du 15° vom Nullmeridian, dann bist du bei +30°. Die Differenz aus diesem Wert und deiner östlichen Länge (8,213889) ergibt 21,786111°. Oder in Stunden ausgedrückt (1h = 15°) sind das 1,4524074 Stunden. Kann das hinkommen?

[mimi]

Zitat:

Oder in Stunden ausgedrückt (1h = 15°) sind das 1,4524074 Stunden. Kann das hinkommen?

Noch nicht so ganz: So müsste es laut Referenz sein:
2015-01-01 08:41:19
Das kommt von einer Perl Lib.
Aber so ist es laut Astro Unit
2015-01-01 08:59:10
Es sind also fast 20 Minuten zu viel.
Aber wir nähern uns.

Delphi-Quellcode:

procedure TForm1.BitBtn1Click(Sender: TObject);
var
  SunRise,SunSet,DT:TDateTime;
  YY, MM, DD, H, M, S, MS:Word;
  I1,I2, DM:integer;
  D:TDate;
begin
  InitLocale; // Muss das gemacht werden? Ändert jedenfalls nichts.
  for I1:=1 to 12 do begin
    DM:=DaysInAMonth(2015,I1);
    for I2:=1 to DM do begin
      D:=EncodeDate(2015,I1,i2);
      SunRise:=Sun_Rise(D,+53.143889,+21.786111,ctZivil); // 8.213889
      Memo1.Lines.Add(DateTimeToStr(SunRise));
    end;
  end;
end;

[mimi]

Neue info:
Wenn ich von ctZivil auf ctGeneral umstelle klappt es. Dann gibt es kaum noch Abweichungen. Dann muss ich im Winter nur noch 1 Stunde abziehen.
Wenn ich jedoch ctAstronomical meint die Unit, dass die Werte nicht errechenbar sind. Ab 2015-05-15.

Delphi-Quellcode:

procedure TForm1.BitBtn1Click(Sender: TObject);
var
  SunRise,SunSet,DT:TDateTime;
  YY, MM, DD, H, M, S, MS:Word;
  I1,I2, DM:integer;
  D:TDate;
begin
  InitLocale;
  for I1:=1 to 12 do begin
    DM:=DaysInAMonth(2015,I1);
    for I2:=1 to DM do begin
      D:=EncodeDate(2015,I1,i2);
      SunRise:=Sun_Rise(D,+53.143889,+21.786111,ctGeneral); // 8.213889 //21.786111
      Memo1.Lines.Add(DateTimeToStr(SunRise));
    end;
  end;
end;

Nun gibt es nur noch eine Sekunde Abweichung.

Edit1: Im Sommer sind die Abweichungen größer. Aber noch im Sekunden Bereich.

[mimi]

Ich habe noch ein paar Fragen zur Unit:
1. Warum ist das bei dieser Unit, anders beim Sonnenaufgang/Untergang als es andere machen?
Z.b. habe ich ein Code für Arduino gefunden, der macht es so, wie ich es erwarte und wie es alle anderen machen(Die Berechneten Zeiten stimmen mit den von verschiedenen Wetter-Diesten überein).
Außerdem habe ich noch ein Perl Skript gefunden, die es auch genau so machen.

2. Könnte man es die Übergabe der Koordinaten vereinfachen?
Wenn es wirklich der Mittelpunkt der Zeitzone sein muss.

3. Könnte man in der Unit am Anfang darauf hinweisen? Auf diese Abweichungen?

Ich finde die Unit nicht schlecht und bin schon froh das sie unter FPC läuft. Kann das der Grund für die Abweichung sein?

[markus5766h]

... ist zwar schon etwas her, aber . . .

zum Sonnenaufgang - habe heute mal im Netz die Werte für den Sonnenaufgang für Hamburg aufgerufen (Wetterdienste und andere),
Ergebnis : 10 verschiedene Zeiten in einem Zeitraum von 30 Minuten (ohne Angabe der Bezugsposition) - und genau hier liegt das Problem : ohne die Berechnungsparameter zu kennen, ist ein Vergleich nicht möglich, einige werden wohl für die exacte geogr. Position berechnen, andere für gerundete Positionswerte oder die "Mitte" der Zeitzone . . .

[Mavarik]

Was ist mit der Sternzeit? Könnte JamesTKirk Interessieren...

Hast Du auch etwas um die Position der Planeten im Sonnensystem mit den Monden darzustellen?

[BoolString]

Sorry, wenn ich mich hier jetzt kurz einmische bezüglich der berechneten Zeiten.

Ich habe die Unit nicht getestet, habe aber vor einigen Jahren auch mal mit den Algorithmen von Jean Meeuse (Buch: Astronomische Algorithmen, 1994) zu tun gehabt.

Die Internationale Astronomische Union (IAU) hat festgelegt, daß das Längengradsystem eines Planeten immer positiv entgegen der Planetenrotation gezählt wird. Bei der Erde ist das der einzige Planet bei dem das anders herum ist (historische Gründe; man fing an Längengrade zu nutzen, bevor man über allgemeine Sachen nachdachte). Nun war Meeus aber sehr stark im IAU System verhaftet und hat seine Algorithmen entsprechend allgemein aufgebaut.

Mich hat es damals einiges an Zeit gekostet, die Abweichungen wirklich zu verstehen. Der Fehler lag bei mir einfach darin, daß man positiv/negativ im Längengrad umkehren musste. Hast du entsprechend mal etwa -8 (minus 8 Grad) für Oldenburg probiert an Stelle der offiziellen Zählung von +8 ???

Da wir nahe am vereinbarten Nullmeridian leben, ist man schnell versucht, solche verhältnismäßig geringen Abweichungen 'schönzuerklären'. Ein Versatz von 1.5 Stunden könnte hier durchaus im Rahmen dieser plus/minus Geschichte liegen.

Deutlicher wird der Fehler, wenn man Orte mit größeren longitudinalen Werten berechnet (Moskau, Delhi, Sydney, Washington, San Francisco, ...)

Ist nur so eine Idee....

Insgesamt ist es aber natürlich auch so, das meist die Mitten der Zeitzonen angegeben werden (der Breitengrad hat natürlich zusätzlich auch einen Einfluss). Das schöne an den Algos von Meeus ist aber, das man die realen, ortsbezogenen Daten relativ gut berechnen kann... und die weichen immer etwas von offiziell tabulierten Werten ab...

Einige Minuten Abweichung ergeben sich teils auch schon aus unterschiedlichen Algorithmen, die unterschiedliche Näherungen produzieren. Aber sind wir mal ehrlich: ob die Sonne um 06:30 oder um 06:32 aufgeht ist eher irrelevant für die meisten irdischen Anwendungen. Spätestens wenn eine Wolke am Himmel ist, kann ich daraus wenig allgemeine Lichtverhältnisse ableiten...

Das schwer erhältliche Buch von Meeus (Scan, 72.1 MB) darf ich aus copyright Gründen natürlich auf gar keinen Fall an jemanden weiterreichen, der zu mir per PN Kontakt aufnimmt...

Jan