Automatische Berichtgenerierung für v. Beobachtung

Status
Es sind keine weiteren Antworten möglich.
Robert Zebahl

Robert Zebahl

Aktives Mitglied
Hallo zusammen,

seit September 2011 bin ich stolzer Besitzer eines 8 Zoll Dobson (neben meinem kleinen 4.5 Zoll f/7.9 Newton) und beschäftige mich seitdem recht intensiv mit der visuellen Beobachtung. Aufgrund der Vielzahl von beobachtbaren Objekten ist es natürlich sinnvoll, einen Bericht über das, was beobachtet wurde, zu verfassen. Die Frage ist nun: Wie soll so ein Bericht aussehen? Da ich selbst mehr oder weniger viel mit Latex als Textsatzsystem (ähnlich wie MS Word oder OpenOffice, nur deutlich bessere Ausgabe) arbeite, war für mich die Entscheidung klar: Der Bericht soll in Latex verfasst werden um daraus ein PDF inkl. Inhaltsverzeichnis (mit internen Links zur besseren Navigation) zu generieren.

Welche grundsätzlichen Informationen sollten in diesem Bericht enthalten sein? Hierfür hat mich die DeepSky-Liste (http://deepsky.fg-vds.de/deepskyliste) aufgrund ihrer kompakten Form (insbesondere die Skalen für die Sichtbarkeit von Objekten) inspiriert, sodass ich deren Legende fast vollständig übernommen habe. Neben diesen recht knappen Informationen gebe ich zusätzlich noch die konkret verwendeten Primäroptiken (z.B. Teleskope) und Okulare an. Zusätzlich können noch textuelle Beschreibungen hinzugefügt werden. Zeichnungen sind in diesem Bericht vorerst nicht vorgesehen, könnten aber prinzipiell ergänzt werden. Hier mal mein derzeitiger Bericht: Bericht.pdf
Natürlich fehlen noch ein paar erklärende Worte, aber sowas kann schnell ergänzt werden.

Was macht diesen Bericht nun eigentlich (aus meiner Sicht) so besonders? Das Textdokument wird (zum Glück) nicht mehr von Hand geschrieben, sondern vollautomatisch generiert. Grundlage hierfür bieten komplexe Datenstrukturen, welche in Perl (Skript-/Programmiersprache) umgesetzt sind. Auf aufwendige grafische Eingabemöglichkeiten der Daten habe ich (aus Zeitgründen) verzichtet. Stattdessen werden die Daten direkt in Perl über geeignete Funktionen eingegeben. Um die Art der Daten möglichst flexibel zu gestalten, habe ich mich vollständig auf die Verwendung von Hash-Tabellen zurückgezogen. So können z.B. Eigenschaften zu einem Objekt oder ergänzende Informationen zu Beobachtungen schnell hinzugefügt werden. Auf Basis dieser Datenstruktur bin ich nun in der Lage, verschiedenste Funktionen auf diesen Daten umzusetzen, welche mir nach Belieben die Informationen extrahieren, welche mich interessieren und diese in einem geeigneten Format ausgeben. In diesem konkreten Fall lasse ich mir nahezu alle Tabellen, die in dem PDF zu sehen sind, automatisch generieren. So werden z.B. auch die Werte in der Tabelle für Okular-Teleskop-Kombinationen (analog zum Okularrechner) berechnet. Um dieses Vorgehen etwas besser zu motivieren, hier mal ein paar meiner Gedanken dazu:

Ein klassischer Bericht könnte ein Dokument sein, welches neben Datum, Ort und Bedingungen (Fst, Seeing, ...) auch die einzelnen Objekte enthält. Natürlich werden einige Objekte immer wieder beobachtet und auch die verwendeten Instrumente sind nicht immer gleich.
Folgende Fragen haben mich dann interessiert:
* Welche Galaxien, Nebel, ... habe ich denn überhaupt schon gesehen/nicht gesehen
* Welche Beobachtungen wurden für ein konkretes Objekt gemacht?
* Welche Objekte konnte ich in einem Sternbild gut beobachten? (Weil z.B. das Sternbild gerade besonders günstig steht)
* ...

Man könnte sich hier die verschiedensten Fragen überlegen (bis hin zu Statistiken), um einen geeigneten Überblick zu bekommen. Da bei ausreichender Anzahl von Berichten sowas keinen Spaß mehr macht, habe ich mich für die Trennung der Daten und deren Darstellung entschieden. Die Daten werden in Perl abgelegt und mittels Funktionen (ebenfalls in Perl) in ein geeignetes Datenformat transformiert. So könnten z.B. auch automatisch HTML-Seiten generiert werden. In meinem Fall generiere ich Latex-Dateien (im Grunde auch nur reine Textdateien), welche dann mit einem Latex-Compiler übersetzt werden, um dieses PDF zu erhalten.

Sicher gibt es auch mehr oder weniger brauchbare Software, aber: Hier hat der Anwender (sofern er über Programmierkenntisse verfügt oder diese erlernen möchte) die volle Kontrolle über die Datenhaltung und deren Darstellung (theoretisch können auch grafische Oberflächen zur Eingabe/Visualisierung der Daten erstellt werden) und es kostet zumindest kein Geld.

Falls sich jemand einen besseren (tieferen) Einblick verschaffen möchte:
Komplettes Projekt.rar
Hinweis: Ich habe mich nicht um Effizienz des Codes oder Ähnliches gekümmert. Es soll einfach funktioneren ;) Ebenso die Darstellung der Daten kann sicher optimiert werden, wobei ich für meinen Teil zufrieden damit bin.

