DSO-Liste erstellen mit Excel, Access oder HTML5

Status
Es sind keine weiteren Antworten möglich.
Via_Lactea

Via_Lactea

Aktives Mitglied
Hallo allerseits

Ich möchte gerne eine DSO-Liste, der von mir bereits fotografierten Objekte erstellen. Dazu würde ich gerne eine Excel- oder Access-DB erstellen oder in HTML5 (bin noch am Recherchieren nach dem WIE und WAS bzw. welche Parameter und mit welcher Maschinensprache dies sinnvoll ist).

.....bevor ich das Rad neu erfinde, wollte ich euch fragen, wie Ihr eure DSO-Katalog, Kompendium, Konvolut oder Liste führen, und oder habt Ihr eine Vorlage über Excel, Access oder betreibt Ihr es über ein Kaufprogramm.
Bisher studiere ich über eine Formularbühne die z.B. über Access abgewickelt werden könnte und füge die verschiedenen Parameter "Texte & Bilddatei" hinzu, die Parameter belaufen sich auf die Daten von: Magnitude, Entfernung in Lj. oder in AE, Katalog-Nr. [NGC/M/IC/SH2 etc.], physikalische Daten, Positionsdaten, Zenit-Datum dazu noch ein kleiner Textauszug des Objektes, sowie die Merkmale der Bildaufnahme [Datum, Brennweite, Teleskope, Kamera, Filter, Gain, Mosaik etc.

Da hier eine grosse Arbeit vor mir liegt, frage ich euch mal, wie Ihr das so handhabt, vielleicht hat ja jemand von euch schon eine Vorlage, die ich eventuell erhalten könnte oder andere Hinweise, auf die man achten sollte.

PS: auch schwebt mir ein Gedanke das ich dies in HTLM über SQL tätige, so habe ich es online und kann es noch RWD (Responsive) tauglich machen für Mobilgeräte und oder für APK und als APP Implementieren.

…stehe voll in der Entwicklungsfasse und hoffe auf die einen Ideen – die DSO-Liste ist für den Privaten gebrauch gedacht und wenn mal die v1.x ausgerollt wird stelle ich dies gerne für euch bereit.

CS john
 
Hi John,

du bist mit der Idee sicher nicht der Erste. ;)
Ich würde mir nie die Arbeit machen die Standard Daten von DSOs manuell einzugeben. Die sind auf vielfältigste Art schon überall katalogisiert.
Wenn überhaupt würde ich nur eine Liste mit den reinen "privaten" Daten machen und diese dann über die Objekt ID mit einem passenden Katalog verbinden.

ZB könnte man die Objekte dieser Liste dann einfach auf einen Online-Katalog verlinken.
Man kann auch den Katalog von Stellarium lokal per HTTP abfragen. Der Vorteil hier ist, dass man die Daten gleich als JSON bekommt und sie damit sehr gut verarbeiten kann.

Dann gibt es noch freie SW, wo man Beobachtungslisten erstellen kann. ZB Eye&Telescope und Stellarium.

Gruß
Peter
 
Hallo John,

vielleicht ist ja das Sheet das ich zur Verfügung stelle etwas für dich?

Google Sheet zur Beobachtungsdokumentation

Hallo liebe Astrokollegen, ich habe ein Google Sheet erstellt, um meine astronomischen Beobachtungen zu dokumentieren und auswerten zu können. Das Sheet stelle ich hier zur Verfügung, damit vielleicht auch andere Astroanfänger einen Startpunkt haben. Habe für den Katalog, die Instrumente, den...
forum.astronomie.de forum.astronomie.de

Freue mich immer über Feedback und weitere Ideen :)

Ich habe lange überlegt, ob ich was programmieren sollte, bin aber dann dabei geblieben das Zeug über Google Sheets abzubilden.

Liebe Grüße
Philipp
 
Zuletzt bearbeitet:
Vielen Dank für die Rückmeldung und eure Tipps,

@gateway "Philipp" der Link bzw. die Exceldatei ist auf deinem Drive gelöscht – also ich kriege diese Meldung hier.
googli.jpg




