Neues Tool "Moon and Darkness Calendar"

[sphere]

Hallo zusammen,

ich freue mich, euch mein kleines Web-Tool, den Moon and Darkness Calendar, vorzustellen! Ich habe es ursprünglich für mich selbst entwickelt, aber es könnte auch für andere in der Astronomie-Community nützlich sein. Die Website erstellt einen Kalender für die nächsten 30 Tage, basierend auf dem Standort, den ihr eingebt. So zeigt sie Mondphasen, Dunkelheitsstufen (civil, nautical, astronomical) und Zeiträume an, in denen der Mond über dem Horizont steht – und das für jede Nacht.

Ein paar Screenshots:

Hier könnt ihr es öffnen: https://dersphere.github.io/moon-and-darkness-calendar/

Ich nutze Tools wie clearoutside.com sehr gern, allerdings zeigt es nur die nächsten sieben Tage an. Wenn ich z. B. einen Standort und ein Datum für einen zukünftigen Urlaub überprüfen möchte, finde ich oft kein passendes Tool. Genau deshalb habe ich den Mond- und Dunkelheitskalender erstellt.

Nachdem Version 1 auf astrobin und cloudynights letzte Woche veröffentlicht wurde, habe ich viel Feedback erhalten und in Version 2 umgesetzt.

Hier die wichtigsten Features:​

• Balken für Dunkelheit und Mondphasen: Es werden Balken für einen 24h Zeitraum (12:00 Mittags bis 12:00 Mittags am nächsten Tag) angezeigt. Die Mondbalken zeigen mit ihrer Helligkeit die Helligkeit des Mondes, die Dunkelheitsbalken zeigen die Dunkelheitsstufe.
• Integrierte Zeiten für wichtige Ereignisse: Mondaufgang, Monduntergang und Beginn/Ende der astronomischen Nacht werden direkt in den Balken angezeigt. Die Zeiten erscheinen beim Hover oder können für mobile über eine Checkbox ein- und ausgeblendet werden.
• Stundenlinien: Volle Stunden können in den Balken angezeigt werden – entweder beim Hover oder über eine Checkbox immer sichtbar.
• Überlappungsbalken: Zwischen den Dunkelheits- und Mondbalken gibt es einen grünen Balken, der ideal geeignete Zeiträume für die Himmelsbeobachtung (bisher noch ohne Berücksichtigung des Wetters) hervorhebt.
• Nacht-Details: Es kann jeder Tag geklickt werden, um detaillierte Informationen wie die Dauer der Dunkelheit oder Monddaten zu sehen.
• Mondphase und Beleuchtung: Mondphase und Beleuchtungsprozentsatz sind direkt neben dem Tagesindikator sichtbar, ohne dass Hovers oder Overlays nötig sind.

Vielen Dank für euer Feedback und die Unterstützung! Ich hoffe, ihr findet das Tool hilfreich und ich freue mich auf euer Feedback.

clear skies und Grüße,
Tristan

PS. das Tool is open source

 

[Nachtschwalbe]

sehr schön gemacht ! Wird es das auch mal als App geben ?
Danke fürs zeigen,
vG Alex

 

[Denebolus]

Moin zusammen,

App wäre IMHO nicht nötig, die Webseite ist doch prima „responsive“, passt sich doch auf mobilen Geräten der Ansicht an.

Großes Lob an Tristan

Klare Nächte,
Micha

 

[sphere]

Danke. Ja, wie Micha geschrieben hat kann man Webseiten sehr einfach zum Homescreen von iOS und Android hinzufügen. Ich müsste nur ein Icon einbauen damit es auch schön aussieht. Aber dann fühlt es sich genau so an wie eine App.
Grüße!

 

[h_c_greier]

Hallo Tristan,

schön, dass es noch Menschen gibt, die so etwas selbst programmieren und dann noch gratis ins Netz stellen! Bravo!

Ich habe deine App durchgesehen und habe Folgendes anzumerken:

• Optik sehr schön. Übersichtlich, auch wenn ich persönlich das "liegende Format" bevorzuge (Tage auf der Abszisse, Stunden Ordinate). Die farbigen Unterlegungen zeigen die täglichen Änderungen sehr gut. Die Idee mit dem grünen Überlappungsbalken finde ich gut.
• Dass du die zusätzlichen Daten in so ein Aufklapp-Akkordion gepackt hast ist sehr gut.
• Das Ding ist bereits eine App, es funktioniert auch auf dem Handy, es gibt keinen Grund, das Ganze jetzt dem GooglePlay oder AppleStore in den Schlund zu werfen! (Wozu auch, zumal das mit Auflagen einhergeht, die keinen Spaß machen).

• Woraus ich leider nicht schlau werde: Die Mondauf-/Untergangszeiten sind irgendwie verwürfelt. Wenn man z.B. den 15.Oktober 2024 ausklappt, beziehen sich dann die Angaben "Moonrise" und "Moonset" BEIDE auf den Tag 15.10.? Falls ja, dann stimmt da was nicht.

Hier ein Test für die drei Tage 1./15./30. Oktober 2024

Mondauf-/Untergang
Location: 50°N 10°E 

GUIDE 8
Zeiten in MESZ
                Auf     Unter
01.10.2024     05:44    18:36
15.10.2024     17:42    04:35
30.10.2024     05:50    17:06


Moon and Darkness Calendar
Zeiten in MESZ
                Auf        Unter