Jetzt mach ich aber erstmal Schluss und bin gespannt auf Kommentare und Fragen.

Viele Grüße und vor allem CS, Robert :)
 
Kleine Ergänzungen:

Ich bin gerade zufällig über den "Observation Manager" hier gestolpert, der quasi das Ganze grafisch löst und einen guten Eindruck hinterlässt.

Da ich selbst ein Minimalist bin (arbeite viel auf der Kommandozeile), ausschließlich unter Linux arbeite und viel in Perl und Latex mache, kam für mich derartige Lösungen nicht in Frage. Anwenderfreundlich ist meine "Lösung" natürlich keineswegs ?) Allerdings wollte ich als Ausgabe ein portables Format (hier PDF) haben, welches weitergegeben werden kann und auch druckbar ist. Die Bindung an ein konkretes Programm zur Eingabe und Darstellung der Daten ist (zumindest in meinem Fall) nicht immer vorteilhaft.


CS, Robert
 
Hallo Robert,

Deine Bemühungen in allen Ehren, aber irgendwie habe ich das Gefühl, dass Du da aufgrund Deines Studiums Dich auf Sachen versteifst, die für einen wahren Beobachter nicht wirklich interessant sind.

Zusätzlich können noch textuelle Beschreibungen hinzugefügt werden.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Müssen!!

Das ist das überwiegend Interessante an Beobachtungsberichten. Zahlen und Daten sind nur sekundär und dienen der Unterstützung der visuellen Eindrücke bzw. zum Verdeutlichen der Sichtbarkeit anhand der Beobachtungsbedingungen (Grenzgröße des Objekts und HImmelsqualität)- nicht umgekehrt!

Schöne Grüße,
Norman
 
Servus.

Für einen Beobachtungsbericht wäre mir der Aufwand, den du hier betreibst zu viel.
Ich schreibe meine mit Publisher, drucke die aus und sammle die in einer Mappe.
Um nachzusehen, wo welches Objekt steht, habe ich mir eine kleine Access Tabelle gemacht.

Der Ordner ist schnell aus dem Regal gezogen, und man kann einiges Revue passieren lassen. Auf einem Treffen oder am Stammtisch sind gedruckte - einfach gehaltene Beobachtungsbücher immer wieder etwas, was sich viele Leute gerne anschauen.

Viele Grüße
*entfernt*
 
Hallo Norman,

Zitat von Norman:
Zusätzlich können noch textuelle Beschreibungen hinzugefügt werden.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Müssen!!
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

