Diskussion:Gliese 436

Koordinaten

Für Gliese 436 werden bei Simbad 114211.094111^h 42^m 11.0941^s und 2264223.652+26° 42′ 23.652″ - in dieser Genauigkeit - angegeben. Warum also auf Stellen verzichten ? Die Rundung erfolgt jetzt in der Vorlage mit hilfe der beiden Fehlerparameter Als Quelle für die Magnituden und die Parallaxe habe ich den Hipparchos-Katalog genammen. Ich sehe keinen Grund, diese Werte der technich zu runden, wenn sie so drin stehen. ÅñŧóñŜûŝî (Ð) 02:02, 19. Apr. 2010 (CEST)

Was soll denn der Unsinn? Man braucht ja wohl keine Parameter, um anzugeben, wie genau man runden will, das kann man auch direkt machen.

Mach Dir mal ein Bild davon, was eine Millibogensekunde ist! Auch ein Text zur PSF und ihrer Bedeutung wäre eine Lektüre wert. Es ist gerade nicht das Ziel von Wikipedia, blindlings irgendwelche Zahlen von irgendwo abzuschreiben. Ein Beispiel: Der "Punkt", den Gliese 426 auf einer DSS-Aufnahme hinterlässt, hat etwa einen Durchmesser von 1 Bogensekunde, also 1000 Millibogensekunden... Rechne als kleine Übung mal aus, was für ein Gerät Du nach Rayleigh bräuchtest, um eine Millibogensekunde aufzulösen. Von atmosphärischen Störungen reden wir da schon gar nicht. (Wie viele Amateurastronomen haben wohl ein 10-Meter-Teleskop mit adaptiver Optik im Vorgarten stehen?) Ich weiss nicht, was Du mit den zusätzlichen Ziffern willst. Information enthalten sie jedenfalls nicht. Du könntest sie auch von einem Zufallsgenerator erzeugen lassen. -- 83.77.98.73 03:20, 19. Apr. 2010 (CEST)

Wenn man nur den Text ausgeben will, dann hast du Recht. Es geht aber noch um Folgendes:

Oben auf der Seite kann man unter "Datenbanklinks zu .." Ein Tool aufrufen, welches diverse Webseiten anbietet, darunter auch die Umgebungssuche von SIMBAD mit diesen Koordinaten als Target (hier "Area-search" genannt). Die zusätzlichen Ziffern entsprechen der ICRS-Angabe und bewirken, dass das Objekt des WP-Artikels bei der Abfrage in der ersten Zeile steht. (mit einem Abstand von 0,00 arcsec zum Target). Die Dezimalstellen werden also intern benötigt. Deshalb unterschiedliche Genauigkeit zw. Darstellung und Queries. Deshalb die Ziffern.

P.S.: Ich weis, was eine Milliwinkelsekunde ist. Unter diesem Winkel erscheint vom Mond aus betrachtet ein auf der Erdoberfläche liegender, 1,86 m großer Mensch.

ÅñŧóñŜûŝî (Ð) 04:45, 19. Apr. 2010 (CEST)

Hm, also bei einer Suche kann man ja wohl nicht erwarten, dass genau das Objekt rauskommt. Das ist quasi das Wesen einer Suche. Die Suche braucht man zudem doch eher dann, wenn man die das Objekt noch nicht kennt und nicht wenn man schon ganz genau weiss, was man sucht... Ferner können sich die Koordinaten in SIMBAD grundsätzlich jederzeit ändern. Ich seh wirklich das Problem nicht, aber was solls. Man kann offensichtlich von einem Wikipedia-Artikel auch nicht so viel Wissenschaftlichkeit erwarten.

Nur noch etwas: Es heisst Millibogensekunde. (Das weiss sogar Wikipedia!) Und diese Millibogensekunde ist wirklich sehr klein. Wie Du wahrscheinlich weisst, haben wir - und zwar deutlich - keine Chance, Menschen oder Gerätschaften auf dem Mond von der Erde aus aufzulösen. Hochauflösende Hubble-Bilder (dafür kriegst Du nicht ohne weiteres Teleskop-Zeit) haben etwa so um die 50 mas pro Pixel. Da musst Du schon recht kreativ werden, um die Millibogensekunden-Genauigkeit da statistisch rauszukriegen.

Aber bevor wir noch weiter abgleiten, beenden wir das Klugscheissen hier dann wohl doch besser. -- 83.77.98.73 05:32, 19. Apr. 2010 (CEST)

Bogensekunde: Ok, akzeptiert.

Es geht bei "Area-Search" um die Frage: "Was befindet sich in der Nähe von Objekt XY ?" Daher die "Zentrierung" auf das bekannte Objekt. Mit dem Parameter kann man jetzt den Kompromiss finden. Ich könnte allenfalls eine feste Rundung einbauen, welche dann aber alle Sterne betreffen würde, was ich für noch schlechter halte, da die Genauigkeit der Werte von Objekt zu Objekt schwankt. Außerdem sind mit der Infobox Stern auch Doppelsterne erfasst, für deren Komponennten es nicht genug bekannte separate Daten gibt. Wenn es da messbare Abstände gibt, dann geht das mit den 0,001 Bogensekunden sowieso nicht mehr hin.

Ich werde mir mit dem Query aber bestimmt noch etwas besseres einfallen lassen.

ÅñŧóñŜûŝî (Ð) 12:55, 19. Apr. 2010 (CEST)