01.10.2024     06:51:04    18:40:43
15.10.2024     17:42:05    06:14:27
30.10.2024     05:55:00    16:08:55

• Die Zeiten der Dämmerungen, die direkt inline stehen würden gerundet gehören. Z.B. steht am 2.10.2024 bei "Astronomical Darkness" 20:45:57, was gerundet dann wohl 20:46 in der Grafik wäre. Für Mond Auf-/Untergang gilt Analoges.

• Bitte - Please - Per favore - Por favor - S'il te plaît: Auf-/Untergangszeiten sekundengenau anzugeben ist ein UNDING! Das ist ausgesprochen theoretisch. Bitte auf ganze Minuten runden. Bei entsprechend schwankenden Witterungen stimmen nämlich nicht mal diese, mal ganz abgesehen vom lokalen Horizont, der bei jedem anders ist.

• Ich bitte auch um eine Erklärung was genau mit "Moon Illumination Angle: The angle of the moon's illumination." gemeint sein soll?


Sehr schönes Tool, ist in den Bookmarks! Kleinigkeiten ausbessern und weiter so!

cs,
harald

--

 

[sphere]

Woraus ich leider nicht schlau werde: Die Mondauf-/Untergangszeiten sind irgendwie verwürfelt. Wenn man z.B. den 15.Oktober 2024 ausklappt, beziehen sich dann die Angaben "Moonrise" und "Moonset" BEIDE auf den Tag 15.10.? Falls ja, dann stimmt da was nicht.

Hi Harald, vielen Dank für dein Feedback!

Genau hier handelt es sich denke ich um die Besonderheit die mich recht viel Arbeit bei der Entwicklung gekostet hat bzw. die ich nicht in anderen Apps/Webseiten finden konnte:
In der App steht eine Nacht im Fokus - nicht ein Tag.
Also immer noch ein Zeitraum von 24h - aber eben nicht 00:00-24:00 sondern 12:00 (am "Ersten Tag")-12:00 (am "Folgetag").
In einem Zeitfenster von 24h gibt es ja immer nur maximal einen Auf- und einen Untergang. Die Reihenfolge ist allerdings unterschiedlich.

Viele Webseiten machen das einfach falsch bzw. gegen die Intuition in des Nutzens. Für uns ist wichtig wann die Sonne bzw. der Mond auf und untergeht bezogen auf eine Nacht (und eine Nacht hat nun mal Komponenten in zwei Tagen). Also müssen wir in "klassischen" Tabellen (manchmal) in zwei Tagen gucken.

Auf deine Beispiele bezogen:
Nacht 15.10 auf 16.10 (Deine Koordinaten und alles in MESZ)
15.10.2024 04:49:52 Untergang
(dunkel)
15.10.2024 17:42:05 Aufgang
(hell)
16.10.2024 06:14:27 Untergang
(dunkel)
16.10.2024 17:56:29 Untergang
Also die "Mondfreie Zeit" ist hier als 17:42 bis 06:14 und nicht 04:49 dargestellt.

Nacht 01.10 auf 02.10 (Deine Koordinaten und alles in MESZ)
01.10.2024 05:43:21 Aufgang
(hell)
01.10.2024 18:40:43 Untergang
(dunkel)
02.10.2024 06:51:04 Aufgang
(hell)
02.10.2024 18:51:03 Untergang
Also die "Mondfreie Zeit" ist hier als 18:40 bis 06:51 dargestellt.

Die Rechnerei für den 31.10. erspare ich mir hier - der Unterschied in Definition dürfte klar sein
Ich werde allerdings in der nächsten Version der App in der Tabelle die Tage ergänzen damit das klarer wird, Danke!

• Bitte - Please - Per favore - Por favor - S'il te plaît: Auf-/Untergangszeiten sekundengenau anzugeben ist ein UNDING! Das ist ausgesprochen theoretisch. Bitte auf ganze Minuten runden. Bei entsprechend schwankenden Witterungen stimmen nämlich nicht mal diese, mal ganz abgesehen vom lokalen Horizont, der bei jedem anders ist.

Bei dem Runden bin ich nicht ganz überzeugt. Ich stimme natürlich vollkommen zu, dass es hier nicht "auf Sekunden ankommt" (wieder im Sinne des Nutzens). Allerdings würde ich die Interpretation, das aufschlagen von besonderen Faktoren und Puffern lieber dem Nutzer überlassen - die Zeiten sind halt nicht "falsch". Vor allem wenn ich die Angabe des Zeitpunktes wie oben angekündigt auf YYYY-MM-DD HH:mm:SS verändere fände ich es "falscher" hier zu runden (oder Sekunden abzuschneiden). Ich denke aber noch darüber nach...

Grüße,
Tristan

 

[h_c_greier]

Viele Webseiten machen das einfach falsch bzw. gegen die Intuition in des Nutzens. Für uns ist wichtig wann die Sonne bzw. der Mond auf und untergeht bezogen auf eine Nacht (und eine Nacht hat nun mal Komponenten in zwei Tagen). Also müssen wir in "klassischen" Tabellen (manchmal) in zwei Tagen gucken.

Das ist mir schon klar, dass hier die Abfolge Mondaufgang Tag X → Monduntergang Tag X+1 bzw. Monduntergang Tag X → Mondaufgang Tag X+1 gefragt ist.