ich denke, dass es jedem Beobachter selbst überlassen werden darf, welche Informationen er für sinnvoll hält oder nicht. Den von mir verfassten Bericht verwende ausschließlich ich. Das dahinterliegende Programm (besser Tool) ist hier der Kern der Sache, nicht der Inhalt des Berichts ;) Außerdem habe ich mit dieser Aussage einen Unterschied zur DeepSky-Liste hervorheben wollen, da diese keine weiteren Beschreibungen zulässt!

Gruss, Robert
 
Zuletzt von einem Moderator bearbeitet:
Hallo Gerd,

so sind halt die Geschmäcker verschieden. Würde ich es so machen wie du, müsste ich mir 2 mehr oder weniger große (für diesen einen Zwecks völlig überdimensionierte) Programme installieren/beschaffen/kaufen. Ich ziehe mich hier gezielt auf (zumindest unter Linux) Standardtools zurück, welche mit einfachsten Mitteln (ich nutze ausschließlich reine Texteditoren mit sehr umfangreichen Funktionen auf der Konsole) zu bedienen sind. Grafische Programme sind jedenfalls für diesen Zwecks aus meiner Sicht nicht zwingend erforderlich. Die Eingabe der Daten geht jedenfalls sehr schnell (schneller als mit grafischer Oberfläche!) ;)

Vermutlich ist hier das Problem, dass hier ein minimalistischer Linux-User mit Programmierkenntnissen auf viele Windows-User stösst, welche nicht programmieren können/möchten.

Der Ordner ist schnell aus dem Regal gezogen, und man kann einiges Revue passieren lassen. Auf einem Treffen oder am Stammtisch sind gedruckte - einfach gehaltene Beobachtungsbücher immer wieder etwas, was sich viele Leute gerne anschauen.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Nunja... Genau sowas kann ich allerdings auch tun. Meinen Bericht auf das Nötigste zu reduzieren ist eine kleine Sache ;) Der Inhalt kann mit wenigen Handgriffen beliebig in der Anordnung und dem Umfang umstrukturiert werden.

Vielleicht nochmal ganz kurz: Der hier erstellte Bericht ist eine von mir gewünschte Darstellung der Daten. Die Daten können jedoch in nahezu jeder gewünschten Art präsentiert werden. Das ist jedem selbst überlassen.

Gruss, Robert
 
Zuletzt von einem Moderator bearbeitet:
Hallo zusammen,

noch einmal kurz der Punkt, welcher mich zu diesem Tool motiviert hat:

Ich versuche, möglichst viele Beobachtungsabende zu genießen und diese auch (nach meinen Vorstellungen!) zu protokollieren. Da ich jedoch kein Freund von Papier im Schrank bin (ökologisch auch besser ;) ), möchte ich diese Ergebnisse in geeigneter Form digitalisieren und darstellen. Allerdings habe ich festgestellt, dass es (zumindest für mich) schwierig sein kann, eine geeignete Darstellungsform der Daten zu finden, die einen über lange Zeit zufriedenstellt. Also habe ich mir Gedanken darüber gemacht, wie ich die Daten von der Darstellung trenne. Somit kann ich jetzt all meine Beobachtungsergebnisse eingeben, um mir (wenn Zeit ist) eine geeignete Darstellung (hier mal eine tabellarische Variante über Latex) zu überlegen.

Warum verwende ich keine klassischen Programme? Die Daten in diesem Fall sind an kein konkretes Programm (außer an Perl als Sprache) gebunden. Ein Transformieren der Daten in andere Strukturen ist leichter möglich (kleines Beispiel: Latex-Dokumente sind reine Text-Dokumente, die quasi immer lesbar sind. Im Fall von MS-Word-Dokumenten muss man kompatibilität beachten, falls sich Versionen ändern). Ich umgehe hier also Abhängigkeiten von (meist kommerziellen) Programmen (die ich ohnehin nicht besitze). Ein Texteditor ist für solche Dinge oft ausreichend (und meist auch schneller).

In Bezug auf den Aufwand, der hier angesprochen wurde: Der Aufwand ist geringer, als es aussieht ;)

Gruss, Robert
 
Hi Robert,

Original geschrieben von: Norman

