HYG 2.0 Database Problem - XYZ-Koordinaten ergeben Kugeloberfläche

Liebes Forum,

viele spannende Dinge sind hier zu erfahren; ich bin selbst kein Astronom, aber was noch nicht ist, kann ja noch werden :)

Mit einem Kollegen (wir betreiben 3D-Topologieforschungen und -experimente) möchten wir den Weltraum handgreiflich erfahrbar machen, indem wir aus Sternkoordinaten Polyeder ableiten, die dann, herunterskaliert, als Modelle in die Hand genommen werden können. Zu diesem Zweck hatten wir von Nick Strobel vom Bakersfield College die HYG 2.0 Database http://www.astronexus.com/node/34 als Excel-Datei erhalten, die auch auf die Sonne bezogene XYZ-Koordinaten beinhaltet und vieles mehr. Excel läßt sich z.B. in MATLAB usw. sehr gut nach Kriterien filtern und dann in 3D software verarbeiten, daher dieses praktische Dateiformat.

Nun gibt es aber eine Merkwürdigkeit: wie in den Bildschirmfotos ersichtlich, scheinen die meisten Sterne unter Verwendung der XYZ-Koordinaten auf eine Kugeloberfläche projiziert zu sein, anstatt, wie z.B. hier http://www.atlasoftheuniverse.com/20lys.html im Raum verteilt zu sein. Also machen wir etwas falsch, bzw. verstehen etwas die XYZ-Koordinaten betreffend nicht richtig.

Vielen Dank für einen Hinweis!

kannst du vielleicht ein paar Zeilen/Spalten der Excelfile hier bereitstellen? vielleicht liegt da der Fehler irgendwo?

z.b könnte ich mir vorstellen, dass die XYZ Koordinaten tatsächlich auf eine Kugelfläche projiziert sind und dann noch mit einer Entfernung multipliziert werden müssen?

auf der Seite find ich zum DL nämlich keine CSV mit XYZ koordinaten, sondern meist eben Kugelkoordinaten/Polarkoordinaten http://en.wikipedia.org/wiki/Equatorial_coordinate_system

RA und DEC und Distance ergeben dann die Koordinaten. Falls ihr aber wirklich XYZ bekommen habt, ists vielleicht anders.^^

Hallo Kryo,

vielen Dank für die schnelle Rückmeldung; es sind 22,5MB Daten für 119617 Sterne - ich kann allerdings keine Datei mit z.B. 20 Sternen hier anhängen... oder doch?

Gliese   X   Y   Z
         
         
GJ 1001   727.591   0.14718   -625.623
GJ 1002   465.686   0.13769   -0.61445
GJ 1003   1.629.864   0.52219   913.547
GJ 1004   701.307   0.37624   849.904
GJ 1005 A   49.955   0.33751   -144.822
GJ 1006 A   1.879.688   133.389   680.746
GJ 1006 B   1.432.191   101.515   519.025
GJ 1007   1.754.898   129.898   158.065
GJ 1008   2.037.576   170.142   -359.209
GJ 1009   1.547.248   148.529   -948.994
GJ 1010 A   434.956   0.44789   1.922.909
GJ 1010 B   34.619   0.35943   1.530.789
GJ 1011   1.483.815   152.504   673.567
GJ 1012   1.317.511   165.732   -154.897
GJ 1013   15.996   221.813   -165.617
GJ 1014   1.517.658   239.399   284.263
GJ 1015 A   1.275.964   23.245   1.910.897
GJ 1015 B   1.275.892   232.533   1.910.934
GJ 1016   1.628.669   29.827   -1.101.122
GJ 1017   2.620.536   47.686   -3.448.397

Leider sind in HYB 2.0 nicht wie hier http://www.atlasoftheuniverse.com/stars.html Namen aufgeführt. Die http://www.atlasoftheuniverse.com/ website ist leider seit 2006 nicht mehr gepflegt worden, so daß sich nicht herausbekommen läßt, ob es noch andere umfangreiche Dateien mit XYZ-Koordinaten gibt...

Hallo,

welche Punkte sind da jetzt 1000er-Zeichen und welche sind Kommas?

ja genau, darin könnte ein Problem liegen. Prüfe mal die excel einstellungen. leider ist das oft ein gemurkse, wenn man eine "englische" excel datei mit "deutschen" Einstellungen öffnet. Vielleicht bevor du die original datei öffnest zunächst excel settings so editieren, dass "," das trennzeichen für 1000er ist und "." das dezimaltrennzeichen.


