Vorlage Diskussion:Infobox Asteroid

Alte Beiträge (bis Juli 2007) können hier nachgelesen werden.

Position provisorische Bezeichnungen

Bei diesem Edit wurde versehentlich (?) die provisorische Bezeichnung ganz nach oben verschoben. Ich beabsichtige, dies wieder rückgängig zu machen (mach zu lassen), da dies offensichtlich nicht sinnvoll ist. Sollte jemand berechtigte Einwände haben, möge er sich hier äussern. -- 83.76.254.49 17:49, 25. Dez. 2008 (CET)

Man darf freilich auch Zustimmung kundtun... -- 83.77.128.188 01:41, 6. Jan. 2009 (CET)

Separates Feld für die Nummer

Hallo zusammen. Ich schlage vor, die Nummer des Asteroiden in einem separaten Feld zu speichern. Dies wäre für verschiedene Anwendungen von Vorteil. -- Herzliche Grüsse: CHRV 00:02, 5. Mär. 2009 (CET)

Die befindet sich bereits in SSD_ID . Diese ID wird für die Simulation auf der NASA-Website benutzt und ist mit der Nummer des Asteroiden identisch. Cäsium137 (D.) 14:46, 5. Mär. 2009 (CET)

Das ist nicht ganz richtig. Im Feld 'SSD_ID' befindet sich - wie der Name schon sagt und Du schon angetönt hast - eine eindeutige Kennung für den Asteroiden, die dazu gedacht ist, einen entsprechenden Link zum "JPL Small-Body Database Browser" zu erzeugen (was meistens auch funktioniert). Dieses Feld ist jedoch mitnichten mit der Nummer des Asteroiden identisch! Es kann sich dabei zum Beispiel auch um eine provisorische Bezeichnung handeln (unabhängig davon, ob der Asteroid eine Nummer erhalten hat oder nicht; ausserdem gibt es ja auch noch 'SSD_TNO'). So wäre zum Beispiel auch eine Konstruktion à la Informationen zum Asteroiden ({{SSD_ID}}) {{Name}} eine ganz schlechte Idee.

Da jedoch die Nummer des Asteroiden sowieso auch im Feld 'Name' eingetragen wird, dürfte es auch niemandem Einfallen eine solche Konstruktion zu verwenden. Eine Änderung ist also durchaus nicht zwingend notwendig. Die Redundanz ist verkraftbar, ich fände es trotzdem schöner und sauberer anders... -- Gruss: CHRV 21:53, 5. Mär. 2009 (CET)

Es ist tatsächlich so, dass in besagtem Feld beides stehen kann (und leider auch tut). Ich habe es mir mittlerweile zur Regel gemacht, das zu ändern und konsequent die Nummer des Asteroiden in das Feld zu schreiben. Allein deswegen schon, da die vorläufige Bezeichnung in der Vorlage nur funktioniert, wenn sie aus Jahr un Buchstabenkombination besteht. Bei den Survey-Nummern wie z.B. Palomar-Leiden arbeitet die Vorlage ohnehin fehlerhaft. Die Vorlage zu verändern und ein extra-Feld zu generieren, hieße, sämtliche Asteroidenartikel ändern zu müssen, um der neuen Vorlage gerecht zu werden. Ich wüsste nicht recht, wie das praktisch aussehen soll, da es davon bereits mehr als 2000 geben dürfte. --seismos 22:04, 5. Mär. 2009 (CET)

Ich habe noch keinen Fall gefunden, bei dem diese Nummer nicht der des Asteroiden entspricht, sofern dieser bereits eine hat. Nur wenn der A. noch keine hat, ist das anders. Hast du ein Gegenbeispiel ? Cäsium137 (D.) 22:27, 5. Mär. 2009 (CET)

Nein, spontan kann ich keins nennen, vermutlich wirst Du bei einigen Entdeckungen von van Houten/Gehrels fündig werden. Ich habe selbst unzählige Artikel angelegt, bei denen ich die vorläufige Bezeichnung verwendet hatte, daher bin ich mir da ziemlich sicher. Wie gesagt: Wo immer ich auf einen solchen Fall treffen, ändere ich das auf die fortlaufende Nummer. Sehr viele werden also nicht mehr übrig sein. Auf jeden Fall halte ich es für erstrebenswerter, diesen Eintrag bei SSD_ID konsequent umzustellen, als ein weiteres Feld zu kreieren, was dann redundant wäre. --seismos 22:37, 5. Mär. 2009 (CET)

PS: hab gerade mal ein Beispiel gefunden: Harriet (Asteroid). Davon gibt es sicher noch mehr verstreute...

Ganz recht, die gibts; die van Houtens mit Gehrels sind eine ergiebige Quelle. Ein weiteres Beispiel wäre etwa Humboldt (Asteroid) (mit diesen provisorischen funktionierts leider gar nicht). Übrigens, seismos, wieso hast Du als Hüter des Asteroiden-Lemma-Schemas denn hier noch nicht interveniert? ;-) -- CHRV 22:42, 5. Mär. 2009 (CET)

nun ja, nicht jeder Neuzugang spring einem gleich ins Auge... Aber wenn er Dir doch bereits aufgefallen ist... warum dann nicht du? Die Sache mit den Lemmata ist ja auch so eine Sache. Eigentlich wäre das korrekte Lemma ja das mit der Nummer vorweg (in Klammern, wenn ich mich nicht täusche) - aber dafür ist es mittlerweile leider viel zu spät... --seismos 22:57, 5. Mär. 2009 (CET)

Eben drum habe ich halt etwas Hemmungen bei solchen Verschiebungen. Ich weiss natürlich, dass es sonst fast unmöglich ist, die Liste der Asteroiden einigermassen aktuell zu halten (aber das ist es, wie man sieht, sowieso). Zu spät ist es nie in einem Wiki! Es ist eine Abwägung zwischen Vor- und Nachteilen, bzw. es wird der Arbeitsaufwand mit dem Nutzen verglichen. Da der Nutzen hier wohl unbestritten relativ gering ist, hat sich bisher niemand gefunden, der diese Arbeit auf sich nehmen will (und es wird sich vielleicht auch nie jemand finden; ich werds jedenfalls nicht sein). -- CHRV 23:43, 5. Mär. 2009 (CET)

Was die Sache angeht: Wie gesagt: Ich bin nicht der Meinung, dass dies zwingend geändert werden müsste, fände dies aber hübsch. Falls es geändert würde, müsste man meiner Meinung nach auch nicht jetzt und sofort alle Infoboxen und Artikel anpassen. Durch die Änderung würde übrigens nicht Redundanz geschaffen, sondern verringert: Denn, wo es das Feld 'Nummer' gäbe, stünde natürlich nicht mehr die Nummer im Feld 'Name' (das würde die Vorlage machen) und das Feld 'SSD_ID' gäbe es in diesen Fällen natürlich auch nicht mehr. (Momentan steht die Nummer aber bei 'Name' und 'SSD_ID'.) -- CHRV 22:52, 5. Mär. 2009 (CET)

Ich verstehe, was du damit beabsichtigst, aber wie soll das mit der Änderung nach und nach funktionieren? Die Nummern stehen ja überall in den Artikeln drin und würden bei einer Umstellung dann ggflls. doppelt in der Infobox stehen. Wäre es da nicht einfacher, die verbliebenen "Falsch"einträge unter SSD_ID zu ändern? --seismos 22:57, 5. Mär. 2009 (CET)

Einfacher wäre das ganz bestimmt (eine pragmatische Lösung). Einfacher ist manchmal aber nicht besser. Deshalb stelle ich es auch hier zur Diskussion. Wir sollten hier ebenfalls Vor- und Nachteile sorgfältig abwägen. Also:

• Vorteile: (ein ganz klein bisschen) weniger Redundanz, einheitliche Formatierung des Namens sichergestellt in der Form (Nummer) Name, die Nummer (bzw. die Information, ob eine Nummer vergeben wurde, unter der Voraussetzung, dass der Artikel aktuell ist) steht für die weitere Verwendung in der Vorlage separat zur Verfügung (momentan allerdings kein Bedarf dafür absehbar).
• Nachteile: Da sich die Änderung der Infoboxen (soweit ich das beurteilen kann) nicht automatisieren lässt, müsste dies manuell erfolgen (einiges an Arbeit). Da dies niemand alles machen kann / will, würde es sehr lange dauern (wohl mehrere Jahre) bis alle Infoboxen angepasst wären. In dieser Zeit gäbe es also verschiedene "Klassen" von Artikeln (mit Infobox "vor und nach der Reform") und in der Vorlage müssten bestimmte Abfragen sicherstellen, dass der Leser davon nichts merkt.
• .... (bitte ergänzen)

CHRV 23:43, 5. Mär. 2009 (CET)

Bei Harriet ist der Link falsch. Der führt gemäß Nummer zu "6557 Yokonomura (1990 VR3)". die SSD_ID ist einfach falsch. Es gibt eine einfache Methode, die SSD_ID nummerierter A. von den anderen zu trennen: Die Vorlage:IstZahl. Damit lässt sich was anfangen. Cäsium137 (D.) 23:29, 5. Mär. 2009 (CET)

Falsch ist da relativ. Angegeben war die Bezeichnung bei Entdeckung. Nur ist die Vorlage für diese Survey-Sonderfälle nicht gemacht. Geändert werden muss das so oder so... --seismos 23:40, 5. Mär. 2009 (CET)

Vorlage:IstZahl wäre grundsätzlich eine gute Idee, aber damit lässt sich die Redundanz auch nicht reduzieren (oder übersehe ich etwas?). -- CHRV 23:48, 5. Mär. 2009 (CET)

Da hast du recht. Diese vorlage ist insgesamt nicht mehr besonders "Up to date". Viel zuviele Textparameter statt der reinen Werte, mit denen man auch Redundanz vermeiden kann. So hat bestimmt kaum eioner nachgerechnet, ob gr. Halbachse und Exzentr. . zu Perihel und Aphel passen. Es stellt sich echt die Frage nach einer weitgehend neuen Infobox. Cäsium137 (D.) 23:57, 5. Mär. 2009 (CET)