Antwort auf:
Zusätzlich können noch textuelle Beschreibungen hinzugefügt werden.


Müssen!!


ich denke, dass es jedem Beobachter selbst überlassen werden darf, welche Informationen er für sinnvoll hält oder nicht. Den von mir verfassten Bericht verwende ausschließlich ich.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Natürlich ist es jedem selbst überlassen, was er in einen Bericht reinschreibt. Aber ein Bericht kommt definitionsgemäß von berichten. Dies kann nur mit Worten geschehen. Allein deshalb "muss" in einen Bericht auch richtiger Text rein. Ansonsten ist das nur eine Liste, aber keinesfalls ein Bericht. Nun kann man sich über die Schwelle streiten, was ist wann ein Bericht. Aber wenigstens vorab definierte Kürzel, um das Objekt zu beschreiben, sind ein Muss in einem Bericht. Darum kommst Du nicht herum. Und selbst mit Kürzeln wäre es eher eine Liste. Wie der NGC 2000 mit Kürzeln von Dreyer "f" für faint "s" für small usw.

Und um es nochmal zu verdeutlichen, so ein Zahlengewusel ohne Text - ohne Dir als Informatiker nahetreten zu wollen - ist nicht ergiebiger als jeder bereits vorhandene Objektekatalog und des Begriffes BeobachtungsBERICHT nicht wert.

Schöne Grüße,
Norman


 
Zuletzt bearbeitet:
Hallo Werner,

danke für deine tröstenden Worte :)

Das Prinzip meines Tools ist eigentlich sehr einfach: Ich fülle einfach mehrere Hash-Tabellen. Um mir hier die Arbeit zu erleichtern, gibt es halt noch viele Hilfsfunktionen drumherum. Die Eingabe der Daten ist im Grunde nichts anderes, als eine Perl-Datei zu schreiben, wobei hier nur noch Funktionen aufgerufen werden. Sind die Hash-Tabellen einmal aufgebaut, lege ich einfach eine Funktion darüber, welche mit den Inhalten irgendetwas macht. Hier konkret wird (wenn auch etwas absurd wirkend) Latex-Code in Dateien geschrieben, welche dann von einem "Master-Tex-File" inkludiert und übersetzt werden.

Um auf deinen Vorschlag zu "Observation Manager" zu kommen: Ich habe selbst mir das Programm mal kurz angeschaut und auch festgestellt, dass es alles in einer XML-Datei speichert. Unter Perl (habs noch nicht ausprobiert) gibt es ein Modul, mit welchem sich XML-Dateien einlesen und direkt in Hash-Tabellen speichern lassen. Hier hätte man u.U. keine Arbeit. Aber auf Basis der Datenstruktur (die ja der Observation Manager vorgibt), könnten dann Funktionen aufsetzen, die die für dich relevanten Daten in Latex umsetzen. Allerdings müssten die dann geschrieben werden.

Zum groben Aufbau (zwecks Front-/Backend und Co.): Es gibt eine Datenstruktur, welche einem Schema folgt, aber in ihren Details erweiterbar ist (sowas kann bei einer grafischen Oberfläche sehr unangenehme Effekte haben!). Die Funktionen, welche hier z.B. Latex-Code generieren, müssen natürlich diese Datenstruktur kennen. Dies würde ich als Back-End bezeichnen. Das was rauskommt (Tex-File/PDF) sehe ich hier als Frontend. Einen generischen Ansatz würde ich hier nicht unbedingt wählen, da mir dann der Aufwand zu groß wäre. Zumal die Art der Daten sehr verschieden sein können. Würde man sich auf konkrete Eigenschaften und deren Definition einzelner Objekte (Objekte sollen hier Teleskope, Okulare, astronom. Objekte, Berichte, etc. beschreiben) einigen, könnte man noch eher einen generischen und damit universelleren Ansatz wählen. Doch genau dieses "auf Eigenschaften einigen" möchte ich vermeiden, um flexibel zu bleiben.

Gruss, Robert
 
Zuletzt von einem Moderator bearbeitet:
Hallo Normal,

ich bin jetzt etwas verwirrt ?)