möglich wäre aber auch, dass Nick Strobel ein Fehler unterlaufen ist, als er die Äquatorialkoordinaten in kartesische Koordinaten umgewandelt hat^^

Hallo Schillrich & Kryo,

danke für die Rückmeldung. Nein, die Punkte aus Excel sind nur Tausender-Trennzeichen für die Anzeige, die Werte sind ganzzahlig, ohne Punkt und Komma. Er schreibt dort "13. * X,Y,Z: The Cartesian coordinates of the star, in a system based on the equatorial coordinates as seen from Earth. +X is in the direction of the vernal equinox (at epoch 2000), +Z towards the north celestial pole, and +Y in the direction of R.A. 6 hours, declination 0 degrees."

Vielleicht gibt es noch andere umfangreiche Dateien, die bei wissenschaftlichen Institutionen heruntergeladen werden können? Hier http://www.atlasoftheuniverse.com/nearstar.html und http://www.atlasoftheuniverse.com/stars.html sind nur sehr kurze Teil-Listen zu sehen, die schließlich auch aus einer Datenbank stammen müßten? Wir könnten auch aus RA und Dec XYZ-Koordinaten errechnen, aber dazu bräuchte es auch eine Datei...

In deinen Zahlen steht u.a. : 0.14718

Das sieht arg nach einem Dezimalpunkt aus, nicht nach einem Tausender-Punkt. Immerhin müsste da sonst auch nach der 7 ein Punkt kommen.

eben, es kann sich nicht nur um 1000er trennzeichen handeln, irgendwo muss das gemischt worden sein..

http://www.astronexus.com/node/34 hier gibts doch downloads mit den daten.

In deinen Zahlen steht u.a. : 0.14718 Das sieht arg nach einem Dezimalpunkt aus, nicht nach einem Tausender-Punkt. Immerhin müsste da sonst auch nach der 7 ein Punkt kommen.

0.147. 18  etwa so? Hihi HausD?

Hallo Schillrich & Kryo,

tja, die Plausibilität der Werte kann ich als Nicht-Astronom nicht beurteilen :o aber besser ist wohl, ich schaue mir nochmal die originäre CSV-Datei an, David Nash's Github repository - da kommen die Daten her.

Ansonsten - aus RA und Dec selbst XYZ berechnen, wenn der Datei nicht zu trauen ist? Allerdings wurde sie für http://astronexus.com/node/28 und viele andere Dinge benutzt - und dort wurde doch sicher kein Fehler gemacht?

hab das hier runtergeladen: www.astronexus.com/files/downloads/hygxyz.csv.gz

und mit text in colums mit trennzeichen , und englischen excel settings ("." dezimaltrennzeichen) kommt was gutes raus

da sind auch xyz daten drin...und kein seltsames trennzeichenproblem.

So, wie ich die schon ans schlampige grenzende "das wies man doch" Auffassung der Am's kenne sehe ich (von ferne ) das so:
Bsp.: die letzte Zahl oben = -3.448.397 und das sind nach meiner Lesart minus 3 Tausend 4 Hundert und acht und vierzig DP(=Komma) 397
d.h. in den Zahelnkolonnen sind Tausender-Trenner und Dezimalpunkte munter durcheinander verwendet worden.
Eine andere Ursache kann natürlich die schon vorher falsch gesetzte Import-Bedingung sein, doddet pairs sind es sicher nicht!
Gruß HausD

Hallo Kryo & HausD,

vielen Dank für den Tip! Der filehoster liefert leider nur eine "iLividSetupV1.exe" Datei, die sich unter OSX leider nicht öffnen läßt; aber dank Deines Hinweises zur Formatierung (wir haben es auch mehrmals in .xlsx gewandelt aber wohl immer neue Fehler gemacht) kann ich die Daten ja selbst korrekt in EXCEL einlesen und ggf. das Komma vor und zurückschieben...

Es hätte mich auch mehr als gewundert, wenn der Fehler in HYG 2.0 gewesen wäre ;)

iLividSetupV1.exe dann ist das wohl ein trick ich lösch den link wieder lieber, so hieß die datei näämlich nich^^ virusgefahr