@AstroPZ "Peter" Ja; Du hast schon recht es gibt viele Katalogen im Deep-Web, aber mein Begehren liegt das ich meine eigene Aufnahmedaten Dokumentieren möchte, um die bestehenden .FITS-Daten möglichst einfach ergänzen zu können. [die DB muss eben eine Suchfunktion enthalten, um alle Eigenschaften und Parameter auszuspucken, die ich anfordere].

Der Grund:
Meine besten Bilder sind Ergebnisse die aus mehreren Jahren entstanden sind und möchte diese fortlaufend ergänzen um die Gesamtbelichtungszeiten zu erhöhen – so entstand die Idee alle meine Eigenschaften von .FITS daten zu dokumentieren dazu lege ich noch meine Eigene Bilder dazu.

Meine BD wächst und wächst jedes Jahr um einige TB an (wobei seit Okt. 2022 bis heute eine dichte Nebelwolken-Suppe habe).
Die bestehende .FITS-Daten haben unterschiedlichen Brennweite, Filter, Belichtungszeit etc. dazu kommt noch verschiedene Mosaiken aufnahmen bis zu 12 Feldern – da verliere ich den Durchblick.
Wenn ich meine nächste Session plane und möchte, wissen welche Datensätze ich schon gemacht habe oder welche Daten noch fehlen "z.B. über Filter, Gain-Wert etc." Klicke ich mich tief im Keller durch über dem Explorer-Verzeichnisen. Daher meine Idee dies allesamt zu dokumentieren, um auf eine angemessene Gesamt-Belichtungszeit zu kommen. Da ich auch noch unter Bortle 6+ fotografiere und viel Ausschuss produziere, und zusätzlich nur ein kurzes Zeitfenster habe (Lichtquellen- Hello City, Baukran, Fassade etc. ist dies eine Lösung für mich, denn ich tätige mehrere Objekte Aufnahmen in der gleichen Nacht auf mehrere tagen, Monaten und Jahre. Daher eine Doku für meine alt Daten Sätze.

…das mit dem .json DB ist ein Anreiz für mich, aber es sind nicht meine eigene Daten – über Excel hab ich Zweifel bekommen (wegen den Bilddatensätze Excel bleibt einfach nur ein rein Textbasierendes Tool. Für Bild und Ansicht Parameter ist es nicht gemacht) da bleibt mir nur noch Access oder eben doch alles via HTML5 aufzuziehen.

Danke an euch für das lesen und für zukünftige Tipps....

CS john
 
Hi, was haben deine FITS denn für Metadaten? Ich habe mir selbst ein Tool gebaut welches alle Metadaten des FITS nach z.B. Excel übernehmen kann.
Ich würde den FITS möglichst viele Metadaten verpassen damit sie für sich selbst sprechen können.
Soll ich dich unterstützen? Das Tool heißt FITSGrep und nutzt z.B. Everything zur schnellen Suche nach relevanten Dateien. Viele Grüße Martin.
 
Ave Martin

Mein Glück….mein Sequenzer ist NINA und hier habe ich alle relevante Metadaten aufgenommen, die dann in die Bilddatei bzw. im .FITS header geschrieben werden – wobei diese Dateivorlage nur in meinen Datensätzen ab Frühjahr 2022 enthalten sind.

Diesen Gedanken habe ich auch gefast (kenne das von der Exif-Ansicht, die man in eine CSV importieren kann [auch gibt es einige Programme, die die Sortierung über das .Exif für die Bildkataloge etc. vornehmen]), und PixInsight bietet das Format .Xisf (Erweiterbares Format zur Bildserialisierung) an - ob man diese Metadaten so einfach über einen Batch importieren kann, habe ich bisher nicht getestet.
Wobei (wie oben erwähnt) NINA bei mir so konfiguriert ist, dass alles schön gebündelt ist [Pfad > ImageTyp > Fiter > etc.], so dass ich nach einer Aufnahmesession das erstellte Verzeichnis und die Typen bequem auf meinen Fileserver in die bestehende Verzeichnisstruktur übertragen kann.

Dies ist ein kleiner Einblick in mein Dateisystem, dieses ist noch nach Aufzeichnungsdatum aufgeteilt. Ich würde diese Informationen gerne in ein Access übertragen oder über HTML5 implementieren (d.h. ich muss nicht alle .FITS-Daten auslesen können - nur die Informationen, die in einer Sitzung anfallen und das könnte über ein Eingabeformular geschehen).
Verzeichnis_001.jpg



Ich stelle mir das so vor! Das soll mit statischen und Dropdown-Feldern funktionieren und für die Bilddatei soll ein Link im Skript sein, der dann im Suchformular mit Popup- oder Mousover-Funktion aufgerufen wird. Das klingt einfach und gibt auch keine immense Arbeit.

CS john
 
Hi,

meine Gedanken:

Wenn es um eine Dokumentation/Daten geht, die einzeln stark mit den Bilddateien verknüpft ist, bzw. eigentlich da dazu gehört, dann gehört diese Information, aber auch nur diese, in die Bilddateien. Dazu hat eben FITS die Möglichkeit beliebige Tags zu definieren und anzuhängen und das würde ich dann dafür benutzen.
Gleichzeitig kann man dann noch ein Verwaltungs/Auswerteprogramm dazu schreiben oder ein vorhandenes nutzen, das die Daten aus den FITS subsumiert und darstellt.

Allerdings wird es schnell auch hierarchisch. Die Daten der Aufnahme Session gehören nicht in die einzelnen Bilddateien. Die Session ist ein eigenes Objekt/Entität. Wo speichert man das ab? Oder auch das Aufnahme Setup. Also braucht man eine DB in der alle Objekte/Entitäten angelegt und verknüpft sind.

Wenn "echte" DB, was eine gute Sache aber aufwendig ist, dann auch wirklich eine DB nehmen und nicht so etwas wie Excel.
Ich komme aus dem Bereich der SQL-DBs und finde das natürlich gut und für mich wäre das sofort die Wahl (zB das Open Source PostgreSQL).

Gruß
Peter
 
Gerade was den Austausch bzw. die Kompatibilität der Beobachtungsdaten zwischen verschiedenen Anwendungen betrifft bin ich immer wieder erstaunt, dass man sich da nicht auf einen Standard einigen kann. Oder wenigstens auf einen Quasi-Standard. Da kocht jeder wie immer sein eigenes Süppchen.. Aber ist das nicht überall so? Einheitliche Stecker für Handy, ....bla
Ich würde da HTML mit JSON nehmen, einfach zu handhaben und zu implementieren.

Bin ja nicht sooo der praktische Beobachter. Welche Art von Daten kommen da so zusammen und welcher Art sind diese?

cs,
harald

--
 
… eigentlich passt alles in den FITS-Header, und den liest mein Tool aus und packt ihn irgendwohin - ich jetzt in eine File-Basierte Datenbank, LiteDB.
Dann kannst du in alles mögliche exportieren
 
@AstroPZ "Peter" Danke für deinen Tipp,
die PostgreSQL (das Handbuch mit 2892 Seiten) musste ich kurz überfliegen, auch gibt es eine Menge Pakete, aber nicht alle sind unter Freeware. Ich habe fünf ausgewählt [PG-Amin, PG-loader, PG-Collector, NextTypesSQL , ImageViever], um ein besseres Verständnis zu bekommen.

@h_c_greier "Harald"
der Standard ist bei mir .FITS, obwohl ich das .Xisf über NINA nehmen könnte, aber .FITS-Dateien sind (wie ich es kenne seit ~1980 unterwegs) und stehen im Bereich der Astronomie ganz vorne, dieses Format hat ja die NASA entwickelt. Zu deiner Frage welche Daten hier zusammenkommen und in welcher Art diese sind.
  1. Datentyp: Lights, Dark, Flats, Darkflats und die Eigene Bilddatei.
  2. Die relevanten Aufnahmeinformationen (von Punkt 1.), z. B. Gain, Offset Gain, Belichtungszeit, Temperatur, Bildwinkel, Kamera- und Teleskopsystem....; alles, was beim Stacken übereinstimmen sollte. Die infos befinden sich im .FITS-Header, sofern man die Parameter im Sequenzer gesetzt hat.
Hier ein Beispiel:
$$TARGETNAME$$\$IMAGETYPE$$\$FILTER$$$__$$$TARGETNAME$$__$$$FRAMENR$___$$$TELESCOPE$$$_$$$HFR$$__$$$EXPOSURETIME$$__$$$$SENSORTEMP$$$$$$ROTATORANGLE$$$$$$$DATETIME$$$$$$TELESCOPE$$
​
@albusmw und welches ist dein Tool, ich lese mich gerade ein wie ich .FITS-Header auslese resp. Exportieren kann über ein Script. Bei PI über Image Inspection > Blink; hier kann ich nur eine Datei Auslesen und in ein Text-File senden.

CS john
 
Mein Tool ist .NET / C# / VB, weil ich seit 35 Jahren programmiere - damit kann man alles machen, ist halt nicht für jedermann der mögliche Weg
 
Hi,

PostgeSQL ist natürlich ein vollwertiges, klassisches RDBMS und damit schwerer zu handhaben (wenn man sich nicht auskennt ;) ).
Ich komme ja auch aus der Java Welt. Für Java gibt es noch schöne einfache DBs, wie zB H2 DB oder HSQLDB. Die gibt es auch eingebettet, also man braucht nur ein JAR zur Applikation dazubinden.

