3D-Karte unserer Milchstraße

[Bernhard]

ich dachte auch eher daran, dass man von der Seite evtl. auch entsprechende Daten bekommen kann.

Hi cuxmini,

solche Vorschläge sind zwar sicher nett gemeint (Danke), aber erst dann hilfreich, wenn die exakte Quelle angegeben wird und idealerweise auch eigene Erfahrungen mit der Quelle gemacht wurden .

@Peter:

habe gleich wieder ein Update eingespielt (s. Commit-Browser). Die Sternbilder sind aber noch nicht fertig. Da kommt noch ein bisschen was nach.
Gruß

 

[pmvstrm]

Hi Bernhard

Ganz deiner Meinung was die Sache mit Boinc betrifft.
Ja mit den Checkins funktioniert es jetzt glaube ich ganz gut. Ich habe aber in der Doku zu Mercurial gelesen das nur im Tip Bereich
entwickelt werden und im Branch Bereich jeweils eine stable Version bereit steht, damit Entwicklungs und Releases sich nicht
in die Quere kommen. Wir haben nun beides immer gleichmässig mitgezogen aber ich glaube ich kann die Branches wieder
entfernen und wenn es ein Release von Tip gibt, laden wir eine Stable Version nach Branch hoch.

Grüße Peter

 

[Bernhard]

laden wir eine Stable Version nach Branch hoch.

Hallo Peter,

nur zum Verständnis: Wie macht man das eigentlich, bzw. wie machst du das?
Gruß

 

[Bernhard]

Hallo Peter,

ich habe gerade gemerkt, dass in dem Hipparcos-Katalog nicht alle Nummern eine gültige Parallaxe haben. Man muss beim Laden also Informationen ergänzen, bzw. beim Anzeigen der Sterne unterdrücken. Deswegen fehlt auch noch eine Linie bei den Sternbildern im Großen Wagen .

Ich werde als nächstes also nachsehen, welche Entfernungsangaben fehlen und auch nachsehen, ob diese Angaben zusätzlich aus dem hyg.csv ergänzt werden können. Die Funktion OpenCatalogues muss also verbessert werden und das ist dann wohl die nächste größere Aufgabe.

Grüße, Bernhard

 

[pmvstrm]

Hi Bernhard,

Also ich nutze Mercurial bei diesem Projekt auch das erste mal. Aber nach dem was ich jetzt weiß, ist jedes Commit ein Changeset, was wiederum eine
atomisierte Einheit mehrerer Ereignisse mit eindeutiger ID ist, die dann in der History landet. Mit commit fügt man eigene Änderungen an seinem
lokalen Projektordner durch und wird somit in der lokalen Historie gepflegt. Mit push und update werden Änderungen final durchgeführt und mit
entfernten Repositories abgeglichen (alle Dateien die lokal geändert wurden und zur Übermittlung zwecks Verteilung anstehen lassen sich mit
hg status anschauen). Mit hg log kann man dann die wirkliche Historie anschauen (was wo wann passiert ist). Wenn zwei Änderungen,
die nicht gemergt wurden nicht aufgelöst wurden, entsteht als Konsequenz ein eigener Zweig in der History (daher wohl auch die
dein eigener Zweig auf Sourceforge). Nach derzeitiger Info schaut es so aus, das aus einem TIP irgendwann automatisch ein Branch
wird, aber die Bedingungen die dazu führen sind mir noch ein Rätsel (mea culpa)

ps:
Was aber wohl nicht geht, ist, dass man die History so einfach löschen kann, davor wird sogar gewarnt. Wenn wir also wirklich
irgendwann mal ausmisten wollen, müssen wir wohl sauber auschecken, auf SF das Repo im Adminbereich löschen und das ganze
wieder einchecken und somit eine neue History aufbauen.