Ich habe nun GUIDE 8, Stellarium sowie ein eigenes Script befragt. Ich habe in GUIDE/Stellarium den oberen Mondrand auf Horizont gestellt, um den Auf-/Untergang mit Sekunden zu ermitteln, wenn's denn unbedingt sein muss. (Bei Stellarium wurde "Atmosphäre" abgeschaltet, um die Refraktion auszuschließen.)

Mond
Location: 50°N 10°E
Nacht 15/16. 10. 2024

Aufgang
GUIDE 8     15.10.2024   15:42:24 UT = 17:42:24 MESZ
Stellarium  15.10.2024                 17:40:38 MESZ
MDC         15.10.2024                 17:42:05 MESZ
Script      15.10.2024                 17:42 MESZ

Untergang             
GUIDE 8     16.10.2024   04:03:51 UT = 06:03:51 MESZ
Stellarium  16.10.2024                 06:05:47 MESZ
MDC         16.10.2024                 06:14:27 MESZ
Script      16.10.2024                 06:04 MESZ

Man erkennt: Aufgang passt, Untergeng ist hier 8-10min daneben. Es gibt also schon Abweichungen.

Ich verstehe aber, dass Runden unbequem ist, denn man läuft da programmiertechnisch in lästiges Terrain. Wenn zB herauskommt 2024-10-xx 06:59:51, und man rundet auf ganze Minuten, dann hat man 2024-10-xx 07:00, man muss also einen kaskadenartigen Effekt berücksichtigen. Noch schlimmer wäre es, wenn es sogar zu einem Tages-Überlauf käme.

cs,
harald

--

 

[sphere]

Das ist mir schon klar, dass hier die Abfolge Mondaufgang Tag X → Monduntergang Tag X+1 bzw. Monduntergang Tag X → Mondaufgang Tag X+1 gefragt ist.

Ok, Entschuldigung - da hatte ich dich wohl misserstanden, mein Fehler.

Man erkennt: Aufgang passt, Untergeng ist hier 8-10min daneben. Es gibt also schon Abweichungen.

Ich befürchte, dass du auch hier recht hast. Da muss ich mal auf Ursachensuche gehen...

Ich verstehe aber, dass Runden unbequem ist, denn man läuft da programmiertechnisch in lästiges Terrain. Wenn zB herauskommt 2024-10-xx 06:59:51, und man rundet auf ganze Minuten, dann hat man 2024-10-xx 07:00, man muss also einen kaskadenartigen Effekt berücksichtigen. Noch schlimmer wäre es, wenn es sogar zu einem Tages-Überlauf käme.

Och, das geht... Ich rechne in der App permanent mit timezone-aware Date() Objekten und benutze Intl (Intl - JavaScript | MDN) - ist mittlerweile komplett unterstützt. Auf ganze Minuten runden wäre also einfach 30 Sekunden dazu und dann die Sekunden abschneiden. Da muss man nichts mehr "von Hand" kaskadieren ?.


Ich melde mich falls ich das Rätsel um die 10 Minuten gelöst habe. Heute morgen hatte ich übrigens eine neue Version veröffentlicht, die die Tage bei den Mondzeiten anzeigt - das war eine gute Idee, Danke!

Grüße,
Tristan

 

[h_c_greier]

Hallo Tristan,

das Problem scheint hier zu liegen.
Deine Funktion moonCoords(d) berechnet die geozentrischen ekliptikalen Koordinaten ohne Korrekturterme und wandelt diese dann in äquatoriale Koordinaten um.

function moonCoords(d) {
      const L = rad * (218.316 + 13.176396 * d); // ecliptic longitude
      const M = rad * (134.963 + 13.064993 * d); // mean anomaly
      const F = rad * (93.272 + 13.229350 * d); // mean distance
      const l = L + rad * 6.289 * sin(M); // longitude
      const b = rad * 5.128 * sin(F); // latitude
      const dt = 385001 - 20905 * cos(M); // distance to the moon in km

      return {
          ra: rightAscension(l, b),
          dec: declination(l, b),
          dist: dt
      };
  }

Wirklich? Ich sehe hier keinerlei Korrekturen zur Ellipsenbahn. Eine konstante Ekliptikschiefe - wie sie bei der Umrechnung in RA/DEC verwendet wird - würde ich mir ja noch einreden lassen, man nehme einfach jene von J2000.

Ich rechne in der App permanent mit timezone-aware Date() Objekten

Das halte ich für keine gute Idee bei astronomischen Berechnungen.
Die Date()-Klasse von JavaScript halte ich bei meinen Scripts so weit wie möglich aus Berechnungen raus.
Lediglich zum Auslesen der momentanen Systemzeit, und dann wird mit den Date-Methoden getUTCFullYear(), getMonth(), usw..., und die Zeitzone geholt und alle in eine entsprechende Variable gesteckt.
Ich rechne mit dem Julianischen Tag JD (bzw. JDE, wenn die Eingabe dyn. Zeit TD ist) bzw. seiner Rückrechnung in ein Kalenderdatum. Die Date-Klasse beruht ja auf der Unix-Epoche vom 1.1.1970.
Die String-Rückgaben sind auch nicht so der Burner, finde ich, selten hat man das so wie man's haben will für die Ausgabe.
Aber schon OK, ist nur meine persönliche Meinung, nix für ungut.

cs,
harald

--

 

[sphere]