Gruß
Peter
 
Ich nehme immer die - für solche Anwendungen völlig ausreichend und very easy to use
www.litedb.org

LiteDB :: A .NET embedded NoSQL database

LiteDB : LiteDB - A .NET NoSQL Document Store database in a single data file.
www.litedb.org www.litedb.org
 
…. Ich programmier halt seit 30 Jahren Basic …
 
Zitat von albusmw:
…. Ich programmier halt seit 30 Jahren Basic …
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
echt jetzt?
Wolltest nicht mal nach C# umsteigen?

Eine andere Welt ist natürlich Java.
Ich kenne praktisch alle anderen Programmiersprachen (alles auch aus der Praxis, zB auch Delphi wer kennt das noch? ;) ) und bin der Meinung, dass man mit Java am schnellsten eine einigermassen objekt orientierte Applikation mit GUI erstellen kann. Allerdings ist wie immer schon auch eine Einstiegshürde da.
Und Java hat halt die ganzen Test Frameworks (man denkt man braucht das nicht ;) ) mit dabei und über Eclipse auch sehr schön integriert.

Gruß
Peter
 
Ich programmier halt immer „nur“ auf Windows, und ob man .NET mit C# oder VB produziert macht auch keinen großen Unterschied, objektorientiert geht auch super mit VB, man muß es nur machen …..
 
.....langsam, aber sicher wird was mit meiner DSO-Liste, die Formulareingabemaske funktioniert und speichert die Werte brav in der vorgesehenen Applikation-DB.

DSO-DB_by-joim_2023_Beta.jpg


Die Parameter sind noch nicht endgültig gesetzt "Beta-Version", kommt immer wieder was neues dazu. Auch die Filterlösung ist noch in der Entwicklung Status. Die Kalibrierungs-DB ist provisorisch verlinkt und zeigt eine Auflistung der Inhalte, sowie alle Dateninhalte aus dem Ordnerpfad.

Hier ist ein Beispiel:
DSO-DB_Filter-Link.jpg


ob ich dies als Desktop-DB beibehalte oder doch zu einer serverseitigen DB wechseln möchte ist noch nix Entschieden.

CS john

PS: ab Donnerstag ±lössen sich endlich die Wolkensuppen auf :y: Wenn nicht lerne ich Rails & Phyton :eek:
 
Status
Es sind keine weiteren Antworten möglich.
Zurück
Oben