Vorschlag:
Am besten wir machen erstmal weiter wie bisher und wenn wir sicher sind das wir die Version 1.0 Release haben,resetten wir
das Sourceforge Repo (ist denke ich am wenigsten Aufwand). Vermutlich ist das sowieso die beste Idee, dann können wir
uns vielleicht auch einen neuen Namen und Bereiche für die einzelnen Setup Projekte einrichten, denn Mercurial mag keine
Unterprojekte (da müssen wir bevor wir das dann machen alles genau planen)

Gruß, Peter

 

[pmvstrm]

Hallo Bernhard,

Ich habe jetzt gerade noch ein Icon für das Programm und einen Unterordner "./resources" angelegt. Darin liegen die Dateien
my3dsc.ico und my3dsc.rc .Du kannst das Projekt auschecken und bindet das Icon (momentan nur Windows) korrekt ein. Ich habe
es in einen frischen Ordner ausgecheckt, der Unterordner und die zwei Dateien werden richtig ausgecheckt. Übrigens habe
ich herausgefunden wie das mit Tip und Branch geht.

Beim Adden und Single File commit kannst Du das Ziel angeben (Tip oder Branch). Da kann man fortan einfach immer stur
TIP angeben und gut. Wenn wir dann einen Branch wollen, muss man dann dort halt Branch einstellen (entweder Default
als Standardwert oder z.B Release 1.0)

Grüße, Peter

 

[Bernhard]

Vorschlag:
Am besten wir machen erstmal weiter wie bisher

Hi Peter,

gerne. Gib mir aber bitte bescheid, ab wann Du mit Deinen aktuellen Änderungen fertig bist. Ich habe gerade gesehen, dass wir momentan beide an dem Projekt arbeiten, bzw. arbeiten wollen. Ich habe meine Sachen also erst mal lokal abgespeichert und habe mir Deine neuen Änderungen geholt.

Ich fände es vorteilhaft, wenn wir vereinbaren würden, wer wann einchecken darf (z.B. die Tagesregelung von weiter oben), damit wir uns nicht gegenseitig behindern, bzw. Code gegenseitig löschen. Ich hatte nämlich schon wieder die Aufforderung ein push -f zu machen und dann wären Deine Änderungen von heute abend wieder weg gewesen .
Gruß, Bernhard

 

[pmvstrm]

Hi,
Also laut Doku macht Mercurial keinen Ärger wenn man in der gleichen Datei arbeitet.
Allenfalls wenn beide an der gleichen Codestelle hantieren, kann es zu einer Mergeaufforderung kommen. Aber das mergen ist nun mal das tägliche
Geschäft bei Versionskontrollsystemen, das müssen wir beide aus dem FF heraus beherrschen. Lieber kurz und schmerzloss anstatt Stundenpläne
aufstellen denn ansonsten kann man nicht produktiv an einem Projekt arbeiten. Wenn Du committest, addest oder updatest klicke immer automerge
an, dann wird Dir das gröbste schon abgenommen. Die anderen Projekte kriegen das auch hin, das schaffen wir auch

Gruß, Peter

 

[Bernhard]

Hallo Peter,

ich habe jetzt einfach mal mit Windiff meine Änderungen nachträglich eingebaut (manuelles merging) und dann mit push -f eingecheckt. Auch wenn der Commit-Browser jetzt mehr anzeigt, als ich dachte, sieht der aktuelle Code so aus, als wären alle aktuellen Änderungen von uns vorhanden.

Zu dem neuen Icon: Da wäre mir ein Icon mit mehr Bezug zur Astronomie lieber. Ein gelber Kreis ist zwar besser als gar nichts, sagt mir aber über das Programm zu wenig aus. Besser fände ich z.B. einfach den Schriftzug "3D" oder ein paar Sterne.
Gruß

 

[pmvstrm]

Guten Morgen,

Ja perfekt!
Das mit Windiff werde ich in Zukunft genauso handhaben.Für Leute die nicht zum Projekt gehören und einen Patch vorschlagen existiert
auch eine Funktion namens Export. Diese Einsendungen werden dann in der Patchwarteschlange angezeigt und werden dann von einem
der committer nach in Augenscheinname entweder angewendet oder verworfen.