Hallo Tristan,

das Problem scheint hier zu liegen.
Deine Funktion moonCoords(d) berechnet die geozentrischen ekliptikalen Koordinaten ohne Korrekturterme und wandelt diese dann in äquatoriale Koordinaten um.

function moonCoords(d) {
      const L = rad * (218.316 + 13.176396 * d); // ecliptic longitude
      const M = rad * (134.963 + 13.064993 * d); // mean anomaly
      const F = rad * (93.272 + 13.229350 * d); // mean distance
      const l = L + rad * 6.289 * sin(M); // longitude
      const b = rad * 5.128 * sin(F); // latitude
      const dt = 385001 - 20905 * cos(M); // distance to the moon in km

      return {
          ra: rightAscension(l, b),
          dec: declination(l, b),
          dist: dt
      };
  }

Wirklich? Ich sehe hier keinerlei Korrekturen zur Ellipsenbahn. Eine konstante Ekliptikschiefe - wie sie bei der Umrechnung in RA/DEC verwendet wird - würde ich mir ja noch einreden lassen, man nehme einfach jene von J2000.

Vielen Dank für den Hinweis, da hast du den Nagel auf den Kopf getroffen.

Ich habe soeben eine neue Version veröffentlicht die unter anderem deutlich genauere Mondzeiten erlaubt (basierend auf astronomy engine, hier die entsprechenden Korrekturen für die Mondbahn).

Bitte gib mir sehr gerne Bescheid falls du noch andere Probleme findest!

Grüße,
Tristan

 

[h_c_greier]

Hallo Tristan,

die Auf-/Untergangszeiten funktionieren jetzt. Habe aber nur ein paar Daten getestet (1.10, 15.10, 31.10), aber die passen, auch die dazu gehörenden Azimute.

Zu den Dämmerungszeiten:
Die Uhrzeiten scheinen zu passen, aber:
Die bürgerliche Dämmerung beginnt nicht bei Sonnenhöhe = -6°, sondern sie endet dort.
So gesehen wäre es vielleicht besser, von bürgerlicher Dämmerung "am Abend" ("civil dusk" am Tag X) und bürgerlicher Dämmerung "am Morgen" ("civil dawn" am Tag X+1) zu sprechen.

Weiteres:

Die Angabe z.B.:
Moon Phase 31.10.2024, 00:00:00 Waning Crescent (2.2% illuminated, Age: 28 days)
finde ich etwas seltsam.

[1] Warum die Angabe um 00:00 Uhr bei den Mondphasen? Man könnte ja die Zeiten der Mondphasen berechnen für das laufende Monat. Das sind dann 4 bzw. 5 Daten+Uhrzeiten, die sich über den Monat hinweg nicht ändern.

[2] was für 00:00:00? UT, MESZ, MEZ? Ich habe das für MEZ getestet, und die Daten sind 2.16% Beleuchtung und 28.17 Tage Mondalter. Die Daten stimmen also, aber du solltest mMn die Zeitzone dazu schreiben.

cs,
harald

--

 

[sphere]

Hallo Tristan,

die Auf-/Untergangszeiten funktionieren jetzt. Habe aber nur ein paar Daten getestet (1.10, 15.10, 31.10), aber die passen, auch die dazu gehörenden Azimute.

Perfekt, danke für deine Mühe!

Zu den Dämmerungszeiten:
Die Uhrzeiten scheinen zu passen, aber:
Die bürgerliche Dämmerung beginnt nicht bei Sonnenhöhe = -6°, sondern sie endet dort.
So gesehen wäre es vielleicht besser, von bürgerlicher Dämmerung "am Abend" ("civil dusk" am Tag X) und bürgerlicher Dämmerung "am Morgen" ("civil dawn" am Tag X+1) zu sprechen.

Hier bin ich nicht sicher, ob ich deinen Kommentar verstehe, aktuell zeige ich die folgenden Werte:

<tr>
    <td>Civil Darkness</td>
    <td>${formatDate(rowData.sunCivilDuskTime, 'YYYY-MM-DD HH:mm:ss')}</td>
    <td>${formatDate(rowData.sunCivilDawnTime, 'YYYY-MM-DD HH:mm:ss')}</td>
    <td>${formatDuration(rowData.sunCivilDuskTime, rowData.sunCivilDawnTime)}</td>
</tr>

Also bei "Civil Darkness" zeige ich als Zeitraum zwischen CivilDuskTime und CivilDawnTime. Ich benutze ja bewusst nirgendwo den Begriff "Dämmerung".

Weiteres:

Die Angabe z.B.:
Moon Phase 31.10.2024, 00:00:00 Waning Crescent (2.2% illuminated, Age: 28 days)
finde ich etwas seltsam.

Ich war ehrlich gesagt unsicher welchen Zeitpunkt genau ich in diesem 24h Fenster ich für die Berechnung der Mondphase, Illumination und Moon-age nehmen sollte. Also habe ich mich für "die Mitte" des Zeitfensters entschieden. Und um dabei Missverständnissen vorzubeugen dachte ich, es würde Sinn machen, den Zeitpunkt auch mitzuteilen - deswegen steht es dort bei.
Welchen Zeitpunkt würdest du empfehlen und wie würdest du diese Entscheidung in den Daten kenntlich machen?
Die meisten Mondkalender Apps scheinen hier sehr inkonsistent zu sein, für den 15.10. benutzen manche scheinbar "15.10. 00:00 Uhr" und manche "15.10 12:00". Aber ich habe ja sowieso keine App gefunden, die sich "auf die nacht als ganzes" konzentriert.
Spontan fällt mir nur ein Datum und Zeit zu entfernen und durch sowas wie "In the middle of the night" or "at midnight" zu schreiben - was denkst du?