Nachgerechnet sicher nicht. Die Werte sind - soweit es sich um meine eingestellten Artikel handelt - aus AstDys übernommen. Könnte man das Ganze vielleicht mit einem Bot rundum erneuern? Ich kenne mich damit nicht aus, aber vielleicht kann man die alte Infobox irgendwie elegant gegen eine neue ersetzen? --seismos 00:21, 6. Mär. 2009 (CET)

Vollständig nicht. Mein Bot ist da nicht so gut drin. Aber C&P-Rohlinge für die zu ersetzenden Zeilen kann ich ggf. offline erstellen. Das ginge dann zumindest halbautomatisch. Cäsium137 (D.) 00:41, 6. Mär. 2009 (CET)

Begriff Simulation

Das in der Vorlage als Simulation Bezeichnete ist keine Simulation, sondern eine Visualisierung (Animation passt aus Platznot auch, wenngleich eine A. meist nicht interaktiv ist). – Rainald62 23:20, 30. Apr. 2010 (CEST)

Wenn man das Play-Button anklickt, dann ist es zumindest eine Animation. So falsch ist es also nicht. ÅñŧóñŜûŝî (Ð) 00:40, 1. Mai 2010 (CEST)

Ja, Animation ist viel richtiger als Simulation, denn es steht kein physikalisches Modell dahinter, Stichwort Gravitationswechselwirkung, sondern lediglich Ephemeridenauswertung und Projektion. Ich ändere das mal. – Rainald62 17:31, 1. Mai 2010 (CEST)

Rotationsdauer und Einbindungen

Es ist ja primär nicht verkehrt, die Zeiteinheit in die Vorlage einzubauen, aber dann muss man sich auch die Mühe machen, die bereits vorhandenen Einträge in den Artikel zu bereinigen. In den meisten dürfte jetzt zweimal "h" drinstehen... --seismos 21:43, 28. Apr. 2011 (CEST)

Ursache ist die unterschiedliche Eingabe im Laufe der Zeit. Aufgrund der stark unterschiedlichen Werte ist es besser, wenn die Einheit bevorzugt Bestandteil des Parameterwerts ist. Ich habe daher das "h" aus der Tabellenzelle genommen und - für die Seiten ohne "h" - durch eine Fußnote ersetzt. Das kommt auch deinem im November geäußerten Wunsch nach Userfreundlichkeit entgegen, da jetzt Klartext bevorzugt wird.

Die damals von mir angeregte, diskutierte Sanierung der Einbindungen auf einen einheitlichen, benutzerfreundlichen Standard wurde bisher nicht durchgeführt und ist sowieso überfällig. Diese Arbeit gehört wieder auf die ToDo-Liste. Ich schlage daher vor, wegen dem einzelnen Parameter nicht extra die Artikel abzuklappern. ÅñŧóñŜûŝî (Ð) 22:03, 28. Apr. 2011 (CEST)

Link Orbitalgeschwindigkeit

Der Link von Orbitalgeschwindigkeit landet im Artikel Geschwindigkeit, wo der Begriff aber nicht erklärt wird. Da wäre es wohl besser Orbitalgeschwindigkeit gar nicht zu verlinken. Gruß, -- Hans Koberger 19:16, 20. Feb. 2012 (CET)

Ich habe den Redirect mal passend umgebogen. Jetzt ist natürlich das Problem, dass entweder a) der Leser unter Umständen merkt, dass gar nicht klar ist, was eigentlich genau gemeint ist oder b) er im Zielartikel keine passende Erklärung findet. -- 178.198.24.98 14:40, 21. Feb. 2012 (CET)

Mein Interesse ist geweckt: Wie definiert sich denn nun die Orbitalgeschwindigkeit. Gäbe es da nicht die Möglichkeit, dass die Wissenden einen kurzen erklärenden Artikel schreiben. Muss ja nicht länger als 2 oder 3 Sätze sein. So, dass es halt ein behaltenswerter Stub wird. Gruß, --Martin1978 ^☎/_± WPVB 14:06, 28. Feb. 2012 (CET)

Datum der Entdeckung mit Komma? und Datumsverlinkung

Ich stolperte gerade umseitig darüber, daß das Datum der Entdeckung in der Form [[Tag. Monat]], [[Jahr]] angegeben werden soll. Wozu das Komma? Soll das tatsächlich so sein? In der umseitigen Beispiel-Infobox sehe ich kein Komma (und auch keine Verlinkung). Gruß --Schniggendiller Diskussion 23:44, 14. Jun. 2012 (CEST)

Es kommt auch kein Komma hin. Umseitig ist das Komma Bestandteil des Satzbaus, nicht Teil des Formats. ÅñŧóñŜûŝî (Ð) 15:10, 15. Jun. 2012 (CEST)

Okay danke. Bleibt noch die fehlende Verlinkung in der Beispiel-IB ... Gruß --Schniggendiller Diskussion 01:11, 16. Jun. 2012 (CEST)