ps:
Um ein neues Icon kümmere ich mich, das sollte kein grösseres Problem sein.
Ich werde hier ein paar Designvorschläge im Forum verlinken und dann nehmen wir das was uns beiden am meisten zusagt

So, nach all dem Stress jetzt erstmal einen guten Schluck Kaffee

Gruß, Peter

 

[Runzelrübe]

Theoretisch könnte man ja ein Hardwaredevice für Teleskope bauen und dann aufgrund der GPS des Handybesitzers
das Teleskop auf den Stern im Display ausrichten (nur so eine Idee)

Extra Hardware braucht man dazu nicht erfinden, die gibt es nämlich seit Jahren zur automatischen Nachführung.

http://www.fernglas-store.ch/conten..._Serie_mit_vollautomatischer_Ausrichtung.html

Man braucht eher eine Schnittstelle zu dem jeweiligen Steuerungsprogramm. Es gibt hier mehrere Hersteller, die aber natürlich alle die Gemeinsamkeit haben, damit Geld verdienen zu wollen.

Die 3D-Ausrichtung eines Mobiltelefons anhand der GPS-Richtung seines GPS-Empfängers plus der Ausrichtung durch seinen Trägheitssensor werden mittlerweile durch eine Menge Spiele genutzt. Zur Ausrichtung eines Teleskops anhand einer Sternkarte bräuchte man nur identische Sternkarten und besagte Motorennachführung.

Für solche Hard- und Softwarekombinationen, die nicht Open Source sind, gelten allerdings strikte Exporteinschränkungen.
Eine Präzisionsausrichtungssoftware, die für jeden quelloffen und ohne reverse engineering zugänglich ist, kann nämlich schnell in eine Verfolgungssoftware umgebaut werden, indem der Updatezyklus an die Hardwareschnittstelle auf einen Sekundentakt gesetzt wird. Das kann ziemlich schnell ziemlich offensiv missbraucht werden, beispielsweise als Raketenausrichtung per Handy - es muss schließlich kein Teleskop an die Halterung montiert sein.

Trägheitsverfolgungssysteme wurden erstmals in den 50ern des letzten Jahrhunderts vom Militär entwickelt und da tut sich immernoch einiges.

 

[pmvstrm]

Icon Auswahl

Hi,

Ich habe hier mal einige freie Icons gefunden, die ich für unser Projekt in allen 3 Phasen
getestet habe, da sich das Endergebnis doch teilweise sehr vom Original unterscheidet

Und hier die Kandidaten:

Mein Favorit ist Icon 6

Gruß, Peter

 

[Bernhard]

Mein Favorit ist Icon 6

Hi Peter,

ich finde die Nummer 5 richtig stark, weil da auch das Icon einen gewissen 3D-Effekt zeigt. Icon 6 finde ich dagegen eher ungeeignet (Sorry), weil das Programm doch Beobachtungstandpunkte weit weg von der Erde simulieren soll. Dieses Feature haben wir zwar noch kaum besprochen, ist aber dennoch vorhanden. Und genau da liegt doch die Stärke des Programms. Alles andere kann Cartes Du Ciel viel besser.

Ich gebe aber zu, dass Icon 6 von der Optik her mehr "her macht", als Icon 5. Wie wäre es also, wenn wir Kibo dazu überreden würden Icon 6 in ein Qt-Programm zur Atmosphärenerosion einzubauen? Das würde meiner Meinung nach besser passen. Vielleicht kannst Du mir aber Icon 6 auch noch näher bringen. Die Entscheidung ist ja noch nicht gefallen.

 

[pmvstrm]

@Runzelrübe