[1] Warum die Angabe um 00:00 Uhr bei den Mondphasen? Man könnte ja die Zeiten der Mondphasen berechnen für das laufende Monat. Das sind dann 4 bzw. 5 Daten+Uhrzeiten, die sich über den Monat hinweg nicht ändern.

Ich hatte kurz überlegt ob ich auch Daten für den ganzen Monat übernehmen sollte (also eine Liste wie von dir vorgeschlagen), habe mich dann aber bewusst dagegen entschieden da bisher alle Daten in der Detail-Sektion wirklich nur für die gewählte Nacht gelten. Das macht für mich Sinn da man die anderen Daten (also zB wann genau Vollmond ist etc) ja außerhalb der Detail-Sektion ersichtlich sind.

[2] was für 00:00:00? UT, MESZ, MEZ? Ich habe das für MEZ getestet, und die Daten sind 2.16% Beleuchtung und 28.17 Tage Mondalter. Die Daten stimmen also, aber du solltest mMn die Zeitzone dazu schreiben.

Alle angaben sind aktuell immer in der Zeitzone des Nutzers (bzw. des Browsers). Ich werde mal überlegen wo ich das am besten erwähnen kann.
Allerdings ist ja der Sinn meiner App, dass man auch für entfernte Orte mal schnell schauen kann ob man gute Bedingen zu einem bestimmten Zeitpunkt erwarten kann oder nicht. Hier würde es also aus Nutzersicht eher Sinn machen die Zeitzone der eingegeben Koordinaten zu nehmen. Wenn man zB für Tokyo schauen möchte müsste es ja eigentlich Mitternacht von Tokyo im Zentrum stehen - tut es aber aktuell nicht. Aber ich habe noch keinen guten Weg gefunden von Koordinaten auf Zeitzonen bzw. locales zu schließen.

Grüße,
Tristan

 

[h_c_greier]

Also bei "Civil Darkness" zeige ich als Zeitraum zwischen CivilDuskTime und CivilDawnTime. Ich benutze ja bewusst nirgendwo den Begriff "Dämmerung".

Ist kein großes Ding, ich bin nur lästig

Ich meinte nur, da steht bei den Dämmerungen immer "Start" und "End", was mich verwirrt hat. Vielleicht könnte man dort "Abend" (dusk) bzw. "Morgen" (dawn) schreiben? Im Tages-/Nachtlauf kommt hier ja immer zuerst der "dusk" von Tag X und dann der "dawn" des Tages X+1.

Ich war ehrlich gesagt unsicher welchen Zeitpunkt genau ich in diesem 24h Fenster ich für die Berechnung der Mondphase, Illumination und Moon-age nehmen sollte.

Ach so, ja, ich verstehe, ich habe instinktiv mit meiner App "verglichen".
Dort habe ich nicht von 12:00 Tag X bis 12:00 Tag X+1 genommen, sondern bei mir hab ich von Sonnenuntergang - 5h bis Sonnenaufgang + 5h (oder waren es ±4h, ich weiß nimmer) die Monddaten alle 15min berechnet. So gesehen hast du schon recht, die Phase bei dir um 00:00 anzugeben, da es bei dir immer der "Mittelpunkt" des Verlaufs ist.

Das macht für mich Sinn da man die anderen Daten (also zB wann genau Vollmond ist etc) ja außerhalb der Detail-Sektion ersichtlich sind.

Du meinst die Darstellung der Mondphase links bei den einzelnen Tagen mit der kleinen Grafik? Ja stimmt, da sieht man die Phasen, man kann also sehen, dass der Vollmond am 17.10.2024 sein muss (100%). Das letzte Viertel war aber z.B. im Oktober der 24.10.2024, 09:03 MEZ, was bei dir dann nicht mehr ganz eindeutig erkennbar ist (23.10. → 54%, 24.10. → 44%) usw.
OK, so schlimm ist das auch wieder nicht...Allerdings finde ich die Beleuchtungen in den Grafiken manchmal etwas "sprunghaft". Siehe z.B. 8.10/9.10, da sind 31% bzw. 41% Beleuchtung, was die Grafiken nicht so ganz widerspiegeln. Eventuell müsste man hier feinere Abstufungen machen.

Allerdings ist ja der Sinn meiner App, dass man auch für entfernte Orte mal schnell schauen kann ob man gute Bedingen zu einem bestimmten Zeitpunkt erwarten kann oder nicht. Hier würde es also aus Nutzersicht eher Sinn machen die Zeitzone der eingegeben Koordinaten zu nehmen. Wenn man zB für Tokyo schauen möchte müsste es ja eigentlich Mitternacht von Tokyo im Zentrum stehen - tut es aber aktuell nicht. Aber ich habe noch keinen guten Weg gefunden von Koordinaten auf Zeitzonen bzw. locales zu schließen.