Ich nehme die Verlinkung des Datums raus, da dies nicht den Konventionen (vgl. WP:DK, WP:VL#Daten verlinken) entspricht. -- Hans Koberger 08:57, 19. Jun. 2012 (CEST)

Dezimalpunkt

Sollte in der Erklärung nicht das Wort "Dezimalpunkt" mit "Dezimalkomma" ersetzt werden? --Gereon K. (Diskussion) 09:48, 8. Mai 2013 (CEST)

Wartungslisten

Ich kann nicht behaupten, verstanden zu haben, wofür die Wartungslisten gut sind. Insofern bitte ich um Verzeihung für meinen sicher wieder unnötig überheblich wirkenden Eingriff. Mir geht es um die Lesbarkeit des Quelltextes. Und der besagte bisher, dass zuerst geprüft wird, ob die Parameter „SSD_ID“ und „Nummer“ Zahlen beinhalten. Wenn nein, wird kein Wartungslink gesetzt. Wenn ja, werden alle Artikel mit einer SSD_ID kleiner als 10000 als „Fehler 1“ und alle anderen als „Fehler 2“ kategorisiert. Nach meiner Änderung: Es gibt keine extra Prüfung mit einer Multiplikation mehr, sondern das passiert automatisch während des Kleiner-als-Vergleichs (Beispiel: »«). Der Parameter Nummer entfällt. Am Resultat ändert sich nichts. --TMg 23:14, 23. Jul. 2013 (CEST)

Das ist doch gerade das Gegenteil des gewünschten Effekts. Aktuell werden alle korrekten Einträge in Wartungslisten eingetragen und alle falschen nicht. Die Unterscheidung nach der Zahl ergibt für Wartungslisten auch keinen Sinn - denn gewartet werden muss nur, was nicht als Zahl interpretierbar ist. Ich habe es nun geändert, und ein paar Artikel sind schon aufgetaucht. --mfb (Diskussion) 23:34, 12. Nov. 2014 (CET)

Hm... Vielleicht hätte er jemanden fragen sollen, der sich damit auskennt? -- Tent*nerveç (Diskussion) 15:05, 13. Nov. 2014 (CET)

Hast du auch inhaltlich etwas beizutragen? Die alte Version hat nahezu alle Asteroidenartikel in Wartungslisten "Fehler 1" bzw. "Fehler 2" eingetragen. Welcher Fehler denn? --mfb (Diskussion) 15:44, 13. Nov. 2014 (CET)

Habe ich gesagt, dass die aktuelle Version die einzig seeligmachende sei? Ich habe das nicht so programmiert und hänge auch nicht dran. Die Semantik dahinter ist (war) offenbar, dass davon ausgegangen wird, dass Objekte mit Nummer unter 10000 öfter mal eine Zahl verpasst kriegen. Sicher ist jedoch, dass "SSID ist keine Zahl" *kein* Wartungsgrund ist. -- Tent*nerveç (Diskussion) 15:52, 13. Nov. 2014 (CET)

Die alte Version hat absolut keinen Nutzen und schadet sogar. Sie füllt Spezial:Gewünschte Seiten mit zwei Wartungslisten "Fehler 1" und "Fehler 2", bei denen aber kein Fehler ist. "SSD_ID keine Zahl" kann sinnvoll sein (diese Artikel erkennt man aber an ihrem Lemma), kann aber auch ein Fehler sein (wahrscheinlicher als bei Zahlen). --mfb (Diskussion) 13:40, 14. Nov. 2014 (CET)

Orbittyp

Ist es erwünscht, die Abkürzung für den Orbittyp durch eine händische Bezeichnung zu ersetzen? Siehe (2026) Cottrell, (2023) Asaph, (2022) West, (2014) Vasilevksis und (2028) Janequeo --SteEis. (Diskussion | Bewertung | Beiträge) 09:37, 7. Jan. 2014 (CET)

Das ist eine Eigenmächtigkeit vom Schweizer Astronomen, welcher den Astronomiebereich seit ein paar Jahren gängelt. Hier geht es um die Differenzierung zwischen innerem, mittlerem und äußerem Asteroidengürtel. Sie wird von der genannten seriösen Quelle (JPL Small-Body Database Browser) verwendet und unser Schweizer Astronom mag sie nicht. Sein Verhaltensmuster lässt die Vermutung zu, dass er damit in der Minderheit ist. Es geht darum, dass die Quelle auch Asteroiden, welche z.B. zwar den größten Teil, nicht jedoch den ganzen Orbit im äußeren Bereich haben, als "outer mainbelt asteroid" bezeichnet, unser Schweizer Astronom würde dem - wenn überhaupt - nur bei Asteroiden, welche den Orbit ganz im Außenbereich haben, zustimmen. ÅñŧóñŜûŝî (Ð) 23:49, 8. Jan. 2014 (CET)

Im JPL Small-Body Database Browser ist Classification: Main-belt Asteroid angegeben. Wo siehst Du Inner Main-belt Asteroid? -- Hans Koberger 08:37, 9. Jan. 2014 (CET)

Sorry, ich habe mich vertan. Es steht unter JPL Small-Body Database Search Engine, wo man Queries fragen kann. Die Eigenschaft lautet "orbit classification" oder "Asteroid Orbit Classes". ÅñŧóñŜûŝî (Ð) 20:45, 9. Jan. 2014 (CET)

Das heißt, dass in keiner der im Artikel angegebenen Quellen der Orbittyp Inner Main-belt Asteroid genannt wird. Die JPL Small-Body Database Search Engine definiert zudem Inner Main-belt Asteroids mit 1.666–2.0 AU. Bei uns (in der Vorlagenbeschreibung) wird der Bereich 0–2.50 angegeben. Daher findet die JPL Small-Body Database Search Engine (2026) Cottrell auch nicht, wenn man die Option Inner Main-belt Asteroid wählt. Eine Teilung des Hauptgürtels in Bereiche, die in Literatur und Wissenschaft nicht einheitlich und durchgängig definiert sind, ist daher wohl kaum sinnvoll. -- Hans Koberger 23:47, 9. Jan. 2014 (CET)

Siehe dazu: Kirkwoodlücke: 3:1-Resonanz (Hestia-Lücke): Sie liegt bei 2,50 AE und bildet die Grenze zwischen innerem und äußeren Hauptgürtel.; 5:2-Resonanz: Sie liegt bei 2,82 AE und begrenzt die Koronis-Asteroidengruppe nach innen. (nicht signierter Beitrag von SteEis. (Diskussion | Beiträge) 09:08, 10. Jan. 2014‎)

Aha. Und inwiefern ist diese Information auf die fragliche Angabe in der Infobox zu übertragen bzw. andersrum: Welche Aussage trägt die Angabe in der Infobox? Das wurde übrigens alles schon mal durchgekaut (zweite Hälfte). Es wäre wirklich toll, wenn nicht jeder einzelne Punkt von dort wiederholt werden müsste und die Fehlinterpretationen von dort hier nicht wiederholt würden. -- 85.5.115.29 09:36, 10. Jan. 2014 (CET)

Ich vermute, dass die allergischen Reaktionen gegen den Schweizer Astronomen darauf beruhen, dass ein Steckenpferd angetastet wird. --Rainald62 (Diskussion) 02:54, 21. Nov. 2017 (CET)

Die Automatik der Vorlage ist verbesserungswürdig: "Asteroidenfamilie unbekannt" ist für \epsilon > 1 unangemessen. --Rainald62 (Diskussion) 02:54, 21. Nov. 2017 (CET)

Peridatum, Periode, Winkelrundungen

Frage 1: Hat es einen bestimmten Grund, daß die Peridatum-Zeile auskommentiert wurde und Periode entgegen der Doku nicht eingebaut ist? (Gerade letzteres wäre bei tagesgenau erfaßten Umlaufzeiten geschickt, da leicht aus der JPL SB-DB zu kopieren. Es bräuchte nur jemanden, der die Berechnung in a, M, d coden kann, ich trau mich da nicht bei.)

Frage 2: Was spricht dagegen, Bahnneigung, Argument des Knotens und Argument der Periapsis genauer als in Zehntelgrad anzugeben, wenn sicher genug bekannt? Zur Zeit umgeht das jeder gesehene Artikel durch die Verwendung von Dezimalkommata, damit die Angabe als Text interpretiert und nicht gerundet wird. Doku sagt hingegen "Reine Dezimalzahl mit Dezimalpunkt ist erwünscht." Runden auf zwei oder drei Stellen? Ich wäre für drei, zumindest bei der Inklination, da stehen jetzt bei vielen Artikeln mehr… Gunslinger ^Klönschnack 14:30, 31. Okt. 2015 (CET)

Zu 1: Peridatum ist seit vier Jahren nicht mehr drin, weil man nicht für mehrere Tausend WP-Artikel über Asteroiden nach jedem Periheldurchgang den neuen letzten Zeitstempel aktualisieren kann. Periode ist nicht nicht mehr drin, weil damit oft eine nicht vorhandene Genauigkeit suggeriert werden kann, wenn man sich nicht an die Angaben der Doku hält. Umrechnen wäre kein Problem.

Zu 2: die Bahnen der Asteroiden werden immer wieder durch andere Körper, besonders durch den Jupiter, gestört. Die Elemente der angegebenen Keplerellipse sind oskulierend, also Näherungen für die Bahn zu einem bestimmten Zeitpunkt. Es ist deshalb nicht sinnvoll, hier in der WP Dezimalstellen anzugeben, welche sich innerhalb von Tagen oder Wochen ständig ändern. Die Angaben in der Box können daher nur relativ grob angegeben werden.

Gruß von ÅñŧóñŜûŝî (Ð) 15:36, 31. Okt. 2015 (CET)

1: OK, Peridatum macht für die sonnennäheren Asteroiden wenig Sinn. Da ich mich eher um die TNOs kümmere, hab' ich da nicht dran gedacht. Wenn man die Periode (womöglich automatisiert?) aus der JPL SB-DB übernimmt, dann natürlich nur solche, bei denen die dort ebenfalls angegebene Fehlerbandbreite (1 Sigma) mit "0." anfängt. Das tut sie bei TNOs z.B. nicht, weswegen ich bei denen auch die Umlaufdauer als Text verwenden würde.

2: Naja, das wird ja schon jetzt dadurch konterkariert, daß die Leute z.T. absurd genaue Angaben mit Dezimalkomma eintragen, woraufhin der Wert nicht mehr als Zahl interpretiert wird, aber was solls…

Danke für die prompte Rückmeldung, Gunslinger ^Klönschnack 20:56, 1. Nov. 2015 (CET)

"Physische" statt "physikalische" Eigenschaften

M.E. muss es "physische" statt "physikalische" Eigenschaften heißen. --BuSchu (Diskussion) 08:50, 12. Nov. 2015 (CET)

Die Eigenschaften sind Thema der Physik, im Gegensatz zur Chemie auf dem Asteroiden beispielsweise. --mfb (Diskussion) 11:28, 12. Nov. 2015 (CET)

Ich weiß nicht, ob du richtig vermutest (bei den Ephemeriden und Veränderlichen heißt es schließlich auch "physische" = körperliche), deine Begründung ist jedenfalls schwach (Gegensatz zwischen Physik und Chemie?? Gegenbsp. Spektralklasse). Hier geht es vielmehr um den Gegensatz zwischen Bahn und Körper des Asteroiden – physisch würde passen. --Rainald62 (Diskussion) 01:55, 21. Nov. 2017 (CET)

Hauptgürtelasteroiden

Wäre es möglich, die folgenden Gruppen unter „Orbittyp“ anzugeben (besser sogar mit Kürzel): Flora-Gruppe, Vesta-Gruppe, Nysa-Gruppe, Eunomia-Gruppe, Gefion-Gruppe, Koronis-Gruppe, Eos-Gruppe, Themis-Gruppe, Hygiea-Gruppe (siehe Asteroidengürtel#Asteroidengruppen im Hauptgürtel)? --SteEis (Diskussion | Bewertung | Beiträge) 17:54, 2. Sep. 2016 (CEST)

Welche Art von Albedo?

Da die Albedo meist mit mehr als einer signifikanten Stelle angegeben ist, ist es nicht egal, ob es sich um die geometrische oder sphärische Albedo handelt. Falls es halbwegs einheitlich ist, könnte das zumindest in der Vorlagenbeschreibung erwähnt sein. Gesehen habe ich schon Angaben mit vier Stellen, obwohl selbst drei ohne weitere Angaben (Wellenlängenbereich, Wichtung, irdische Beobachtungswinkel oder die einer Raumsonde) nicht sinnvoll sind. --Rainald62 (Diskussion) 12:51, 1. Nov. 2016 (CET)

Es dürfte wohl die sphärische Albedo und sehr wahrscheinlich im sichtbaren Licht sein. ÅñŧóñŜûŝî (Ð) 13:10, 1. Nov. 2016 (CET)

Inzwischen habe ich mich selbst schlau gemacht. Im als Default-Quelle angegebenen JPL Small-Body Database Browser steht „geometric albedo“. „Im sichtbaren Licht“ ist nicht nur sehr wahrscheinlich, sondern sicher, allerdings vage. Genauer wäre z.B. „dunkeladaptiert-visuell“, aber das trifft wohl eher selten zu, da in der JPL Small-Body Database als Quelle meist IRAS angegeben ist (Daten von 1983, letzte Datenaufbereitung (V6.0) war 2004). Ich habe noch nicht recherchiert, was das für die spektrale Wichtung bedeutet. --Rainald62 (Diskussion) 14:49, 1. Nov. 2016 (CET)

Ich habe immer noch nicht recherchiert, bloß überlegt (TF): Man kann wohl mit IR-Daten die Albedo schätzen (was von der Insolation absorbiert wird, wird im IR abgestrahlt, Verdampfungsenthalpie vernachlässigt) und braucht dafür nicht einmal die Größe des Objekts zu kennen, aber damit kommt man sicher nicht auf drei Nachkommastellen. Die Doku der Vorlage habe ich an dieser Stelle schon mal korrigiert von "maximal 4" auf "typ. zwei Nachkommastellen". --Rainald62 (Diskussion) 23:47, 1. Nov. 2016 (CET)

Ergänzung von Einheiten bitte vor statt nach einem ref-Tag

... bzw. garnicht, falls die Einheit schon angegeben ist. Solange keine der beiden Verbesserungen des Skripts durchgeführt ist, haben Autoren die Wahl zwischen zwei inakzeptablen Renderings:

• 10^18[2] kg
• 10¹⁸ kg^[2] kg

--Rainald62 (Diskussion) 17:21, 1. Nov. 2016 (CET)

Was möchtest du mitteilen? Fehlt bei deinem Edit am Anfang ein Teil vom geplanten Beitrag? ÅñŧóñŜûŝî (Ð) 18:24, 1. Nov. 2016 (CET)

Ich rate mal: Es ist derzeit schwierig, der Masse eine Quelle zuzuweisen, ohne eine seltsame Formatierung zu bekommen. --mfb (Diskussion) 22:19, 1. Nov. 2016 (CET)

Ach, das ist die Fortsetzung der Titelzeile... Hätte ich gleich draufkommen können. Dann müsste man die Einheit vorziehen. Von

{{#if: {{IstZahl|{{{Masse}}}}} | {{formatnum:{{{Masse}}}}} | {{{Masse}}} }} kg

nach

{{#if: {{IstZahl|{{{Masse}}}}} | {{formatnum:{{{Masse}}}}} | {{{Masse}}} kg}}

Dann sind aber alle Einbindungen, bei denen die Masse nicht als reine Zahl angegeben ist, ggf fehlerhaft. Ich zähle das mal. ÅñŧóñŜûŝî (Ð) 22:43, 1. Nov. 2016 (CET)

Ich verstehe nicht, was dieser Code bewirkt. "IstZahl" scheint mir eine sinnvolle Prüfung, aber ein einfacher Test überzeugt micht nicht: "foo" → "foo kg".

Ich weiß nicht, was Du unter "reine Zahl" verstehst. Falls "Zahl mit Standardunsicherheit" (dafür gibt es verschiedene Formate) nicht darunter fällt, lass das Zählen und verwirf deinen Reparaturvorschlag.

Ich verstehe auch nicht, inwiefern das intendierte Verhalten eine Hilfe für Autoren sein soll: Die Einheit selbst hinzuschreiben ist leichter als sich zu merken (oder per Vorschau herauszufinden), in welchen Feldern die Einheit angegeben werden muss bzw. nicht angegeben werden darf. Die robusteste Lösung wäre, den 'Automatismus' nach dem Motto „Keep it simple, stupid!“ ganz abzuschaffen. --Rainald62 (Diskussion) 23:18, 1. Nov. 2016 (CET)

Es gibt mehr als 5000 Einbindungen. Wie willst du die alle korrigieren? Evtl. könnte der Bot von Benutzer:Cactus26 mit den Skripten "WikiBotGetTplPrm" und "WikiBotSetTplPrm" weiterhelfen. Damit kann man in einer Tabelle arbeiten. ÅñŧóñŜûŝî (Ð) 00:07, 2. Nov. 2016 (CET)

Wer das Problem verursacht hat, mache sich bitte an die Arbeit. --Rainald62 (Diskussion) 21:02, 11. Nov. 2016 (CET)

"kg" wird seit der ersten Version 2004 automatisch dazugeschrieben. --mfb (Diskussion) 21:56, 11. Nov. 2016 (CET)

Damals waren wir noch nicht so erfahren, den Refs einen eigenen Parameter zu geben. Der Aufwand, das jetzt zu korrigieren, ist recht groß und es ist nur ein Schönheitsfehler. Ich finde, es lohnt sich nicht. ÅñŧóñŜûŝî (Ð) 10:44, 12. Nov. 2016 (CET)

(Halb-)Automatisches Auslesen und Einfügen aus dem JPL Small-Body Database Browser

Die Anzahl der astronomischen Objekte in unserem Universum fasziniert mich und ich bin gespannt wie viel da noch in meiner Lebzeit entdeckt wird. Nur ist mir auch klar, dass es der Wikipedia mit menschlichem Fleiß alleine nicht gelingen wird überhaupt nur einen Bruchteil dieser zu erfassen. Und ja, primärer Anspruch der Wikipedia ist nicht die Vollständigkeit der Artikel, aber trotzdem sind viele Artikel gleich aufgebaut und haben neben der Infobox, Einleitung und sonstigen Standardvorschriften wenig Inhalt. Zudem gestaltet sich die manuelle Erstellung von Infobox anhand der standardisierten JPL Daten mühselig und monoton und ist womöglich auch vom Menschen fehlerintensiver (zu mindestens was die Form angeht), als wenn dies ein Skript übernehmen würde. Auch im Punkto Aktualität würde eine geskriptete Infobox mehr Vorteile bieten. Selbstverständlich sollte so ein Skript nur vertrauliche Daten aus der Datenbank entnehmen und der Rest des Artikels sollte auch weiter von Menschen geschrieben werden, bzw. andere Quellen sollten auch ergänzt werden können, da sonst die Qualität leidet, Wikipedia kein bloßes Plagiat ("mit deutscher Übersetzung") sein soll und so ein Skript ja nicht zum Lsjbot werden soll:D.

Habe auch selber ein bisschen rumprobiert aber nachdem ich bei den Implemntierungsversuchen gescheitert bin und nur ein paar Sachen in Excel/Word hinbekommen habe, habe ich aufgeben. So oder so wäre es für den Autonormal-User zu kompliziert, aufwendig und der Einsatz würde sich einfach nicht lohnen (copy and paste ist einfacher und nicht viel langsamer). Deswegen will ich hier erstmal schauen wie man überhaupt dazu steht und vielleicht findet sich ja der ein oder andere, der sich sehr gut mit der Wikipedia Technik und praktischen Webentwicklung auskennt.

So stelle ich mir eine mögliche Funktionsweise vor:

1. Es gibt eine Seite wo der Benutzer den Link oder die ID einträgt
2. API Daten von dem Asteroid werden abgerufen vgl. https://api.nasa.gov/api.html#neows-lookup (API-Seite der NASA. Man muss sich mit seinem Namen und Email für einen API-Schlüssel anmelden)
3. Die für die Infobox relevanten Werte werden in Variablen geschrieben. Ein Beispiel für einen solchen Wert wäre z. B. "name" : "(2010 PK9)", ;welcher den Namen von dem Asteroid anzeigt
4. Die Variablen werden in die Felder der Infobox eingesetzt.
5. Übersetzung und Fehlerkorrektur durch standartisierte Abfragen (Komma, Formatierung, Rundung usw.)
6. Code kann kopiert werden und manuell weiter bearbeitet werden

Wie gesagt soll nur ein Vorschlag von mir sein, denn ich hier mal reinwerfe:D --Noobius2 (Diskussion) 21:20, 7. Feb. 2017 (CET)

Hallo Noobius2. Dies ist sicherlich alles möglich. Und wahrscheinlich noch sinnvoller, dies alles über Wikidata zu machen, damit es in allen Sprachversionen der Wikipedia übernommen werden kann und aktuell ist. Es hätte aber einen großen Nachteil. Jede manuelle Änderung in der Wikipedia würde beim nächsten Botlauf, also wahrscheinlich schon ein paar Stunden später, von einem Bot überschrieben und wieder zurückgesetzt werden. Und das ist ja nicht der Sinn der Wikipedia. --Gereon K. (Diskussion) 09:01, 8. Feb. 2017 (CET)

Ja stimmt, das wäre zugegebenermaßen ein deutliches Problem. Aber wie sieht es denn mit einer bloßen statischen Code-Generierung, der dann nur einmalig kopiert werden kann, aus? Wie gesagt, ich meine keinen Wikipedia:Bot, sondern ein Skript für Seitenersteller, welches einmalig den Code generiert. Sollte dieser Prozess allerdings dynamisch sein wäre der Einbezug der Wikidata eine Möglichkeit, aber ich halte dies auch aufgrund der entstehenden angesprochen Editkonflikte für schwer umsetzbar. Ein Mittelweg wäre das statisch zu lassen, was sich sowieso nicht ändert (und was natürlich von den Wikipedianern bearbeitet werden kann) und nur dynamische Werte von einem Bot zu ändern (falls möglich auch über die Wikidata). Aber das ist dann die Aufgabe eines weiteren Bots und nicht mehr des Erstellungsskriptes--Noobius2 (Diskussion) 13:20, 8. Feb. 2017 (CET)

Man könnte auch die meisten numerischen Daten der Infobox in Vorlagen packen, dann müsste nur für alle Artikel die Vorlage aktualisiert werden. Das Problem dabei ist, dass Artikel mit sehr vielen eingebauten Vorlagen für langsamere Rechner schwierig zu laden sind. --Gereon K. (Diskussion) 18:54, 8. Feb. 2017 (CET)

Deswegen auch ein externes Skript, das keine neue Vorlage erstellt, sondern nur die Daten in die alte einfügt und eine Kopiervorlage für Seitenersteller bereitstellt (mittels ID/Link-Eingabe in einem Eingabefeld und Ausführen-Button). Die Vorlage selbst, in ihrer Struktur verändert sich hierbei nicht. Von der Rechenleistung sollte das aber machbar sein (vllt müsste man vorher unrelevante Daten rausfiltern usw.). Performanceeinbüßungen (man bedenke Wiki soll für jeden zugänglich sein) und Vorlagenüberflutung brauch man hier aber wirklich nicht, dass stimmt.--Noobius2 (Diskussion) 19:36, 8. Feb. 2017 (CET)

Automatische Kategorisierung 1

Wäre eine automatische Kategorisierung von Asteroiden anhand des Durchmessers möglich (z.B. in die Kategorien Hauptgürtelasteroid über 200 km Durchmesser‎, Hauptgürtelasteroid zwischen 100 und 200 km Durchmesser‎‎, Hauptgürtelasteroid zwischen 50 und 100 km Durchmesser‎ und Hauptgürtelasteroid unter 50 km Durchmesser‎)? --SteEis (Diskussion | Bewertung | Beiträge) 21:55, 24. Okt. 2017 (CEST)

Die Größe eines Asteroiden wird längst nicht immer als reine Zahl angegeben, sondern oft mit "ca." oder mit dem Parameter "Abmessungen". Man müsste die Kategorie also sehr oft sowieso manuell angeben. Insoweit ist das nicht so nützlich wie es wünschenswert wäre. Darüber hinaus sind hunderte von Artikeln bereits einsortiert, was man nicht mutwillig weglöschen sollte. ÅñŧóñŜûŝî (Ð) 22:25, 24. Okt. 2017 (CEST)

Mit einem Bot wäre es vielleicht möglich, zusätzliche Angaben wie z.B. „ca.“ oder „ungefähr“ in ein separates Feld (z.B. „Durchmesser_Anm“) zu verschieben. --SteEis (Diskussion | Bewertung | Beiträge) 19:55, 25. Okt. 2017 (CEST)

Diese Vorlage hat schon viele Parameter. Für dieses Feature einen weiteren anzulegen macht die Einbindung noch aufwändiger. Klar wäre ein Automatismus praktisch, aber die meisten Artikel haben die Kategorie bereits manuell drin. So viele neue Asteroidenartikel pro Jahr wird es wohl nicht mehr geben, dass es sich lohnt. Das ist m. E. schon zu weit fortgeschritten. ÅñŧóñŜûŝî (Ð) 21:25, 25. Okt. 2017 (CEST)

Es würde sich unter Umständen lohnen, wenn Überkategorien (z.B. Kategorie:Asteroid unter 50 km Durchmesser) angelegt werden würden, in denen auch Nicht-Hauptgürtelasteroiden einsortiert würden. --SteEis (Diskussion | Bewertung | Beiträge) 21:30, 25. Okt. 2017 (CEST)

Potential für neue Artikel wäre genug vorhanden. Das WikiProjekt Himmelskörper listet zurzeit bereits über 60.000 fehlende Artikel (davon nur ca. 3700 keine Asteroiden). --SteEis (Diskussion | Bewertung | Beiträge) 11:23, 28. Okt. 2017 (CEST)

Familie: unbekannt

Die automatische Vergabe von „Familie: unbekannt“, wenn nicht explizit eine Asteroidenfamilie angegeben wird, halte ich wie Rainald62 für äußerst unglücklich. Da diese Seite nur wenig beobachtet wird, habe ich den Punkt auf Asteroidenfamilie in der Vorlage:Infobox Asteroid angesprochen. --CorrectHorseBatteryStaple (Diskussion) 15:33, 23. Nov. 2017 (CET)

Wurde heute erledigt. Details dazu werden in wenigen Tage zu finden sein auf: Portal_Diskussion:Astronomie/Archiv/2018#Fehlende_Angabe_Asteroidenfamilie -- Wassermaus (Diskussion) 15:38, 25. Sep. 2018 (CEST)

Was vielleicht Sinn machen würde, ist eine versteckte Wartungskategorie, wenn keine Asteroidenfamilie bekannt ist. --SteEis (Diskussion | Bewertung | Beiträge) 21:43, 29. Jul. 2019 (CEST)

Neuer Parameter "Fallbeschleunigung"?

Angesichts der Tatsache, dass auf Eros, Itokawa und Ryugu bereits Sonden gelandet sind: wäre es sinnvoll, einen Parameter für die Fallbeschleunigung (Gravitation) auf der Oberfläche (in m/s²) als neuen, optionalen Parameter einzubauen? -- Gruß von der Wassermaus (Diskussion) 23:52, 23. Sep. 2018 (CEST)

Eher nicht, da zumindest bei den genannten Beispielen das Gravitationsfeld deutlich von der Kugelform abweicht. Bei sehr vielen anderen Asteroiden ist das ebenfalls so. Wenn überhaupt, müsste der Parameter "mittlere Fallbescheinigung" oder so ähnlich heißen. --CorrectHorseBatteryStaple (Diskussion) 01:11, 24. Sep. 2018 (CEST)

Bei den wenigen Asteroiden, für die der Wert bekannt ist, lohnt das kaum. Kann man ebenso im Fließtext erwähnen, wo es bekannt ist. --seismos (Diskussion) 10:41, 24. Sep. 2018 (CEST)

Hört sich beides sehr valide an. Ich ziehe meinen Vorschlag zurück! -- Wassermaus (Diskussion) 15:35, 25. Sep. 2018 (CEST)

Fehler mit SSD_ID

Kann sich jemand bitte diesen Edit anschauen. Passt nicht ganz zur Beschreibung des Parameters SSD_ID: (es geht mit Leerzeichen und ohne Leerzeichen – also z. B. „2003UB313“ oder „2003 UB313“). ganz offensichtlich geht es ja nicht. Entweder ist hier die Beschreibung falsch oder die Implementierung. lg --Herzi Pinki (Diskussion) 04:24, 27. Okt. 2018 (CEST)

Mein Test ergibt, dass bei Ddirekteingabe in der Adreszeile des Browsers mit "2003UB313", "2003%20UB313" und "2003 UB313" funktioniert, als Parameter aber nur "2003UB313" und "2003%20UB313", weil der WP-Parser das Leerzeichen als Endzeichen der URL interpretiert. ÅñŧóñŜûŝî (Ð) 15:03, 28. Okt. 2018 (CET)

Danke, sag ich doch. Ich habe aber um Änderung der Implementierung / Dokumentation gebeten. lg --Herzi Pinki (Diskussion) 20:44, 28. Okt. 2018 (CET)

Automatische Zuordnung von Kategorien

Es gibt offensichtlich einen Automatismus, der zu Asteroiden-Artikeln automatisch Kategorien von Asteroiden-Familien hinzufügt. Woher bezieht dieser Automatismus seine Informationen? Sollte die Datenquelle nicht unter der Infobox angegeben werden? Im Moment steht da nur der Hinweis auf den JPL Small-Body Database Browser, aber dort finde ich die Familien-Zugehörigkeit nicht. Für mich sieht das im Moment wie eine völlig unbelegte Information aus.--Waldmaus (Diskussion) 15:27, 8. Jan. 2019 (CET)

Das war mal etwas ausführlicher D-Thema (entweder hier oder im Portal). Ich versuche mal, das herauszusuchen. ÅñŧóñŜûŝî (Ð) 19:33, 8. Jan. 2019 (CET)

@Waldmaus: hier ist eine Diskussion zu finden. die Weblinks stimmen aber nicht mehr. Ich habe diese Liste aber gefunden (Textdatei, 12,7 MB, der Server ist extrem langsam). ÅñŧóñŜûŝî (Ð) 20:11, 8. Jan. 2019 (CET)

Also wenn die Familienzugehörigkeit automatisch aus der AstDyS-2-Datenbank bestimmt wird (ob das zutrifft kann ich nicht beurteilen), dann sollte meiner Meinung nach unter der Infobox ein Hinweis auf diese Quelle angegeben werden. Ich möchte das aber nicht selber machen, weil ich mich mit Vorlagen nicht auskenne. Dass man die Familienzugehörigkeit in dieser Datenbank finden kann, das habe ich überprüft, siehe [[1]].--Waldmaus (Diskussion) 20:33, 8. Jan. 2019 (CET)

Wo findet man denn den Code für diesen Automatismus? Ich möchte nur mal reinschauen welche Datenquelle(n) er verwendet.--Waldmaus (Diskussion) 21:07, 8. Jan. 2019 (CET)

Soweit ich weis, ist das kein simpler Vorgang und vermutlich auch nur teilw. automatisiert. ÅñŧóñŜûŝî (Ð) 21:09, 8. Jan. 2019 (CET)

Ich habe einen Asteroiden-Artikel neu angelegt und die Familien-Kategorie wurde sofort automatisch hinzugefügt, ohne mein Zutun. Das hat mich ziemlich verwirrt, dass im Artikel plötzlich etwas drinstand, was ich gar nicht reingeschrieben hatte.--Waldmaus (Diskussion) 21:17, 8. Jan. 2019 (CET)

Automatische Kategorisierung 2

Wären vielleicht automatische Kategorisierung bei folgenden Eingaben sinnvoll?

1. Entdecker (siehe Beispiel auf en)
2. Ort der Entdeckung (am besten die Nummer laut Liste der Sternwarten-Codes in der Infobox einzugeben)
3. Größe (da wäre ein zusätzliches Feld für Sigma und das automatische Anfügen von „km“ vonnöten).

--SteEis (Diskussion | Bewertung | Beiträge) 20:59, 5. Aug. 2019 (CEST)

Was es die Größe angeht, könnte man das wohl machen. Die anderen Parameter sind. m. E. aber nur sehr bedingt "kategorietauglich". Es gibt hunderte verschiedene Entdecker und ebenso zahlreich sind wohl die Orte der Entdeckung. Das ergäbe also viele Kategorien mit zumeist weniger als zehn Einträgen. Das ist kein erstrebenswertes Ziel. ÅñŧóñŜûŝî (Ð) 21:50, 5. Aug. 2019 (CEST)

Man könnte das vielleicht auf Entdecker begrenzen, die mindestens eine gewisse Anzahl entdeckt haben. (siehe en). Bei Entdeckungsorten wird es wahrscheinlich wenig Orte mit so wenig Entdeckungen geben, dass eine Kategorie nicht angebracht wäre.--SteEis (Diskussion | Bewertung | Beiträge) 22:13, 5. Aug. 2019 (CEST)

Für die Größe würde man zuerst ein Feld erstellen (z.B. Durchmesser_Sigma) und dann einen Bot benötigen, der:

die übliche Darstellung: | Durchmesser = 4,408 ±0,061 km auf

diese zwei Felder ändert: | Durchmesser = 4,408 / | Durchmesser_Sigma = 0,061

± vor Sigma sowie km zum Schluss müssten dann von der Vorlage angefügt werden. --SteEis (Diskussion | Bewertung | Beiträge) 10:27, 21. Aug. 2019 (CEST)

Das ist viel Aufwand. Das lohnt sich zumindest in dieser Form nicht. Da lohnt es sich schon eher, die Werte komplett auszulagern, und zwar innerhalb von de:WP, denn Wikidata ist bei sowas unbrauchbar. Damit kann man dann jede Menge Features kreieren. ÅñŧóñŜûŝî (Ð) 10:47, 21. Aug. 2019 (CEST)

Vor allem die Kategorie:Hauptgürtelasteroid unter 50 km Durchmesser hat jetzt die 5.000-Artikel-Grenze überschritten und bei einer automatischen Kategorisierung würden auch die anderen Asteroiden nach Größe kategorisiert werden. --SteEis (Diskussion | Bewertung | Beiträge) 11:01, 21. Aug. 2019 (CEST)

Wenn wir hier umkrempeln, dann muss die Box mit einem kopierten Ergebnis aus der JPL Small-Body Database Search Engine arbeiten. Nur auf diese Weise sind die Daten zu pflegen, denn die oskulierenden Werte sind ja nicht statisch fest. ÅñŧóñŜûŝî (Ð) 11:28, 21. Aug. 2019 (CEST)

@Antonsusi: Eine Kategorisierung für Entdecker kann man auch händisch machen, halt nur Personen, die mindestens eine gewisse Anzahl entdeckt haben. Bei Personen wie Nikolai Stepanowitsch Tschernych (537 Asteroiden laut en:List of minor planet discoverers) zum Beispiel würde sich das durchaus auszahlen. --SteEis (Diskussion | Bewertung | Beiträge) 23:28, 11. Sep. 2019 (CEST)

Für die Entdecker und das Datum gibt es bereits eine Liste im Web. Das kann man auch automatisieren. ÅñŧóñŜûŝî (Ð) 00:23, 12. Sep. 2019 (CEST)

Könnte man nicht gleich alle Daten aus der Infobox automatisch übernehmen? --SteEis (Diskussion | Bewertung | Beiträge) 08:37, 2. Okt. 2019 (CEST)

Du meinst, „herauslesen“ aus dem Web? Das dürfte aus Sicherheitsgründen nicht funktionieren. Man kann aber Daten per Hand als Plaintext hierherkopieren. Damit lässt sich dann mittels Lua eine Infobox füllen. Damit wären alle (!) Asteroidenartikel auf einen Schlag aktualisiert. Das einzurichten ist schon etwas mehr Arbeit. Ich würde es machen, wenn es genug Zustimmung gibt, insbesondere, dass wir uns nicht auf Wikidata stützen, denn da haben zu viele Vandalen Zugriff. ÅñŧóñŜûŝî (Ð) 21:43, 2. Okt. 2019 (CEST)

Wäre das rein theoretisch nicht möglich, die Daten direkt von JPL abzufragen, sofern die Betreiber von JPL nichts dagegen haben? --SteEis (Diskussion | Bewertung | Beiträge) 19:45, 12. Sep. 2020 (CEST)

Ich würde das großartig finden, wenn du das machen würdest. --SteEis (Diskussion | Bewertung | Beiträge) 15:27, 3. Okt. 2019 (CEST)

Dann werde ich mal offline anfangen. Mal schauen, wie die große Datenmenge schnell verarbeitet werden kann. ÅñŧóñŜûŝî (Ð) 17:08, 3. Okt. 2019 (CEST)

@Antonsusi: Hast du schon eine Möglichkeit gefunden? --SteEis (Diskussion | Bewertung | Beiträge) 16:28, 31. Aug. 2020 (CEST)

Ich suche noch nach dem richtigen Verfahren, die Rohdaten auszulesen, ohne dass es Minutenlang dauert... ÅñŧóñŜûŝî (Ð) 19:37, 31. Aug. 2020 (CEST)

Was man wahrscheinlich jetzt schon machen könnte: Eine automatische Kategorisierung der Asteroiden durch den Orbittyp-Kürzel. Wäre das gewünscht? --SteEis (Diskussion | Bewertung | Beiträge) 19:34, 8. Sep. 2020 (CEST)

Ich habe nichts dagegen. ÅñŧóñŜûŝî (Ð) 21:41, 12. Sep. 2020 (CEST)

Der erste Versuch ist bereits erfolgreich. Bezüglich Durchmesser: Könnte man den Durchmesser bereits jetzt aus der AstDyS-2 Datenbank importieren, wie die Familie? --SteEis (Diskussion | Bewertung | Beiträge) 21:43, 12. Sep. 2020 (CEST)

Diese Datenbank würde ich nicht empfehlen. Da ist der JPL Small-Body Database Browser besser. Die "Familien" sind dort - weil nicht besonders anerkannt - allerdings nicht drin. ÅñŧóñŜûŝî (Ð) 22:51, 12. Sep. 2020 (CEST)

Gibt es dort eine Liste mit allen Asteroiden-Durchmessern, die man verwenden könnte? --SteEis (Diskussion | Bewertung | Beiträge) 14:56, 13. Sep. 2020 (CEST)

Es gibt noch die dazugehörige Suchmaschine. ÅñŧóñŜûŝî (Ð) 17:34, 14. Sep. 2020 (CEST)

Danke dir für den Link, das Suchfeld habe ich bei meinem neuen Artikel (3148) Grechko schon verwendet (in der Einleitung). --SteEis (Diskussion | Bewertung | Beiträge) 19:02, 14. Sep. 2020 (CEST)

Durchmesser

Ich habe jetzt auf JPL nach dem Durchmesser gesucht. Hier die Asteroiden mit dem Durchmesser (fürs erste nur Hauptgürtelasteroiden, da momentan ja nur sie nach Durchmesser kategorisiert werden):

• <5 km = 91.919 Asteroiden
  • <1 km = 56 Asteroiden
  • >=1<2 km = 12.300 Asteroiden
  • >=2<3 km = 28.517 Asteroiden
  • >=3<4 km = 29.036 Asteroiden
  • >=4<5 km = 22.040 Asteroiden
• >=5<10 km = 36.101 Asteroiden
  • >=5<6 km = 14.865 Asteroiden
  • >=6<7 km = 9.380 Asteroiden
  • >=7<8 km = 5.861 Asteroiden
  • >=8<9 km = 3.578 Asteroiden
  • >=9<10 km = 2.417 Asteroiden
• >=10<15 km = 4.867 Asteroiden
  • >=10<11 km = 1.645 Asteroiden
  • >=11<12 km = 1.233 Asteroiden
  • >=12<13 km = 844 Asteroiden
  • >=13<14 km = 641 Asteroiden
  • >=14<15 km = 464 Asteroiden
• >=15<20 km = 1.387 Asteroiden
• >=20<25 km = 582 Asteroiden
• >=25<30 km = 323 Asteroiden
• >=30<35 km = 189 Asteroiden
• >=35<40 km = 158 Asteroiden
• >=40<45 km = 100 Asteroiden
• >=45<50 km = 83 Asteroiden

--SteEis (Diskussion | Bewertung | Beiträge) 20:19, 17. Sep. 2020 (CEST)

@Antonsusi: Auf Benutzer:SteEis/kleiner2km habe ich die ID aller nummerierten Hauptgürtelasteroiden (9928 Asteroiden) unter 2 km Durchmesser aufgelistet. Ich kenne mich mit Vorlagenprogrammierung leider nicht so gut aus. Schaffst du es, mit dieser Auflistung eine automatische Kategorisierung für eine Kategorie Kategorie:Hauptgürtelasteroid unter 2 km Durchmesser einzubauen, oder soll ich die Auflistung anders gestalten? --SteEis (Diskussion | Bewertung | Beiträge) 18:18, 20. Sep. 2020 (CEST)

Wir brauchen da eine generelle Lösung mit allen Daten. Insoweit brauchst du nicht ins Datensammeln einzusteigen, denn das wäre ggf. in den Sand gesetzte Arbeit. Ich arbeite an einer entsprechenden größeren Lösung. Kategorisierungen per Vorlage sind davon aber nicht betroffen. ÅñŧóñŜûŝî (Ð) 18:24, 20. Sep. 2020 (CEST)

Nicht existierende Vorlageneinbindung

Bei den von mir erstellten höhernummerierten Asteroiden und auch von (541132) Leleākūhonua wird die Vorlage:Infobox Asteroid/Familie/54 eingebunden (siehe die Linkliste. Woher kommt diese Einbindung? --SteEis (Diskussion | Bewertung | Beiträge) 15:27, 6. Sep. 2020 (CEST)

Das liegt an der nicht ausgereiften Syntax zur ermittlung der Asteroidenfamilie. Das muss generell überarbeitet werden. Weil das aber nur bei der Vorschau als Totlink auftaucht, ist das m. E. nicht so dringend. ÅñŧóñŜûŝî (Ð) 18:46, 6. Sep. 2020 (CEST)

Danebengegangen

Mir ist bei meinen letzten Änderungen (automatische Kategorisierung beim Feld Tholen hinzufügen) etwas danebengegangen. In Artikeln wird jetzt immer „{{#if:||“ angezeigt. Könnte das bitte wer richten? --SteEis (Diskussion | Bewertung | Beiträge) 21:18, 15. Sep. 2020 (CEST)

Danke an @Mielas:, jetzt funktionierts! --SteEis (Diskussion | Bewertung | Beiträge) 21:47, 15. Sep. 2020 (CEST)

Fehlerhafte Darstellung der round-Funktion korrigiert

Ich hatte das schon zweimal in der Vorlagenwerkstatt moniert: Durch die Verwendung der round-Funktion werden hinter dem Komma rechtsseitige Nullen unterdrückt, was mathematisch falsch ist. Beispiel des bisherigen Zustands:

Eingabe im Artikeltext "Exzentrizität = 0.1212" Angezeigt wird "Exzentrizität = 0,121". Korrekt bei drei Nachkommastellen.

Eingabe im Artikeltext "Exzentrizität = 0.1202" Angezeigt wird "Exzentrizität = 0,12". Falsch, richtig bei drei Nachkommastellen wäre "Exzentrizität = 0,120".

Nachdem sich in der Vorlagenwerkstatt keiner zuständig fand, der das korrigieren wollte, habe ich es eben selbst gemacht. Danke nochmal für die tolle Unterstützung! Und wie man sehen kann, muss man die Eingaben nicht "als Zeichenketten handhaben", man muss es eben nur geschickt für die Ausgabe programmieren.

Die Vorlage ist hinsichtlich der durchgeführten Änderungen intensiv getestet und funktioniert jetzt wunschgemäß ohne Unterdrückung der rechtsseitigen Nullen nach dem Komma. Viele Grüße, --Ayyur (Diskussion) 16:23, 22. Mär. 2021 (CET)

Das habe ich gleich mal revertiert, denn sowas gehört in eine eigene Vorlage und nicht mitten in die Box. Insbesondere ist das ein Fall für die Umsetzung mit Lua-Code. Dieses Thema taucht ja auch an vielen Stellen auf. Es ist übrigens immer ein String, der dargestellt wird. ÅñŧóñŜûŝî (Ð) 19:21, 22. Mär. 2021 (CET)

Ich habe immer mehr den Eindruck, das hier überhaupt nicht verstanden wird, um was es geht. Das ist echt schön, wenn man sich erst in diese Programmierung reinarbeitet und aufwendige und sinnvolle(!) Arbeit in Programmierung und Testen reinsteckt, und das dann mit dünnen Argumenten abgebügelt und ohne wirklichen Grund in die Tonne getreten wird. Es funktionierte doch! - kein Anlass, das gleich pauschal zu revertieren. Soll hier der Parser geschont werden, weil der Arme sonst überlastet ist? Optimieren durch Auslagerungen kann man es auch noch im Nachgang. Oder soll hier Selbstgerechtigkeit und private Willkür durchgesetzt werden? Ganz toll, das motiviert doch ungemein für eine anspruchsvolle Mitarbeit bei WP! Gibt es hier eigentlich auch Preise zu gewinnen für die "Demotivation zur Mitarbeit"? Ich könnte da inzwischen einige Top-Kandidaten vorschlagen.

Wo ist denn die Grenze, was "in die Box gehört"? Gehört da eine Berechnung der Apsiden oder der Mittl. Umlaufgeschwindigkeit rein? Wenn ja, dann gehört da auch eine vernünftige Ausgabeformatierung rein. Programmieren hört nicht beim Berechnen auf, da gehört auch eine mathematisch korrekte Ausgabeformatierung dazu, sonst kann man als Programmierer gleich nach Hause gehen. Was für ein Versagen, wenn eine auf drei Nachkommastellen gerundete Zahl als 0,12 dargestellt wird (siehe Beispiel oben). Dass diese WP-Vorlagenprogrammierung so eine primitive Programmiersprache ist, dafür kann ich nichts, aber wenn man das notgedrungen kompensieren will, wird es eben im Detail auch mal aufwendig. Wie es in WP-Vorlagenprogrammierung für die korrekte Ausgabe gerundeter Werte geht, habe ich ja jetzt vorgemacht, und da bin ich stolz drauf, denn sonst kann es ja anscheinend niemand! Aber sich bequem in die Passivität zurückziehen und schnell mal zu revertieren, weil man sich überfordert oder beschämt dadurch fühlt, ist ja so einfach... Wenn AntonSusi so gut weiß, was hier "insbesondere" zu tun ist, warum macht er es nicht einfach??? Ich habe das mehrmals in der Vorlagenwerkstatt angefragt. Offenbar ist aber niemand in der Lage, das wegen mir in LUA oder sonst irgendeiner Sprache zu programmieren - das ist schon ein Armutszeugnis. Aber wenn man sich dann nach dem Motto "Hilf dir selbst, sonst hilft dir keiner" richtet, wird "gleich mal" revertiert. Das ist so armselig, ich könnte kotzen vor soviel Ignoranz. --Ayyur (Diskussion) 11:10, 23. Mär. 2021 (CET)

Da kann ich Ayyur nur recht geben! Gute Zusammenarbeit sieht anders aus. Das System mit Vorlagen, die nur von Spezialisten gewartet/geändert werden können, wird uns noch mal auf den Kopf fallen! -- Hans Koberger 12:05, 23. Mär. 2021 (CET)

Moment, habe ich das recht verstanden? Ayyur hat die Vorlage so geändert, dass drei signifikante Stellen korrekt angezeigt werden, und Antonsusi hat das “gleich mal wieder revertiert”, damit es wieder falsch angzigt wird? Geht’s noch? — Wassermaus (Diskussion) 15:48, 23. Mär. 2021 (CET)

Er hat meiner Recherche nach dafür gesorgt, dass auch bei "trailing zeroes" drei Nachkommastellen angezeigt werden. Die Umsetzung mit reinem Wiki-Code ist dafür aber ziemlich ungeeignet und löst auch nicht das dahinterliegende generelle Problem mit fehlenden "trailing zeroes". Ergo habe ich das im ersten Schritt revertiert und in einem zweiten durch eine neue Vorlage zur Stringmanipulation ersetzt. Diese belässt beim Runden die zusätzlichen Nullen. Auch wenn es unbescheiden klingen mag: Das Bessere ist der Feind des Guten. Wenn es wirklich um signifikante Stellen gehen soll, so ist das auch besser mit Lua umzusetzen. Dass da Frust aufkommt, wenn ein Arbeitsergebnis nicht von Dauer ist, kann ich nachvollziehen, aber das ist hier in der WP oft so. Jede Artikellöschung befördert ein Ergebnis von Autorentätigkeit ins Daten-Jenseits. Hier in diesem Fall bleibt der Code zumindest mal in der Versionsgeschichte erhalten und zugänglich. Evtl. gibt es ja doch noch eine anderweitige Verwendung. Gruß von ÅñŧóñŜûŝî (Ð) 18:55, 23. Mär. 2021 (CET)

Das Ganze hat trotzdem etwas von einem „Geschmäckle“. Zuerst wurde das so dargestellt, als ob es überhaupt nicht mit vernünftigem Aufwand möglich wäre. Dann habe ich um das Gegenteil zu demonstrieren meine „gute Lösung“ erarbeitet. Dass die optimierbar gewesen war, steht außer Frage, und gegen eine „organische“ Weiterentwicklung eines Artikels oder einer Vorlage hat niemand was. Aber etwas Funktionsfähiges gleich mal zu revertieren, um dann kurz darauf die „bessere Lösung“ aus dem Hut zu zaubern, das ist unterirdisch.

Revertieren ist eine Maßnahme, die man üblicherweise anwendet bei Getrolle, Vandalismus oder Infantilismus. Wenn meine funktionsfähige „gute Lösung“ also als Unsinn dargestellt und gleich mal revertiert wurde, zeigt das nur, mit welcher Achtung man hier behandelt wird! Und kurz darauf die „bessere Lösung“ (die mir übrigens durchaus gefällt, genauso muss es nämlich gemacht werden, wenn man das kann – danach hatte ich ja in der Vorlagenwerkstatt gebeten) nachzuschieben, erweckt den Eindruck, als ob hier ein vermeintlicher Platzhirsch sich ans Bein gepinkelt gefühlt hat. Ich habe kein Problem damit, wenn in meinen Artikeln Fehler verbessert werden oder wenn diese Vorlage weiterentwickelt wird und meine Edits dabei wieder verschwinden. Aber der Ton macht dabei die Musik.

Aber Schwamm darüber, für mich hat sich eine Beteiligung an der WP auf diesem speziellen Gebiet erledigt, denn ich lasse mich bestimmt nicht ein zweites Mal auf eine solche Art zum Deppen abstempeln. Ich werde auf diesem Terrain nicht mehr erscheinen, oder um es mit Ludwig „Lucki“ Hofmaier zu sagen: „I bin rrraus!“ Und tschüss, --Ayyur (Diskussion) 11:32, 24. Mär. 2021 (CET)

Umlaufgeschwindigkeit

Auf Portal_Diskussion:Astronomie#Orbitalgeschwindigkeit wurde darauf hingewiesen, dass z.B. in (3) Juno die Umlaufgeschwindigkeit mit 0,00 km/s ausgegeben wird. Die Berechnung in der Infobox gibt den Standardwert zurück, wie ich durch diese kurzlebige Änderung bestätigt habe. Die Parameter sind alle vorhanden, die Formel gibt von Hand den richtigen Wert, dennoch schlägt die Berechnung in der Vorlage fehl. Sieht jemand warum? --Wrongfilter ... 15:53, 17. Jul. 2021 (CEST)

Oha. Ein Fehler nach so langer Zeit? Merkwürdig. Ich schaue mal danach. Ein Syntaxfehler. Mal schauen, wann er hinein kam und was vorher drin stand. ÅñŧóñŜûŝî (Ð) 22:06, 20. Jul. 2021 (CEST)

@Wrongfilter: Es war der bei sowas stets Verdächtige Vorlage:Smiley/Wartung/facepalm  Ich hatte am 23. März eine Vorlage fehlerhaft eingebaut. Dürfte jetzt stimmen. ÅñŧóñŜûŝî (Ð) 22:22, 20. Jul. 2021 (CEST)

Sieht gut aus! Danke. Kann nicht behaupten, dass ich da durchblicken würde, zu viele geschweifte Klammern ;-). --Wrongfilter ... 22:39, 20. Jul. 2021 (CEST)

@Wrongfilter: Da habe ich eine bestimmte Methode: 1) Zwischen den Mehrfachklammern verschiedener Objekte, also Vorlagen- oder Variablenklammern ein <!-- --> einfügen. Macht man das richtig, verändert sich die Wirkung nicht. 2) Die Verschachtelung der Vorlagenaufrufe durch Zeilenumbrüche und Einrücken verdeutlichen. Umbrüche und Einrückungen dabei auskommentieren. Bis dahin funktioniert alles unverändert. Wenn das nicht hilft, 3) die fragliche Zeichenkette - hier der Inhalt der IB-Tabellenzeile - Im Editorfenster an eine Noinclude-Stelle am Ende kopieren. 4) dort bei allen Variablen die Dreifachklammer durch den reinen Variablennamen ersetzen Spätestens Jetzt kann man sehen, wie die Formel logisch lautet. Hat man das erstmal erkannt, kann man den Originaltext im einzubindenden Teil leicht ändern. Gruß von ÅñŧóñŜûŝî (Ð) 10:43, 21. Jul. 2021 (CEST)

SSD_ID und SSD_TNO

Hallo, versuche mich derzeit am Artikel 2014 PN70. Dabei hab ich festgestellt, dass die Beschreibung der Vorlage hier wohl nicht (mehr) so ganz stimmt. Dort steht, wenn man SSD-TNO mit einem Wert versieht, müsse man bei SSD_ID ein Leerzeichen in der Form "%20" einfügen, also in meinem Fall "2014%20PN70". Dummerweise funktioniert das nicht. Die JPL-Seite meckert das an. Auch die Angabe SSD_ID würde mit und ohne Leerzeichen funktionieren stimmt so nicht. Hab mal verschiedene Fälle durchgetestet:

"SSD_ID = 2014PN70" (ohne SSD_TNO)

Klick auf JPL Small-Body Database zeigt Orbitsimulation und Datenbankeintrag an, Klick auf Animation führt zum gleichen Ergebnis

"SSD_ID = 2014 PN70" (ohne SSD_TNO)

Klick auf JPL Small-Body Database führt zu Fehlverlinkung auf "2014 Vasilevskis (1973 JA)", Fehlermeldung bei bei Klick auf Animation ("BAD character")

"SSD_ID = 2014%20PN70" (ohne SSD_TNO)

JPL Small-Body Database zeigt Orbitsimulation und Datenbankeintrag an, Animation führt zu Fehlermeldung

"SSD_ID = 2014PN70", "SSD_TNO = 1"

Ergebnis wie ohne SSD_TNO

"SSD_ID = 2014 PN70", "SSD_TNO = 1"

JPL Small-Body Database führt zu Fehlverlinkung auf "2014 Vasilevskis (1973 JA)", Animation jedoch zum korrekten Ergebnis (Daten und Simulation)

"SSD_ID = 2014%20PN70" , "SSD_TNO = 1"

Ergebnis wie ohne SSD_TNO

Größendarstellung der Simulation scheint übrigens in allen Fällen (soweit funtionierend) gleich zu sein. Also, auf SSD_TNO pfeifen und SSD_ID grundsätzlich ohne Leerzeichen (in welcher Form auch immer)?

Denke mal, da hat das „unartige“ JPL seine Datenbankschnittstelle doch glatt geändert, ohne uns um Erlaubnis zu fragen. Sowas aber auch! ;-) --Duschgeldrache2 (Diskussion) 20:42, 14. Aug. 2022 (CEST)

SSD_TNO sollte genutzt werden, um beim Deeplink den PHP-Pararameter "&far=1" zu ergänzen. Müsste man mal überprüfen. ÅñŧóñŜûŝî (Ð) 05:51, 15. Aug. 2022 (CEST)

Abweichungen?

Wenn ich z.B. für die Abweichungen: Große_Halbachse_s, Exzentrizität_s usw. in der Vorlage Werte eingebe, passiert garnichts. Müsste da nicht an die jeweiligen Werte irgendwas mit +/- oder so angefügt werden? Auch beim Quelltext der Vorlage sehe ich nicht, dass diese Parameter überhaupt berücksichtigt werden. Wozu sind die dann gut? Nur um zusätzliche Arbeit zu erzeugen? --Allexkoch (Diskussion) 12:33, 10. Sep. 2022 (CEST)

Da stimmt was nicht …

@Antonsusi: Irgendwas stimmt da nicht, in der Infobox ist unten so ein Textblock und hinter dem Text "JPL Small-Body Database" ist ein Link https://ssd.jpl.nasa.gov/tools/sbdb_lookup.html#/?sstr={{{SSD_ID}}}&view=VOSPDCA, dieses {{{SSD_ID}}} ist wohl nicht so ganz richtig. --Wurgl (Diskussion) 07:42, 14. Aug. 2023 (CEST)

Siehe Benutzer:Wurgl/Externe_Links_mit_fehlendem_Parameter --Wurgl (Diskussion) 08:30, 14. Aug. 2023 (CEST)

@Wurgl: Nicht verwunderlich. Wenn der Pflichtparameter "SSD_ID" fehlt, dann kommt es zum URL-Fehler. Das sind ein paar Kopierfehler von mir Vorlage:Smiley/Wartung/facepalm  Einfach ergänzen. Bei nummerierten Asteroiden ist das seine Nummer. ÅñŧóñŜûŝî (Ð) 19:47, 14. Aug. 2023 (CEST)

Durchmesser in der Vorlage

Ich habe aufgrund einer Fehlkategorisierung von Asteroiden, bei denen der Durchmesser mit Messgenauigkeit angegeben wird (s. Spezial:Diff/236186357/236435064), einen Fix in der Vorlage gemacht. Mit dem zusätzlichen (optionalen) Parameter DurchmesserGenauigkeit kann diese jetzt anegegeben werden, ohne dass die Zahlenformatierung oder Kategorisierung zu einem Fehler führt. Doku passe ich noch an. Ich hoffe, der Fix hatte jetzt keine fatalen Nebenwirkungen. Dann gerne revertieren. --Alturand…D 18:32, 15. Aug. 2023 (CEST)

Rotationsperiode

Hallo, @Antonsusi:. Ich weiß nicht, ob Du den Hut aufhast bei dieser Vorlagenprogrammierung, aber ich richte mich mal an Dich - bitte ggf. weiterleiten. Mir gefällt die neue Struktur der Vorlage mit den automatisch berechneten Parametern (Perihel, Aphel, Umlaufgeschwindigkeit usw.) und der Auflösung in größere und kleinere Einheiten (z. B. Jahre und Tage bei der Umlaufperiode) sehr gut. An einer Stelle hätte ich aber noch einen Verbesserungsvorschlag: Bei Rotationsperioden über 24 Stunden wird derzeit eine Ausgabe mit ganzen Tagen und ganzen Stunden gemacht. Das ist OK für mehrere Tage (bei fünfeinhalb Tagen kommt es auf ein paar Minuten nicht an), aber es ist etwas "unscharf" bei Rotationsperioden, die zwischen (sagen wir mal) vollen Tagen und "etwas darunter oder darüber" liegen. Ein Beispiel: Bei (159) Aemilia beträgt die Rotationsperiode 24,476 h, das wird in der Infobox dargestellt als "1 d 0 h". Das ist mathematisch korrekt, aber unbefriedigend. Es ist schon wichtig zu wissen, dass die Rotation des Asteroiden nicht genau synchron zur Erdrotation ist, sondern sich jeden Erdtag um einen gewissen kleinen Betrag verschiebt. Hier sollte etwas nachgebessert werden. Entweder man erweitert das auf "1 d 0,5 h" oder man geht noch eine Ebene tiefer und gibt in solchen Fällen auch noch die Minuten an, also z. B. "1 d 0 h 29 min". Wie gesagt, das sollte (um nicht alles zu sehr aufzublähen) aber nur in Sonderfällen gemacht werden, also z. B. im Bereich zwischen (n x 24) ± 1 h oder (n x 24) ± 2 h oder ... (das kann man noch sinnvoll festlegen). Bitte denke mal darüber nach, wie man das umsetzen könnte und wie das programmiertechnisch lösbar wäre. Viele Grüße, --Ayyur (Diskussion) 15:06, 27. Jul. 2024 (CEST)

Das müsste man im Lua-Modul ändern. Das Problem hierbei ist nicht die Programmierung, sondern die Tatsache, dass man bei mehr als einem Tag in vielen Fällen keinen minutengenauen Wert hat. Wenn du also 3 d 0 h 24 m angibst, dann ist das scheinbar minutengenau, obwohl es u. U. nur auf 6 Minuten (0,1 Std.) genau ist. Man müsste also dezimle Stundenteile angeben, was ich nicht so toll finde. ÅñŧóñŜûŝî (Ð) 19:38, 29. Jul. 2024 (CEST)

Hallo, AntonSusi. Ich verstehe, was Du meinst. Die Schein-Genauigkeit ist in der Tat ein Problem und dezimale Stundenanteile finde ich auch unästhetisch. Aber um das auf belastbare Füße zu stellen, habe ich mal eine kleine Statistik erstellt, um die Relevanz dieses Problems einzuschätzen. Ich habe mal schnell alle meine (etwa 150) Asteroiden-Artikel durchgesehen und das Vorkommen von Rotationsperioden (alles aus der JPL-Datenbank übernommen) hinsichtlich der angegebenen Dezimalstellen ausgewertet. Ich habe dazu zwei Fälle unterschieden:

• Rotationsperioden unter 24 Stunden (wird in der Infobox in allen Fällen minutengenau dargestellt): Das sind etwa 80 % aller von mir beschriebenen Asteroiden. Etwa bei 96 % sind mehr als zwei Dezimalstellen angegeben, das ist genauer als 1 Minute. Aber bei etwa 4 % ist nur eine Dezimalstelle angegeben, das sind (wie Du schon geschrieben hast) 6 Minuten Genauigkeit, und diese Fälle gibt es (mit dieser geringen Häufigkeit) bereits jetzt! Ein Beispiel dafür ist z. B. (1251) Hedera: Rotationsperiode nach JPL 19,9 h, angezeigt wird "19 h 54 min". Da könnte man schon jetzt die Hände heben.
• Rotationsperioden über 24 Stunden (wird in der Infobox bisher stundengenau dargestellt): Das sind nur etwa 20 % aller von mir beschriebenen Asteroiden. Hierunter gibt es etwa 15 % ohne Dezimalstellen, die stellen kein Problem dar. Etwa 2/3 haben zwei oder drei Dezimalstellen, die könnte man problemlos minutengenau angeben. Bleiben knapp 20 % mit nur einer Dezimalstelle (das sind etwa 3,5 % von allen).

Ich weiß nicht, was mit der LUA-Programmierung möglich ist oder welchen Programmieraufwand man da sinnvollerweise treiben will. Vielleicht sollte man in den Fällen, wo bei den JPL-Daten nur genau eine Dezimalstelle angegeben ist, die Ausgabe in der Infobox auf 5 Minuten runden (oder wegen mir auch als Vielfache von 6 Minuten stehenlassen), aber das dann irgendwie kenntlich machen. Vorschlag: In diesen Fällen eine Tilde (~) davorsetzen, oder ein "ca." davorsetzen. Das gilt übrigens auch für die Rotationsperioden <24 Stunden, wie oben beim Beispiel (1251) Hedera. In einen sauren Apfel wird man dabei wohl beißen müssen, und so etwas erscheint mir nicht der schlechteste Ausweg. Aber vielleicht hast Du noch bessere Ideen. Viele Grüße, --Ayyur (Diskussion) 16:33, 30. Jul. 2024 (CEST)

Es gibt leider selten Sigma-Werte, die man ergänzen könnte. Gibt es Werte mit nachgestellten Nullen, also sowas wie "12,30"? Wenn nein, dann könnte "12,3" auch auf zwei Stellen genau, aber nicht angegeben sein. ÅñŧóñŜûŝî (Ð) 07:12, 31. Jul. 2024 (CEST)