Das war auch nur eine Idee, was man auf der Android Platform machen kann. Wenn überhaupt würde ich das vermutlich als Zusatzextension/PlugIn
für das Hauptprogramm machen. An die GPS Koordinaten kommt man sehr einfach, das ist unter Android nur ein API Call und dann hat man
Längen und Breitengrad. Man kann auch ebenso einfach die Gyroskopdaten (x,y,z Lageedaten) des Handiesabfragen z.B um eine
Kalibrierung mit dem Teleskop durchzuführen. Auf jeden Fall müsste für so ein Projekt ein USB Treiber für Antroid (Accessory) implementiert
werden um eine wie auch immer geartete externe Hardware / ein Thirdparty Servo Interface anzudocken.

Gruß, Peter

 

[pmvstrm]

Hi Bernhard,

Mit Icon 5 kann ich mich auch anfreunden. Ich müsste nur mal versuchen ob ich die Randausfransungen etwas glätten kann, denn
das hat man ja quasi ständig vor Augen wenn das Programm läuft.

Ich bin mit Icon5 einverstanden


Gruß, Peter

 

[Bernhard]

Ich bin mit Icon5 einverstanden

Supi...

ich werde als Nächstes dann versuchen die Lücken im Hipparcos mit Informationen aus dem hyg.csv zu füllen.
Gruß

 

[Kibo]

Hallo,

Ja daran wollte ich mich demnächst auch mal setzen. Ich habe gerade recht viel zu tun, aber das Icon ist vorgemerkt

 

[Bernhard]

ich werde als Nächstes dann versuchen die Lücken im Hipparcos mit Informationen aus dem hyg.csv zu füllen.

... was sich auch schon wieder erledigt hat: Kein einziger Treffer.

Bei SIMBAD bin ich bei HIP979 fündig geworden. Da wird eine Parallaxe angegeben. Die einzige fehlende Sternbildlinie zu HIP55203 in UMA läßt sich mit SIMBAD allerdings auch nicht schließen.

Für die 312 Sterne aus dem Hipparcos-Katalog ohne Parallaxe habe ich das zusätzlich Attribut m_ok in der Klasse CSterne eingeführt. Dieses Flag steht nach dem Laden des Katalogs auf false, so dass die Zeichenroutinen erst gar nicht in die Versuchung geraten, diese Sterne zu zeichnen.

Man kann jetzt SIMBAD noch nach weiteren Sternen ohne Parallaxen-Angabe durchsuchen und beim Laden des Katalogs diese Spezialfälle hart codiert nachtragen. Die Positionsangaben und die visuelle Helligkeit sind ja vorhanden. Das ist aber eine reine Fleißaufgabe.
Gruß

 

[Bernhard]

Hallo Peter,

beim Aufräumen überflüssiger Parameter hast Du zwei Events ausgebaut. Ich habe diese Events wieder eingebaut und an die Variablen ein accept() angehängt. Sonst speichern die Untermenüs ihre Einstellungen nicht mehr ab . Nur zur Info.

Ohne die Karteileichen aus dem Hipparcos-Katalog sieht die Milchstrasse aus 30.000 + 26.000 Lichtjahren Entfernung in der Scheibenebene jetzt wie eine schöne Edge-On-Galaxie aus. Das Halo aus Sternen ist jetzt nicht mehr sichtbar und war damit ein Darstellungsfehler. Es gab da auf den ersten Seiten dieses Themas ein paar Beiträge zu diesem Halo.

Hier die Einstellungen und die zugehörige Sternkarte:


Gruß

 

[pmvstrm]

Hi Bernhard,

Nicht schlecht Herr Specht!

Achso das mit den Variablen. Der Compiler war der Meinung das sie von nirgendwo referenziert wurden, also dachte ich mir: Weg damit
Aber ist kein Problem.Wenn es möglich ist versuche ich Warnungen, Notes und ungenutzte Variablen zu entfernen. Wo es möglich ist,
wäre ich auch dafür das wir QFile anstatt z.B fopen verwenden, wegen der Warnmeldungen, dann könnten wir aus dem Makefile auch die
Surpess MSVC Defines wieder entfernen (aber nur wenn Du damit keinen Aufwand hast, keinen Stress!)

Grüße, Peter