Verstehe. Die Logik der "locales" sollte das machen, wenn ein konkreter Ort angegeben wird. Ein Abschätzung - wenngleich nicht perfekt - wäre die Ermittlung der Zeitzone aus der geograf. Länge, die alle 15° wechselt. Ich weiß, das stimmt nicht, wäre aber ein Ansatz. Längengrad 15° wäre zB die "Mitte" für MEZ, aber auch Madrid mit Länge 3°42'W hat MEZ(!), hingegen London am Meridian hat GMT! Da kommt man also nicht genau hin.

cs,
harald

--

 

[_Jürgen_K]

Hallo Tristan,
sehr schönes Tool. Sehr hilfreich für die Urlaubsplanung.
Wir machen seit geraumer Zeit öfter Urlaub mit dem Auto in Deutschland, oft eben auf Fehmarn oder im Wendland, wo wir dann tagsüber viel mit den Rädern unterwegs sind und ich abends (sofern das Wetter passt) mein Teleskop aufbaue. Meine Frau und ich schauen dann bei der Terminplanung halt immer etwas danach, wie der Mond zu der Zeit seht. Da ist Dein Kalender wirklich eine große Hilfe.
Was mir erst vor Kurzem aufgegangen ist, ist aber, daß allein die Tatsache, dass Vollmond ist nicht immer die gleiche störende Wirkung haben muss. Vollmond ist eben nicht gleich Vollmond !
Manchmal ist der Mond um den Vollmond herum bei einer ALT von über 60° und manchmal ist er aber nur wenige Grad über dem Horizont und stört viel weniger.
Dein Kalender gibt den ALT-Wert ja an, allerdings immer nur für einen Tag.
Wäre es evtl. denkbar, das etwa so darzustellen ? Das würde noch deutlicher zeigen, wie störend der Mond ist.

Viele Grüße
Jürgen

 

[sphere]

Wäre es evtl. denkbar, das etwa so darzustellen ? Das würde noch deutlicher zeigen, wie störend der Mond ist.

Gute Idee, ich hab das mal als Option und Hover eingebaut:

Grüße,
Tristan

 

[_Jürgen_K]

Hallo Tristan,
toll !! Bin begeistert !
Ich meine, ein bisschen kann man die maximale Elevation ja aus der Länge des Weissen Balkens abschätzen. Aber so ist das super ! Und man hat halt echte Werte, insbesondere, wenn man halt nicht zu Hause ist, wo man halt weiss, welches die maximale Altitude ist, sondern vielleicht an einem anderen Ort.
Vielen lieben Dank !!
Ein tolles Tool !
Jürgen

PS: sehe gerade, bei mir wird der Wert aber nur angezeigt, wenn ich mit der Mouse auf den Balken gehe..... oder mache ich was falsch ?

Sorry, wer lesen kann ist deutlich vorn.
Habe das Kästchen gefunden !!! Super !

 

[sphere]

PS: sehe gerade, bei mir wird der Wert aber nur angezeigt, wenn ich mit der Mouse auf den Balken gehe..... oder mache ich was falsch ?

Sorry, wer lesen kann ist deutlich vorn.
Habe das Kästchen gefunden !!! Super !

Hehe, ja der Modus muss vorerst mit der Checkbox aktiviert werden.
In der Zukunft wird sich die App aber merken welche Checkboxen du an hast...

Ich wollte mir halt den sauberen, aufgeräumten Look bewahren...

Grüße,
Tristan

 

[h_c_greier]

Sehr gute Idee das mit der Höhe!
Bitte noch die Farbe der Schrift anpassen. Wenn der Vollmond-Baken dunkelgrau ist braucht's eine andere Farbe, und wenn er weiß ist eine dunklere Farbe.

cs,
harald

--

 

[_Jürgen_K]

Ich finde, die Veränderung der Farbe des Balkens braucht es doch gar nicht, da ja das Mondsymbol links immer angezeigt wird. Den Mondbalken würde ich dauerhaft weiss lassen, damit auch Auf- und Untergang deutlich erkennbar sind. Wenn der Balken dunkelgrau ist, finde ich das Gesamtbild eher etwas unübersichtlicher.
Oder die Farbeveränderung des Balkens auch an-/abschaltbar machen ?
Was meinen die anderen dazu ????
CS Jürgen

 

[sphere]

Ich finde, die Veränderung der Farbe des Balkens braucht es doch gar nicht, da ja das Mondsymbol links immer angezeigt wird. Den Mondbalken würde ich dauerhaft weiss lassen, damit auch Auf- und Untergang deutlich erkennbar sind. Wenn der Balken dunkelgrau ist, finde ich das Gesamtbild eher etwas unübersichtlicher.
Oder die Farbeveränderung des Balkens auch an-/abschaltbar machen ?
Was meinen die anderen dazu ????
CS Jürgen

Die Helligkeit des Mondbalkens (bei Mond >0°) Representiert die Helligkeit des Mondes und lässt damit auch Rückschlüsse zur Phase zu.
Zu der Schrift überlege ich mir was, finde das aber persönlich aktuell gar nicht so schlimm, man kann es lesen sobald es für den Zweck der App wichtig wird. Also bei 10% Mond kann man es schlecht lesen - aber da ist es auch an sich nicht so relevant. Da hatte ich mir schon was bei gedacht.

 

[h_c_greier]

Zu der Schrift überlege ich mir was, finde das aber persönlich aktuell gar nicht so schlimm, man kann es lesen sobald es für den Zweck der App wichtig wird. Also bei 10% Mond kann man es schlecht lesen - aber da ist es auch an sich nicht so relevant. Da hatte ich mir schon was bei gedacht.