Ich hatte ja schon geschrieben, dass erklärende Worte in diesem Bericht (ich weiß ja, was damit gemeint ist ;) ) z.T. fehlen. Zudem gibt es in diesem konkreten Bericht auch eine nicht ganz knappe Legende, wo die einzelnen Kürzel beschrieben sind. Aber nochmal: Es geht hier nicht um inhaltliche, sondern eher technische Aspekte. Wenn sich jemand an den Symbolen oder der Darstellung (genau die kann ja angepasst werden!!!) stört, kann er das ja ändern. Es kann auch nur Text zu den Beobachtungen geschrieben werden. Meinem Tool ist es eigentlich egal, wieviel Wörter ich über ein Objekt verliere ;)

Gruss, Robert
 
Zuletzt von einem Moderator bearbeitet:
Hallo zusammen,

der Autor/Programmierer von "Observation Manager" möge ich mich korrigieren, falls ich etwas daneben liegen sollte.

Im Grunde arbeiten der Observation Manager und mein Tool ähnlich. Der Observation Manager nimmt über grafische Eingabemasken (die statisch sind) Daten entgegen und speichert diese in einer XML-Datei. Die Daten selbst werden ebenfalls über diese graf. Oberfläche dargestellt und gegebenfalls in andere vordefinierte Formate konvertiert. Ich dagegen pflege eine Hash-Tabelle (fast) direkt und überlege mir selbst (nach meinen Vorstellungen und Wünschen) die Funktionen zur Konvertierung der Daten in andere Formate (z.B. Latex). Das Interessante dabei ist: Eine XML-Datei ist im Grunde auch nur eine Hash-Tabelle, bestehend aus Key-Value-Paaren. Zwar fehlt mir der optische Komfort, aber das Hinzufügen von Details (z.B. objektspez. Eigenschaften) geht einfacher. Bei einer graf. Oberfläche ist da in der Regel mehr zu tun.

CS, Robert
 
Hallo zusammen,

nach einigen wenigen kritischen Anmerkungen möchte ich an dieser Stelle noch etwas zur "Zielgruppe" dieses Tools und zu mir selbst sagen.

Ich bin Informatiker und habe mir im Laufe der letzten Jahre so manche Scripte/Programme geschrieben, welche mir gezielt Aufgaben (die meist in stupide, zeitaufwändige Arbeit ausarten) abnehmen sollen. Da sich die Anforderungen an solche Programme im Laufe der Zeit ändern (können), werden diese Programme meist sehr minimalistisch gehalten und nur auf das nötigste beschränkt. Dies hat meist zur Folge, dass auf "komfortable" Ein-/Ausgabe verzichtet wird. Wer sich unter Linux auskennt und viel auf der Shell arbeitet, kennt dies sicherlich. Speziell bei diesem Bericht wäre folgendes Problem, wenn man den händisch schreiben würde: Die Eingabe von nur einer Beobachtung erfodert die Änderung des Berichts an sehr vielen Stellen. Genau diese Arbeit nimmt mir das Tool ab. Ich muss mich letztlich nur noch auf die Eingabe der eigentlichen Daten konzentrieren.

Für wen könnte sowas nun interessant sein? Prinzipiell jeder, welcher über Programmierkenntnisse verfügt, auf grafische Oberflächen verzichten kann und eine funktionale Möglichkeit sucht, sich die Daten in geeigneter Form darzustellen. Man könnte theoretisch all diese Daten auch in einer Datenbank ablegen. Auch hier müsste man etwas tun, um gezielt an die Informationen zu kommen. Im Gegensatz zu Observation Manager habe ich das Tool nicht für die breite Masse geschrieben, sondern vorrangig für mich. Dennoch möchte ich das hier Entstandene mit anderen teilen, falls jemand genau sowas sucht oder dies als Inspiration für weitere Projekte betrachtet. Latex kennt z.B. nicht jeder, aber es leistet im Erstellen von Dokumenten außerordentlich viel. Möglicherweise findet jemand Gefallen daran.