Niemand bezweifelt, dass du dir dabei was gedacht hast. Ich gebe nur meinen Eindruck wieder.
Es würde reichen, bei (Hausnummer...) <40% den Text hell zu machen und darüber dunkel. Oder so

cs,
harald

--

 

[_Jürgen_K]

Die Helligkeit des Mondbalkens (bei Mond >0°) Representiert die Helligkeit des Mondes

Hi Tristan, das war mir schon klar. Aber der dazu passende Mond ist doch links abgebildet. Da sehe ich die Mondhelligkeit ja in % genau. Im Balken muss man schon schätzen. Aber gut, ich will ja nicht meckern, oder es Dir ausreden. Ich wollte nur aus meiner Sicht sagen, daß mir links der Mond mit der %-Angabe mehr gibt als der Grauwert des Balkens.
Liebe Grüße
Jürgen

 

[sphere]

Da hatte ich mir schon was bei gedacht.

Das klang scheinbar deutlich passiv aggressiver als beabsichtigt, sorry.

Es würde reichen, bei (Hausnummer...) <40% den Text hell zu machen und darüber dunkel.

Gute Idee, ich hab rum experimentiert und ich denke bei 20° wäre ein guter Punkt, was denkst du? (Ist noch nicht veröffentlich - nur erst mal ein lokaler Entwurf...

Aber gut, ich will ja nicht meckern, oder es Dir ausreden.

Alles gut, dein (bzw. euer) Feedback ist nützlich und genau weswegen ich die App veröffentlicht habe. Was denkst du über die Variante aus dem Screenshot oben wo der Text von schwarz auf weiß wechselt?

Grüße

 

[sphere]

In eigener Sache (leider ein wenig off-topic), vielleicht könnt ihr mir zu einem anderen Thema auch noch wertvolles Feedback geben:

Ich arbeite gerade an einer Schwester-App zum Moon and Darkness Calendar.

Aus meiner Sicht ist der Moon and Darkness Calendar primär für den "Zeitpunkt" zuständig, zB bei der Urlaubsplanung.
Sinn: Also im Prinzip möchte ich herausfinden, wann ich lieber in den Urlaub fahre, zB. in Kalenderwoche 45 oder 47...

Jetzt habe ich mit einer App angefangen, bei der es primär um den Ort geht. Aktuell besorge ich über Wetter-APIs die Wolkenbedeckung für jede Stunde in den letzten 365 Tagen (tatsächliche Werte, keine Vorhersagen), filtere diese auf Stunden in der Dunkelheit und erzeuge daraus Statistiken. Bis jetzt habe ich die Statistiken "Gesamt" und jeweils für die letzten 12 Monate.
Sinn: Also im Prinzip möchte ich herausfinden, wo ich denn nun in Kalenderwoche 47 hin fahre. zB. Nord-Griechenland oder Süd-Griechenland.
Mir sind andere Faktoren wie Lichtverschmutzung etc bekannt, dafür gibt es bereits gute Apps/Webseiten. Aber ich kenne tatsächlich keine Webseite die mir die Anzahl klarer Nächte in einem bestimmten Monat oder Jahr für einen bestimmten Ort in der Vergangenheit einfach mitteilt.

Hier mal ein Screenshot von meinem Prototyp:

Ein weitere Nebeneffekt: Es ist es ja auch interessant die Standorte von verschiedenen Astro-Kollegen zu vergleichen - der eine hatte vielleicht 20 wolkenfreie und dunkle Nächte verfügbar im Jahr, der andere eher 5.

Also ich plane aktuell nicht eine Wettervorhersage für die nächsten paar Tage einzubauen - stattdessen benutze ich tatsächliche Daten aus dem letzten Jahr um eine Art "Grundgefühl" für die Bedingungen an einem bestimmten Ort zu bekommen.

Kennt jemand Webseiten oder Tools die eine ähnliche Astro-spezifische Übersicht bieten? Wie macht ihr das?
Und falls ihr euch die Daten selber zusammensucht, was für Daten schaut ihr euch genau an?

Und grundsätzlich: Fändet ihr so etwas nützlich?

Grüße,
Tristan

 

[_Jürgen_K]

Was denkst du über die Variante aus dem Screenshot oben wo der Text von schwarz auf weiß wechselt?

Sieht sehr gut aus.

 

[DietSky]

ich freue mich, euch mein kleines Web-Tool, den Moon and Darkness Calendar, vorzustellen! Ich habe es ursprünglich für mich selbst entwickelt, aber es könnte auch für andere in der Astronomie-Community nützlich sein. Die Website erstellt einen Kalender für die nächsten 30 Tage, basierend auf dem Standort, den ihr eingebt. So zeigt sie Mondphasen, Dunkelheitsstufen (civil, nautical, astronomical) und Zeiträume an, in denen der Mond über dem Horizont steht – und das für jede Nacht.

Hallo Tristan,

habe ich gerade erst entdeckt. Eine ganz tolle Arbeit hast Du da geleistet! Ich werde dieses Tool ab jetzt sicher öfter für meine Beobachtungsplanung einsetzen.
Sehr übersichtlich, mit den wichtigsten Informationen auf einen Blick. Ganz große Klasse!

CS Dietmar

 

[h_c_greier]

Gute Idee, ich hab rum experimentiert und ich denke bei 20° wäre ein guter Punkt, was denkst du?

Das würde passen!

Also ich plane aktuell nicht eine Wettervorhersage für die nächsten paar Tage einzubauen - stattdessen benutze ich tatsächliche Daten aus dem letzten Jahr um eine Art "Grundgefühl" für die Bedingungen an einem bestimmten Ort zu bekommen.

Hm. Ich denke nicht, dass ein chaotisches System wie "das Wetter" mit einem "Grundgefühl" beherrschbar wird. Selbst wenn man die Daten aus der Vergangenheit genau gemessen hat. Und wenn in den letzen 5 Jahren die Sommermonate in Nord-Griechenland sch****e waren, was sagt einem das über den kommenden Sommer? Gar nix. Für die "Bedingungen an einem bestimmten Ort" gibt es ja sowas wie den vieljährigen Durchschnitt. Statistik halt.

cs,
harald

--

 

[sphere]

Sieht sehr gut aus.

Alles klar, vielen Dank. Ist jetzt live!

Hallo Tristan,

habe ich gerade erst entdeckt. Eine ganz tolle Arbeit hast Du da geleistet! Ich werde dieses Tool ab jetzt sicher öfter für meine Beobachtungsplanung einsetzen.
Sehr übersichtlich, mit den wichtigsten Informationen auf einen Blick. Ganz große Klasse!

CS Dietmar

Freut mich, Danke für das Feedback. Hast du irgendwelche Verbesserungsideen?

Das würde passen!

Alles klar, vielen Dank. Ist jetzt live!

Hm. Ich denke nicht, dass ein chaotisches System wie "das Wetter" mit einem "Grundgefühl" beherrschbar wird. Selbst wenn man die Daten aus der Vergangenheit genau gemessen hat. Und wenn in den letzen 5 Jahren die Sommermonate in Nord-Griechenland sch****e waren, was sagt einem das über den kommenden Sommer? Gar nix. Für die "Bedingungen an einem bestimmten Ort" gibt es ja sowas wie den vieljährigen Durchschnitt. Statistik halt.

Das Wetter ist sicherlich nicht beherrschbar, und vorhersagen lässt es sich mit der Vergangenheit (alleine) auch nicht - das ist klar.
Aber ich glaube schon, dass es hilfreich sein kann zu wissen wie häufig klare Nächte an einem bestimmten Ort in der Vergangenheit vorgekommen sind.
Es gibt es halt Orte von denen wissen manche, dass sie (häufiger) "gut" oder (häufiger) "schlecht" sind. Das kann man schon quantifizieren.
zB Namibia > La Palma > Toskana > England als Beispiel (Danke @_Jürgen_K). Ich wüsste jetzt auf Anhieb nicht wo ich die Eifel, Südfrankreich oder Südschweden dort einsortieren müsste - da kann eine Datenbasis aus ein oder zwei Jahren schon helfen.

Edit: Ein Beispiel wäre wenn ich unbedingt einen Strandurlaub plane und zwei Orte zur Auswahl habe die mir ansonsten gleich gut gefallen, würde ich den Ort nehmen, der laut Statistik die höhere Anzahl an Sonnenstunden in dem Monat hat. Eine Garantie ist das natürlich nicht - aber ein verbessern der Chancen. Mein Punk ist, es gibt "Sonnenstunden pro Monat" auf jeder Wetterseite. Es gibt (noch) auf keiner Seite "Klare Nachtstunden pro Monat".

Aber klar, Mond- und Sonnenzeiten sind errechenbar, die Lichtverschmutzung ist einigermaßen genau Kartiert - das Wetter lässt sich nicht genau vorhersagen. Deswegen nehme ich die Daten auch nicht in den Kalender auf sondern baue eine separate App.

Grüße,
Tristan

 

[DietSky]

Freut mich, Danke für das Feedback. Hast du irgendwelche Verbesserungsideen?

Hallo Tristan,

wenn Du so fragst, dann hätte ich noch einen Wunsch:

Als Beobachter oder Astrofotograf hat man ja normalerweise ein betimmtes Objekt aktuell in der Planung. Wäre es möglich, eine Eingabemöglichkeit für dieses Wunschobjekt vorzusehen (z.B. NGC-Bezeichnung) und in der Grafik für jeden Tag/Nacht den Meridiandurchgang für dieses Objekt zu markieren. So könnte man sehr schnell den optimalen Zeitraum für die Beobachtung einsehen.
Wäre aus meiner Sicht eine sehr hilfreiche Erweiterung.

CS Dietmar

 

[sphere]

Hallo Tristan,

wenn Du so fragst, dann hätte ich noch einen Wunsch:

Als Beobachter oder Astrofotograf hat man ja normalerweise ein betimmtes Objekt aktuell in der Planung. Wäre es möglich, eine Eingabemöglichkeit für dieses Wunschobjekt vorzusehen (z.B. NGC-Bezeichnung) und in der Grafik für jeden Tag/Nacht den Meridiandurchgang für dieses Objekt zu markieren. So könnte man sehr schnell den optimalen Zeitraum für die Beobachtung einsehen.
Wäre aus meiner Sicht eine sehr hilfreiche Erweiterung.

CS Dietmar

Interessante Idee, Danke! Ich hab es mal auf die Liste gesetzt, kann aber noch nichts versprechen.