Mir ist bewusst, dass ich nichts neu erfunden habe. Ein Programm zu schreiben, dass einfache Textdateien generiert, ist keine große Kunst. Den Effekt, den ich hier allerdings erziele, ist ungemein groß. Wer schonmal etwas mehr mit Latex geschrieben hat, weiß, dass es teilweise recht mühseelig werden kann, große Mengen an Informationen (v.a. in Form von Tabellen) zu schreiben. Immer wiederkehrende Muster, wo sich nur der Inhalt ändert, sind prädestiniert für solche Generatoren.

CS, Robert :)
 
Hi Robert,

ich bin der Entwickler des Observation Manager.
Du hast mit Deiner o.g. Analyse weitgehend recht. OM nimmt die Daten über eine GUI an und speichert sie in einem XML Format ab. Das verwendete XML Format nennt sich <OAL> OpenAstronomyLog und ist eine coproduktion von internationalen Entwicklern, die sich auf ein Format zur Datensicherung für astro. Beobachtungen geeignigt haben. (http://code.google.com/p/openastronomylog/)
XML bietet in meinen Augen z.B. gegenüber einer Hashtable den Vorteil einer klaren Struktur, incl. Abhängigkeiten etc.
Aber klar, wenn man will bekommt man auch alles in eine Hashtable reingedrückt.

OM bietet auf Basis dieser Datenstruktur dem Benutzer verschiedene Aufbereitungen/Analysemöglichkeiten der Daten an. Als ich damals (vor gut 10 Jahren) mit dem OM gestartet bin dachte ich mir, daß das Programm evtl. anderen Beobachtern ebenfalls nützlich sei, daher ist es zum OpenSource projekt geworden.

Aber klar, wer keine speziellen GUIs mag und seine Berichte lieber mit TeX, perl, Bash-scripts aufbereitet, für den ist OM evtl. nicht das richtige.
(Absolut nicht wertend gemeint. Ich bin selbst Informatiker, Linux-User und habe auch einen ganzen Sack voller Bash und Perl Scripte für alles mögliche...ist einfach geschmackssache)

Grüße

Dirk
 
Hallo Dirk,

das mit dem XML-Schema <OAL> klingt richtig gut. Nun wäre es vielleicht überlegenswert, ob ich meine Datenstruktur an das XML-Schema anpasse. Das hätte dann folgende Vorteile: Nutzer von Observation Manager (und andere Programme, die <OAL> nutzen) können ihre Daten (als XML-Datei) z.B. in ein Perl-Modul stecken, durch geeignete Funktionen filtern/verarbeiten/was auch immer und dann z.B. ein sauber druckbares Dokument (z.B. über Latex) erhalten. Von Werner wurde ja schon der Wunsch in diese Richtung geäußert. Alternativ kann ich (für die Puristen) einfache Mittel (ohne GUI) bereitstellen, welche eben solche XML-Dateien auch erweitern/schreiben können. Ich würde es dann als Erweiterung bzw. kompatible Lösung zu bestehenden Produkten sehen.

Gruss, Robert
 
Hallo Werner,

da es mir hier ja eigentlich nur um die Idee geht und nicht um die reale Umsetzung: Nimm doch einfach eine Programmiersprache deiner Wahl, parse die XML-Datei und generiere dir daraus dein Tex-File :) XML-Parser sollten für die meisten Sprachen verfügbar sein. In meinem Tex-File habe ich teils auf Makros gesetzt, sodass ich auf Perl-Seite an wenigen Stellen einfach diese Makro nutzen kann. Genauso gut (um meine Datenstrukturen nicht über den Haufen zu werfen) könnte ich auch ein Mapping der OM-Datenstruktur auf meine eigene vornehmen. Musste auch gerade feststellen, dass die XML-Struktur von <OAL> manche "Eigenschaften" nicht zulässt, die ich aber gerne hätte. Insofern halte ich mich etwas zurück, ganz auf <OAL> zu setzen.

Gruss, Robert
 
Zuletzt von einem Moderator bearbeitet:
Hallo Werner,

das denke ich auch. Je nach Anforderungen an das Tex-File kann das Generieren mehr oder weniger aufwändig werden. Hängt auch stark von der zugrundeliegenden Datenstruktur ab.

Gruss, Robert
 
Hallo,

ich meld mich da mal als User eines solchen Programms.

Es sollte einfach zu bedienen, übersichtlich und nachvollziehbar sein, so wie der OM und deswegen nutze ich diesen mit Begeisterung. :)

Edit: Die Möglichkeit einer Druckfunktion in einen geeigneten Format / Aussehen würde zum OM noch sehr gut passen.
 
Zuletzt von einem Moderator bearbeitet:
Hallo Ulf,

an sich wäre es sicher kein Problem, sowas in den OM zu integrieren. Dirk muss ja ohnehin die XML-Files lesen. Aber: Jeder hat so seine Vorstellung, was in diesen Bericht alles enthalten sein soll und wie er strukturiert ist. Ich glaube, dass man hier auf individuelle Lösungen zurückgreifen sollte, da doch ein gewisser Aufwand notwendig ist. Deshalb die Idee, mit einer geeigneten Sprache XML-File auslesen und was tolles hinten ausgeben :)

Mir ist bewusst, dass die meisten hier ein benutzerfreundliches Programm erwarten. Aber es gibt halt auch welche (wie mich), die sich eher um die Funktionalität kümmern und versuchen, Dinge zu automatisieren.

Gruss, Robert
 
Na hallo,

da habe ich (Neuling) doch gleich den Observation Manager für mich entdeckt. Als Beobachtungsobjekte (bzw. Weitfeldfotoobjekte) könnten noch Sternbilder ergänzt werden. Ich habe heute ja nur Jupiter beobachtet und Orion durch Wolken fotografiert.

Gruß und Dank, Günther.
 
@Günther: Wie Robert schon sagte, kannst Du Dir im OM eigene Objekte anlegen z.B. für Sternbilder

@Robert: Ja klar. Jedes vordefinierte Datenformat, wie z.B: <OAL> verlangt eine gewisse Struktur an die man sich halten muß. Da wir (allem voran Thomas Pfleger (Eye&Telescope) u.a.) bei <OAL> verschiedene existierende Ideen (z.B. die VdS DeepSky Liste sowie das belgische DeepSkyLog (www.deepskylog.org)) in die <OAL> Specs mit eingearbeitet haben würde ich mal behaupten <OAL> ist schon ziemlich "vollständig" (was auch immer das sein mag) in seiner Definition. Ferner läßt es Erweiterungen zu.
Aber klar, jeder Benutzer und Autor von Bebachtungsberichten hat immer noch so seine eigene Idee, was fehlt/besser gemacht werden könnte, etc.
Von daher kann <OAL> (oder jedes andere Format) nie 100% jedem Nutzer gerecht werden. Schön ist aber, daß es mit <OAL> endlich einen defacto Standard gibt, mit dem man Daten austauschen kann. Frei nach dem Motto: Mein Programm hat seine eigene Struktur die 100% auf meine Bedürfnisse passt, aber ich kann <OAL> importieren/exportieren und damit bin ich kompatibel, wenn ich mein Programm mal nicht mehr pflegen mag, etc.
Kurzum, jedes weitere Programm welches (auch) <OAL> Daten verarbeiten kann, ist ein Gewinn für den Enduser!

Grüße

Dirk
 
Hallo Dirk,

vielleicht wäre es eine Überlegung wert, ein Perl-Modul zu schreiben, welches einen Satz von (sinnvollen) Funktionen bereitstellt, welche gezielt Informationen aus den XML-Files extrahieren (z.B. mit Filter-/Sortierkriterien). So könnte man diese Funktionen nutzen, um sich irgendetwas generieren zu lassen. Ich muss zugeben, dass meine "Lösung" erstmal nur schnell geschrieben und eher als "Proof-Of-Concept" anzusehen ist.

Eventuell könnte man auch andere Sprachen neben Perl nehmen, wobei sich hier die Frage stellt: Welche?

Falls jemand hier Interesse oder Vorschläge hat (vielleicht Werner?), einfach mal schreiben.

CS, Robert
 
Status
Es sind keine weiteren Antworten möglich.
Zurück
Oben