Portal Diskussion:Astronomie/Asteroidenbox

Teil 1

Hallo. Mir ist aufgefallen, dass bei diesen Artikeln viele Zahlen manuell gepflegt werden. Es wäre daher wohl besser, die Orbitdaten in eine gemeinsame Vorlage einzutragen und dann für die Infoboxen zu nutzen. Dann kann man sie jederzeit dem Stand der Wissenschaft anpassen, ohne die ganzen Artikel zu ändern. Wäre das nicht viel weniger Arbeit für die Zukunft ? ÅñŧóñŜûŝî (Ð) 19:06, 15. Nov. 2009 (CET)

Auch wenn ich ein gewisses Verständnis für den Vorschlag habe, so wird er dennoch leider nicht umsetzbar sein. Es geht bei Wikipedia darum, Artikel zu schreiben und nicht darum, Datenbanken zu kopieren. Man kann die Daten in den Infoboxen in der Regel (das heisst bei einem Artikel "nach den Regeln der Kunst") nicht ändern, ohne auch den Artikel-Inhalt entsprechend anzupassen (weil die Information auch dort steht). Das würde also so, wie Du das nach meinem Verständnis vorsiehst, nicht funktionieren. Abgesehen davon: Wenn man eine Datenbank will, dann geht man besser gleich zu den einschlägig bekannten Originalen. Vorlagen in Wikipedia sind dafür leider denkbar schlecht geeignet (vielleicht ändert sich das in Zukunft mal). Darüber hinaus würde man es durch die Speicherung der Daten in einer Vorlage einem "normalen" Autor praktisch verunmöglichen, Änderungen an den Daten vorzunehmen. Solche Änderungen sind aber notwendig, weil man die Daten der bekannten Quellen nicht einfach 1:1 übernehmen kann, sondern sie einschätzen, bewerten und entsprechend anpassen muss. Ein einfacher Import der Daten kann das nicht leisten. (Diese Anpassungen sind es übrigens unter anderen auch, die es verhindern sollten, dass die Daten überhaupt häufiger geändert / "dem Stand der Wissenschaft angepasst werden müssen", denn wenn das notwendig ist, hat man ziemlich sicher ganz einfach zu viele Stellen angegeben.) -- CHRV 22:17, 15. Nov. 2009 (CET)

Gegenvorschlag: Man könnte versuchen (vermutlich mit Bot-Hilfe), ein System zu schaffen, das die Wartung erleichtert, indem es gezielt nach möglichen Abweichungen der Daten in den entsprechenden Infoboxen sucht und als Resultat eine Linkliste für die Wartung erzeugt (die dann manuell abgearbeitet werden müsste). -- CHRV 22:53, 15. Nov. 2009 (CET)

(BK) So umfangreich habe ich mir das nicht vorgestellt. Ich will es mal am Beispiel für die Asteroiden erklären: Ich dachte da an die Nummer als Schlüssel und als Werte nur an den ofiziellen Namen, die Orbitdaten (und deren Ableitung) und evtl. noch die abs. Helligkeit. Diese Werte kann man sehr zuverlässig zentralisieren. Alles, was darüber hinausgeht, wie z.B. Orbittyp, Entdecker, "Namenspatron" und die seltener vorhandenen übrigen physik. Werte, kann man so belassen. Die wichtigsten Vorteile wären:

Konvergenz der Daten

Ein Widerspruch, z.B. zwischen (Gr. Halbachse / Exzentrität) und (Perihel / Aphel) gehört der Vergangenheit an.

Ergänzung der Daten

Das ist der größte Vorteil. In der Box fehlen bisher noch mehrere Keplerdaten, wie z.B. Länge des aufst. Knotens und Periwinkel. Mit zentralen Werten kann man die überall automatisch ergänzen.

Update

sollte ein Update nötig sein, so ist das durch Übertragen aus einer externen Quelle, wie z.B. MPCORB, möglich. Das geht in ca. fünfzehn Minuten, ich habe es gerade ausprobiert.

Einheitlichkeit

Das einheitliche Runden der Werte erfolgt in der Infoboxvorlage.

Zu den von dir erwähnten Aspekten:

Änderung durch "normale Autoren"

Bei Beschränkung auf die o.g. Werte ist das gar nicht nötig, denn die Orbitdaten sind wissenschaftlich sehr zuverlässig. Bei der hier benötigten Genauigkeit ist da nur noch selten mit Änderungen zu rechnen. Die relativ unsicheren phys. Daten sind ja nicht im zentralen System drin.

Werte im Fließtext

Das muss man einmal vergleichen und dann wahrscheinlich nie wieder. Nur bei einer der seltenen Datenänderungen wäre das nötig. In 95% der Fälle sind die sowieso in einem immer gleichlautenden Absatz am Anfang des Artikels drin. Den kann man notfalls automatisch generieren und einfügen. Der Rest des Artikels bleibt unversehrt.

Neue Artikel

Kommt ein neuer Artikel dazu, sind die Orbitdaten schon in der Box.

Alle Änderungen in allen Boxen sind ohne einen Edit in den Artikeln möglich. Darüber hinaus fehlen in den Artikeln immer wieder Daten, die eigentlich schon bekannt sind.

Ich finde, dass man das versuchen sollte. Zumindest bei den Asteroiden mit einer Nummer unter, na sagen wir mal, 100.000. ÅñŧóñŜûŝî (Ð) 23:08, 15. Nov. 2009 (CET)

Zum Gegenvorschlag: Wer will das pflegen ? Das wird aufwändiger als meine Idee. ÅñŧóñŜûŝî (Ð) 23:08, 15. Nov. 2009 (CET)

P.S.: Ein Bot kann auch mit den Zentralen Daten arbeiten und einen Log ausgeben, um die Artikel zu überprüfen. ÅñŧóñŜûŝî (Ð) 23:14, 15. Nov. 2009 (CET)

• Konvergenz der Daten: Ja, das wäre in der Tat ein Vorteil. Andererseits: Ist das gegenwärtig ein grösseres Problem? Beispiel? Evtl. könnte man das über eine Anpassung der Infobox und eine Wartungsseite lösen.
• Ergänzung von Keplerdaten: Wäre ebenfalls ein Vorteil. Falls das überhaupt gewünscht ist. Dies wäre zuerst abzuklären.
• Update der zentralisierten Daten: nicht möglich! Wie schon erwähnt: Das funktioniert ganz einfach nicht. Nehmen wir als Beispiel den Artikel Kleopatra (Asteroid). Da hat jemand genau das von Hand gemacht, was Du automatisiert zu machen vorschlägst. Und das ist natürlich nicht so gut, weil jetzt ein Widerspruch zwischen Artikel-Text und Infobox besteht. Die Strukturierung der Artikeltexte dürfte zu vielfältig sein, als dass man dies - selbst mit fortgeschrittenen Methoden der Computerlinguistik - beherrschen könnte.
• Einheitliche Rundung: nicht möglich! Die Rundung muss der Genauigkeit des jeweiligen Wertes angepasst werden. Obwohl Datenbanken Standard-Abweichungen mitliefern, ist neben diesem statistischen Fehler auch die Berücksichtigung eines möglichen systematischen Fehlers entscheidend. Es wäre ziemlich aufwändig, das einem Computerprogramm beizubringen.
• Änderung der Daten durch Autoren: muss aus vorgenannten Gründen möglich sein und ist aus vorgenannten Gründen zwingend notwendig. Die Genauigkeit einzelner Bahndaten ist stark vom einzelnen Objekt abhängig; es gibt Spezialfälle und es gibt andere Quellen (z. B. Wert aus einem Fachjournal). Wie Du selbst einräumst, werden Änderungen - wenn auch selten - notwendig sein. Die Möglichkeit dazu muss sichergestellt sein.
• Abgleich der Werte im Fliesstext: Das wäre mit Sicherheit eine sehr, sehr aufwändige Aktion. Da ist mein Gegenvorschlag direkt ein Pappenstiel dagegen. Aber Du hast natürlich Recht, dass auch dies einen bedeutenden Aufwand darstellt.

-- CHRV 23:42, 15. Nov. 2009 (CET)

• Update: Wenn man erst einmal die Konvergenz zw. Fließtext und Box hat, dann ist weitgehend Ruhe. Die Orbitwerte ändern sich für länger bekannte Objekte nicht einfach mal so. Die einzigen Ausnahmen wären ein paar transneptunische Objekte. Eine systematische Überprüfung der bestehenden Artikel auf Widersprüche ist m.E. sowieso nötig.

• Rundung: TNOs ausgenommen, liegen die Orbitdaten der länger bekannten Objekte inzwischen mit einer Genauigkeit von sechs Dezimalstellen vor. Wir benötigen hier aber maximal fünf, meistens nur vier. Daher ist das m.E. durchaus machbar. wir müssen nicht die Inklination von Objekt X mit vier, und die von Objekt Y mit drei angeben, wenn der wissenschaft die Werte mit mind. vier Stellen bekannt sind.

• Änderung der Daten durch Autoren: Gewiss der kritische Punkt. Ich glaube nicht, dass wir für die Orbitdaten der ersten ca. 100.000 Asteroiden mehrere Quellen brauchen. MPCORB ist da ausreichend. Gerade die Verwendung verschiedener Quellen für die gleiche Eigenschaft bewirkt Widersprüche. Eine Änderung wäre sowieso Sache eines Autors, welcher sich in mit der Box dann auskennt. Eine Fußnote, wo man die Anleitung findet, hilft hier ggf. auch weiter. (oder eine Anfrage beim Portal).

• Abgleich der Werte im Fliesstext Der Katbaum listet 2829 Artikel. Einmal ein Haufen Arbeit, dann nicht mehr. Wäre machbar. Es stellt sich auch die Frage, ob man die Orbitdaten unbedingt im Fließtext haben muss. Eine Stichprobe zeigt mir, dass die sowieso bei den meisten Seiten dort fehlen.

ÅñŧóñŜûŝî (Ð) 00:19, 16. Nov. 2009 (CET)

Also, dann eben in Langfassung. Das Problem ist deutlich komplizierter als Du denkst. Bei den Angaben des Minor Planet Centers, die Du offenbar verwenden willst, handelt es sich um oskulierende Elemente. Das heisst, dass die tatsächliche Bahn des Objektes (kein Kepler-Orbit, sondern ein gestörter Orbit) durch eine Keplerbahn angenähert wird, und zwar so, dass sie für eine genau definierte Epoche (einen Zeitpunkt) möglichst exakt mit der tatsächlichen Bahn übereinstimmt. In der Nähe dieser Epoche stimmt die Bahn dann sehr genau - daher die kleinen Werte für die Standardabweichungen. Je weiter man sich davon entfernt, desto grösser werden jedoch die Abweichungen. Dies bedeutet nun, dass sich die (oskulierenden) Elemente, die Du vom Minor Planet Center für ein bestimmtes Objekt erhältst, relativ schnell ändern können und dass die Änderungen relativ gross sein können. Die dritte signifikante Stelle kann sich dabei innerhalb einiger Monate ohne weiteres ändern; über grössere Zeiträume auch die zweite (so der Fall bei Kleopatra (Asteroid). Du siehst: Das mit den sechs Nachkommastellen ist einfach nur Unsinn. Und das ist das eigentliche / tiefere Problem dahinter (und der Grund, weshalb die Angaben in den meisten Asteroiden-Artikeln genau genommen nicht ganz exakt sind, bzw. unvollständig um die Angabe der Epoche).

Wenn man das wirklich grundsätzlich überarbeiten will, dann muss man die Infobox-Vorlage und sämtliche Asteroiden-Artikel entsprechend anpassen (das sind grössere Änderungen im Fliesstext notabene). Dazu braucht man nicht nur enorm viel Zeit, sondern auch Ahnung von der Materie. Die Infobox müsste dann auch klar deklarieren, dass es sich um die oskulierenden Elemente des MPC für diese oder jene Epoche handelt und dass die Daten regelmässig vom MPC über eine Vorlage übernommen werden.

Ich habe gewisse Zweifel, dass Du eine Mehrheit der Benutzer von dieser Lösung wirst überzeugen können. Abgesehen davon müsste sie dann auch noch umgesetzt werden.

-- CHRV 02:30, 16. Nov. 2009 (CET)

Dann gibt es im Sinne der Korrektheit nur eine Konsequenz, welche langfristig Sinn macht: Im Fließtext dürfen gar keine statischen Zahlen stehen, weil man sonst alle paar Monate dauernd editieren müsste. Daraus folgen zwei Lösungen, welche beide für eine zentrale Datenseite sprechen:

1. Die Wikipedianer springen über ihren Schatten und beschließen, dass auf den Seiten für Asteoiden und Kometen ausnahmsweise eine Vorlage im Fließtext eingesetzt wird, welche die Daten in einem Standardtext (also einem Absatz) wiedergibt.
2. Es kommen gar keine Daten in den Fließtext hinein. Stattdessen eine Fußnote in die Infobox, dass sich die Daten permanent ändern und deshalb nur automatisiert in der Box stehen.

Die zweite Lösung würde mir besser gefallen. Sie entspricht auch der von dir erwähnten klaren Deklaration. Die Epoche kann auch zu den Angaben dazunehmen. Das lässt sich alles in die Box schreiben.

Wenn es soviel zu ändern gibt, dann sehe ich keine andere Möglichkeit, die Artikel Up to date zu halten, insbesondere nicht durch manuelle Edits. Nach deiner Beschreibung ist das viel zuviel dafür und generiert nur unnötige Seitenversionen. Zentrale Daten sind hier besonders vorteilhaft. In regelmäßigen Abständen komplett austauschen und fertig. Nur so verhindert man, von der Einführung des Systems abgesehen, auf Dauer viel Arbeit.

Ich wäre bereit, das System zu erstellen. Wäre nett, wenn du dich dafür erwärmen könntest. Als Belohnung kannst du dich dann zukünftig über regelmäßig zentral aktualisierte Daten in allen (!) Artikeln, auch zukünftig erstellten, freuen. ÅñŧóñŜûŝî (Ð) 16:23, 16. Nov. 2009 (CET)

Ich halte die Verwaltung oskulierender Bahnelemente für Asteroiden in einer zentralen Vorlage mit den angesprochenen Anpassungen grundsätzlich für einen gangbaren Weg, sehe dies jedoch keinesfalls als Notwendigkeit. (Ich sehe dabei insbesondere auch keine "Belohnung" oder auch nur einen Vorteil für mich: Wenn ich Bahnelemente von Kleinplaneten will, dann werde ich die ganz sicher nicht bei Wikipedia suchen. Bei den allermeisten Benutzern wird es ähnlich sein - wer wirklich etwas mit den Daten anfangen kann, holt sie sich nicht bei Wikipedia.)

• Ich weise darauf hin, dass die notwendigen Anpassungen in fast 3000 Asteroiden-Artikeln einen gewaltigen Aufwand darstellen. Ich möchte klarstellen, dass ich dazu weder Zeit noch Lust habe und nicht beabsichtige, mich da in grösserem Umfang zu engagieren. Es stellt sich schon die Frage, ob dieser Aufwand überhaupt zu sinnvoll und zu bewältigen ist, vor allem, wenn man ihn in Relation zu den sich dadurch ergebenden Vorteilen setzt.
• Es müsste abgeklärt werden, ob diese Lösung im Hinblick auf die Server-Resourcen umsetzbar ist. Die vorgeschlagene Daten-Vorlage dürfe mehrere Megabyte gross werden...
• Ich bin ziemlich sicher dass ein Löschantrag auf die Datenseite gestellt werden wird, dem eine grössere und kontroverse Diskussion folgen wird. Man wird - und dies nicht ganz zu unrecht - darauf hinweisen, dass Wikipedia keine Sammlung von Rohdaten ist. Bevor man sich an eine Umsetzung macht, sollten deshalb alle offenen Fragen geklärt und das Vorgehen breit abgestützt werden, sonst wird das in einem veritablen Desaster enden.
• Ich habe massive Vorbehalte gegenüber einer Vorlage für Fliesstext. Das ist meines Erachtens kein erstrebenswertes Ziel. Gleichzeitig bin ich auch dezidiert der Meinung, dass Informationen über die Bahn eines Asteroiden in den Fliesstext gehören. Es ist ganz einfach notwendig, diesen Text so zu gestalten, dass er nicht in regelmässigen Abständen angepasst werden muss. Mit etwas Geschick ist das möglich. Im Fliesstext sollten dann auch unbedingt weitere Aspekte des Orbits anhand geeigneter Quellen (Fachjournale) diskutiert werden (mittlere Bahnelemente, Stabilität, allfällige Resonanz, evtl. Zugehörigkeit zu Familie, Kreuzung von Planetenbahnen usw. usf.).
• Es bleiben diverse Detail-Fragen, je nach verwendeter Datenquelle z. B. auch rechtliche.

Fazit: Es braucht meines Erachtens zunächst weitere Abklärungen und unbedingt weitere Stimmen von anderen Benutzern. -- CHRV 18:38, 16. Nov. 2009 (CET)

Meine bescheidene Meinung dazu: die stete Aktualisierung der Parameter ist nicht notwendig. Ich stimme dem zu, dass derjenige, der an Bahnelementen interessiert ist, auf andere, bessere Datenbanken zurückgreifen wird. Es ist einer der unter WP:WWNI aufgeführten Grundsätze, dass Wikipedia keine Datensammlung ist. Eine entsprechende Datenseite würde eine recht kurze Lebenserwartung haben und wird eher wieder eine neuerliche Diskussion vom Zaun brechen, ob man die Asteroidenartikel nicht sowieso unterbinden sollte, weil sie zumeist nicht viel mehr als die Daten enthalten. Ich würde von einer zentralen Datenverwaltung deutlich abraten. Es widerspricht nun mal den Richtlinien der WP und hat einen eher geringen Nutzwert. Was m.E. jedoch eine sinnvolle Aktion wäre, wäre die Bot-gestützte Verschiebung aller Asteroiden-Artikel auf ein einheitliches Lemma mit der jeweiligen Nummer als Klammer-Vorsatz. Mal so als Anregung für User, die mit Bots umzugehen wissen. --seismos 19:46, 16. Nov. 2009 (CET)

Diese Asteroidenartikel sind halt zu 2/3 an der Stubgrenze. Es gibt aber auch welche mit mehr Infos auf der Seite. Hier kann man das wohl nicht im Einzelnen klären. Es ist ein Mangel der ganzen WP, dass sie nicht mit (externen) Datenbanken kooperiert und nicht Abfragen mit Artikeln verknüpft. Na Ja, schade, wenn für diese Enzyklopädie Nützliches den WP-Regeln wiederspricht. ÅñŧóñŜûŝî (Ð) 23:00, 16. Nov. 2009 (CET)

Darf ich auch meine bescheidene Meinung hinzufügen? Ich habe mir mal wahllos einige Asteroiden-Artikel angesehen. Typischerweise sehen sie etwa wie Westphalia (Asteroid) aus: ein bisschen Fließtext neben einer Infobox, in der die Daten systematisch angegeben sind. In manchen Fällen, wie z.B. Itokawa (Asteroid) werden die Daten, die in der Infobox stehen, im Fließtext wiederholt. Das halte ich für unnötig (redundant) und gefährlich (Inkonsistenz innerhalb des Artikels nach Aktualisierung). Ich wäre also dafür, diese Fließtext-Zahlen zu entfernen, wenn es keinen Grund gibt, sie dort zu behalten (muss manuell untersucht und entschieden werden). Für die Zahlen in der Infobox gilt prinzipiell, dass sie teilweise ebenfalls redundant sind, denn eigentlich kann man große und kleine Halbachse, Perihel und Aphel, mittlere Entfernung und Exzentrizität ineinander umrechnen, aber praktischer ist, wenn man die Zahlen für all diese Größen direkt parat hat. Außerdem gilt, dass sich die Bahnparameter (mehr oder weniger schnell) im Laufe der Zeit ändern. Soweit sind wir uns einig, oder? Wie gehen wir mit dieser Sache um? Eine zentralisierte Datenbank halte ich nicht für sinnvoll. WWNI! Andererseits riskieren wir auch, veraltete Daten anzuzeigen, wenn wir uns nur auf manuelle Überprüfung und Aktualisierung verlassen. Das ist mühsame und fehlerträchtige Arbeit, die sich vielleicht keiner zumuten möchte. Warum holen wir uns da nicht die Hilfe eines Bots, um stupide Vergleichsarbeit zu erledigen? Ein Bot könnte eine externe Asteroiden-Datenbank auslesen und automatisch unsere Asteroiden-Artikel (derzeit knapp 3000) durchscannen und die Datenbank-Werte mit den Infobox-Werten vergleichen. Bei einer signifikanten Abweichung (muss definiert werden) könnte er einen Hinweis auf der Diskussionsseite hinterlassen und um manuelle Überprüfung und evtl. Aktualisierung bitten. Eine automatische Korrektur halte ich wegen der Rundung für problematisch (Ein Experte mag da besser als ein Bot entscheiden können, wieviel Stellen hier oder da sinnvoll sind). Ein Luxus-Bot könnte auch die Bahnparameter auf Konsistenz überprüfen, also wenn z.B. Perihel/Aphel nicht zu Halbachsen/Exzentrizität passen. Warum sollten wir uns die Bot-Funktionalität nicht zu Nutze machen? --Asdert 10:18, 17. Nov. 2009 (CET)

Ich bin auch der Ansicht, dass die Wiederholung der Daten im Fließtext überflüssig ist. Abgesehen von einigen wenigen Fällen, in denen außergewöhnliche Werte auftreten. Ebenso ist offensichtlich, dass eine zuverlässige manuelle Aktualisierung nicht realistisch ist. Der Vorschlag, mittels Bot eine externe Datenbank zur Aktualisierung zu nutzen, scheint mir der praktikabelste Weg, der auch am ehesten mit den Richtlinien der WP konform geht. --seismos 10:37, 17. Nov. 2009 (CET)

Das ist dann aber nur noch marginal verschieden zu meiner "Zentralseite". Ob ein Bot nun diese Werte in die Artikel schreibt oder auf eine zentrale Seite, ist kein großer Unterschied. Der wichtigste Unterschied ist: Beim Update von Artikeln erzeugt der Bot hunderte neuer Versionen, bei der zentralen Tabelle nur eine (!). Darüber hinaus wäre diese zentrale Seite nicht im ANR, sondern eine Untervorlage. WP:WWNI Punkt 7 ist für den Artikelbereich gedacht. Es stellt sich sowieso die Frage, ob dieser Punkt für eine Untervorlage für Infoboxen gültig ist. hier geht es um Werte, welche innerhalb der WP weitergenutzt werden sollen. ÅñŧóñŜûŝî (Ð) 17:47, 17. Nov. 2009 (CET)

Als marginal würde ich den Unterschied nicht bezeichnen. In einem Fall wird ein Hinweis auf die Diskussionsseite geschrieben (ähnlich wie "Weblink defekt, bitte überprüfen"), im anderen Fall wird direkt in den Artikel geschrieben (oder auf eine Zentralseite). Der Unterschied liegt in der manuellen Entscheidung, und das finde ich nicht mehr marginal. Bei den Einwohnerzahlen der deutschen Städte und Gemeinden wird übrigens so ein System verwendet, wie Du vorschlägst, sogar zweistufig. Im Fließtext kommen keine Einwohnerzahlen mehr vor. Im Quelltext der Infobox steht der Gemeindeschlüssel. Großenkneten in Niedersachsen ist 03458007. Damit wird die Einwohnerzahl aus einer (bundeslandspezifischen) Vorlage geholt. Für Niedersachsen ist das Vorlage:Metadaten Einwohnerzahl DE-NI. Dort steht die Zeile 03458007 = 13576, womit in der Infobox von Großenkneten der Text "Einwohner: 13.576 (31. Dez. 2008)" erscheint, obwohl das so nicht im Quelltext steht. Einmal im Jahr werden die Metadaten-Dateien mit den neuen Einwohnerzahlen aktualisiert, damit alle deutschen Einwohnerzahlen immer auf der gleichen Grundlage angegeben werden. Das hat seine Vorteile, war aber auch nicht ganz unumstritten. Für die Asteroiden ist ein ähnliches System technisch machbar, aber ich würde dennoch davon abraten. Noch eine neugierige Nachfrage: Von wieviel Artikeln reden wir? Bei welchem Anteil der Asteroiden ändern sich die Bahnparameter im Lauf eines Jahres um, sagen wir mal, mehr als 5%? Sind es wirklich Hunderte von Seiten, die der Bot jedes Mal aufspürt, oder sind es nur eine Handvoll? --Asdert 21:58, 17. Nov. 2009 (CET)

Wie stark die Änderungen sind, hängt vom betrachteten Objekt und vor allem auch vom jeweiligen Bahnelement ab. Da eine Aktualisierung immer nur einen kompletten Satz von Bahndaten betreffen kann, ist das Bahnelement mit den grössten Änderungen ausschlaggebend. Ich gehe davon aus, dass sich bei allen Asteroiden innerhalb von etwa zwei Jahren eine Änderung eines oskulierenden Bahnelementes um 5% ergibt. Das heisst also, wir sprechen von Änderungen in etwa 3000 Artikeln alle zwei Jahre, wenn man dies als Grundlage nehmen würde.

Als Anschauungsbeispiel vielleicht noch einen Ausschnitt einiger oskulierender Elemente für ein bestimmtes Objekt im Sonnensystem (aus dem Montenbruck; um welches Objekt es sich genau handelt, möchte ich zwecks Vermeidung weitergehender Aufregung mal besser nicht sagen):

Datum       a          e         M         i
----------  ---------  --------  --------  ------
11.10.1949  19,158504  0,046286  285,5139  0,7732
15.11.1950  19,186019  0,046061  292,0829  0,7732
20.12.1951  19,227085  0,046741  299,2106  0,7737
23.01.1953  19,266174  0,048116  305,7044  0,7742
27.02.1954  19,290424  0,049595  310,9224  0,7746
03.04.1955  19,295187  0,050623  314,9855  0,7747
07.05.1956  19,282465  0,050936  318,3453  0,7745
12.02.1962  19,255167  0,043774  342,5533  0,7732
09.02.1965  19,173820  0,046374  354,4738  0,7733
20.04.1967  19,253626  0,050302    3,3464  0,7733
24.05.1968  19,274446  0,051241    6,9902  0,7733
23.01.1976  19,132796  0,045358   42,1393  0,7730
01.08.1993  19,235292  0,047322  111,6887  0,7725

Würde man die vollständigen Daten über einen grösseren Zeitraum anschauen, so würden der oszillierende Charakter der Änderungen noch besser sichtbar. -- CHRV 23:06, 17. Nov. 2009 (CET)

"Marginal" bezog sich auf die vollautomatische Änderung der Artikel per Bot, nicht auf die halb manuelle. Den Fall mit den Einwohnerzahlen hatte ich als Vorbild, als ich hier den Vorschlag machte. Es gibt auch ein kleineres System bei den Banken. Offensichtlich hat es sich in beiden Fällen bewährt. Die Werte sollten schon eine Genauigkeit von 2% haben. gehen wir besser von einem kompletten Austausch in einem Jahr aus. Das ist gewiss nur noch vollautomatisch sauber aktuell zu halten. Bei 3000 Artikeln wären das zwar rechnerich nur neun pro Tag, aber auf Dauer wird das nicht durchgehalten. Auch hier ist die zentrale Tabelle vorteilhaft. Das kann man bei Bedarf alle drei Monate in maximal einer Stunde erledigen. ÅñŧóñŜûŝî (Ð) 03:13, 18. Nov. 2009 (CET)

Egal ob 2% oder 5%, ob 3000 Artikel pro Jahr oder in zwei Jahren: jetzt weiß ich wenigstens, über welche Größenordnungen wir reden: 1500 bis 3000 Änderungen pro Jahr, also 125 bis 250 pro Monat, oder 4 bis 8 pro Tag. Das ist mehr als ich erwartet hätte. Da fürchte ich, dass mein Vorschlag mit dem Hinweis auf der Diskussionsseite vielleicht doch unpraktisch ist. Da kommen die Mitarbeiter vielleicht nicht hinterher, die Daten manuell zu prüfen und den Artikel zu korrigieren. Wenn aber sowieso (mehr oder weniger) alle Objekte betroffen sind, dann ist es auch nicht notwendig, den Bot allzuoft loszuschicken. Wir sind kein Newsticker und keine wissenschaftliche Datenbank, und ein Wikipedia-Leser sollte durchaus akzeptieren, Werte zu lesen, die mehrere Monate alt sind. Eine General-Aktualisierung pro Jahr (oder alle 6 Monate, jedenfalls nicht unbedingt monatlich), die dann alle Artikel umfasst (unabhängig davon, wie sehr sich die Daten geändert haben), wäre also praktikabel, oder? Das wäre ein Kompromiss aus Aktualität, Aufwand und der Menge an neuen Artikelversionen. Das löst aber immer noch nicht das Problem mit der Rundung. --Asdert 10:12, 18. Nov. 2009 (CET)

Teil 2

Mit einer zentralen Tabelle muss man aber keine uralten Werte haben. Das ist der Vorteil.

Was es die Rundung angeht, sollte man sich für jede Größe auf eine bestimmte Genauigkeit für alle Seiten einigen. Mein Vorschlag:

Interne Darstellung von gr. Halbachse und Exzentrizität

sechs Stellen

Darstellung

meistens vier Stellen, also

• Alle Winkel 0,1°
• Exzentr. 0,0001
• alle "AU-Werte" 0,01 (Es gibt mur ca. zehn Werte größer als 100 AU)
• Periode: Ganze Tage

Die physik. Eigenschaften:

• Abs. Helligkeit: 0,01 mag.
• Albedo, Durchmesser etc. sind zu individuell und müssen auch nicht auf eine zentrale Seite, da hier wohl seltener zu ändern ist.

Es zeigt sich immer mehr, dass ein Zentralsystem wie bei den Einwohnerzahlen am leichtesten zu handhaben wäre. Ich habe mal die Größe einer zentralen Seite ermittelt: Es sind ca. 500 Byte und für jeden Eintrag ca. 100 Byte. Bei größzügig angenommenen 10.000 Einträgen wäre das also ca. 1 MByte. ÅñŧóñŜûŝî (Ð) 14:28, 19. Nov. 2009 (CET)

Noch zwei Gesichtspunkte (ja, ich bin der Bedenkenträger, so jemand braucht ein Projekt auch): Zukunftssicherheit und Abhängigkeit. Wenn ein Bot nicht mehr läuft, dann schadet das nicht, weil man trotzdem noch von Hand ändern kann. Wenn die zentrale Seite aber nicht mehr aktualisiert wird (weil die externe Datenbank jetzt irgendwie anders läuft, weil Du nicht mehr in der Wikipedia aktiv bist, weil ...) dann haben wir eine Datei mit 3000 Zeilen und vielen sechstelligen Zahlen, die man irgendwie aktualisieren will/muss oder notfalls wieder in 3000 Artikel als Infobox-Text zurückbringen will. Das muss dementsprechend gut dokumentiert sein. Deinen Einwand "Mit einer zentralen Tabelle muss man aber keine uralten Werte haben. Das ist der Vorteil." verstehe ich nicht. Das ist doch kein Vorteil der zentralen Seite gegenüber

einem Bot, der alle Artikel einzeln aktualisiert. --Asdert 13:29, 20. Nov. 2009 (CET)

Ich bitte, allgemein davon Abstand zu nehmen, von "alten" und "neuen" Daten zu sprechen. Nennt mich meinetwegen pedantisch, aber das wird der Sache einfach nicht gerecht. Wichtig fände ich einzig und allein den Hinweis darauf, dass es sich um oskulierende Elemente handelt, und die Angabe für welche Epoche sie gelten. Ob diese Epoche nun ein paar Tage entfernt ist oder ein paar Jahre ist a priori völlig egal, die eine Angabe ist in keiner Weise besser oder schlechter als die andere; man kann die Epoche in diesem Sinne einfach wie eine zusätzliche (aber notwendige!) Koordinate auffassen. (Natürlich kann es sein, dass die Bahnbestimmung durch neuere Beobachtungen signifikant verbessert / verändert wird, aber dies dürfte im Vergleich zu signifikanten Änderungen der oskulierenden Elemente deutlich seltener der Fall sein.) -- CHRV 18:35, 20. Nov. 2009 (CET)

(BK)@Asdert: Mit "keine uralten Werte" meine ich, dass bei zentraler Tabelle ein Austausch notfalls jede Woche möglich wäre, denn es ist immer nur ein Edit. Willst du einen Bot aber 3000 Edits/Woche machen lassen, so gibt das wegen der Flut an Seitenversionen gewiss Ärger.

Die Daten sind als ASCII-Datei abrufbar. Dort liegen sie beispielsweise im FORTRAN-Stil vor. Die manuelle Umformung kann z.B. mit Hilfe eines blockauswahlfähigen Texteditors und einer Tabellenkalkulation erfolgen:

1. Datei im Texteditor öffnen
2. Nicht benötigte Zeilen (Objekte) und nicht benötigte Spalten (Größen) entfernen.
3. In den als Trenner gekennzeichneten Spalten Tabulatoren einfügen.
4. Den Text per C&P in eine leere Excel- oder OpenOffice-Tabelle kopieren.
5. Zellen ggf. formatieren (Rundungen).
6. Text per C&P zurückkopieren
7. Tabuatoren durch "/" ersetzen.

Bei der zweiten Methode kann man auch direkt in die Tabellenkalkulation einlesen, wenn diese Fortran-Tabellen als Filter kennt.

Geht schnell und sieht dann ungefähr so aus (zehn Einträge für sieben Werte):

{{#switch:{{{1}}}
|     1 =2.765723/0.079221/70.4/72.7/80.4/10.6/0.214284
|     2 =2.772748/0.230970/53.4/310.2/173.1/34.8/0.213470
|     3 =2.670000/0.254965/346.9/248.1/169.9/13.0/0.225910
|     4 =2.361937/0.088729/253.5/149.8/103.9/7.1/0.271519
|     5 =2.577742/0.190815/191.9/358.0/141.7/5.4/0.238146
|     6 =2.424608/0.202490/279.5/239.5/138.7/14.8/0.261060
|     7 =2.386585/0.230906/311.2/145.1/259.7/5.5/0.267324
|     8 =2.200870/0.156833/248.8/285.4/111.0/5.9/0.301864
|     9 =2.386609/0.122221/87.9/6.3/69.0/5.6/0.267320
|    10 =3.139717/0.116943/268.9/313.1/283.4/3.8/0.177161
}}

Das kann man mit der Wikisyntax auslesen und in die Infobox bringen.

Darüber hinaus ist es leicht, ein Programm zu schreiben. Das muss ja nur eine Datei formatiert lesen und anders formatiert schreiben können. ÅñŧóñŜûŝî (Ð) 18:42, 20. Nov. 2009 (CET)

@CHRV: Die Epoche steht in der Quelldatei drin. Kann man übernehmen. (Im Beispiel noch nicht enthalten). ÅñŧóñŜûŝî (Ð) 18:42, 20. Nov. 2009 (CET)

Der springende Punkt meiner Aussage war gerade, dass eine häufigere Aktualisierung gar nicht unbedingt nötig ist. Weshalb sollte man z.B. jede Woche / jeden Monat / jedes Jahr einmal aktualisieren und nicht einmal alle 20 Jahre? -- CHRV 18:50, 20. Nov. 2009 (CET)

Einmal pro Woche ist gewiss übertrieben, aber du hast oben in der Tabelle geschrieben, dass es Werte sind, die sich häufiger ändern. Deine Beispieltabelle zeigt doch, dass nach einem Jahr ein wesentlicher Teil der Zahlen von immerhin 3000 Objekten in der Quelldatei neu sein können. Ein regelmäßiges Update aller Werte ist da die einfachste Methode. ÅñŧóñŜûŝî (Ð) 19:03, 20. Nov. 2009 (CET)

Das sagt die Tabelle eben gerade nicht aus. Genau darauf wollte ich hinaus mit der Bitte um Vermeidung der Worte "alt" und "neu" in diesem Zusammenhang. Jede einzelne Zeile in der von mir weiter oben eingefügten Tabelle enthält im Prinzip die selbe Information (bzw. enthielte sie, wenn die Bahnelemente vollständig wären). Ähnliches Beispiel: Bei den Sternen aktualisieren wir die Koordinaten ja auch nicht jedes Jahr, sondern verwenden die Standard-Epoche J2000.0 (die schon fast 10 Jahre in der Vergangenheit liegt). -- CHRV 19:09, 20. Nov. 2009 (CET)

Aber eben nur genau für den Zeitpunkt. Du beschreibst in deiner "Langfassung", dass die Änderungen sehr schnell sein können und die Abweichungen mit zunehmender Zeitdifferenz größer werden. Bei einem Hauptgürtelasteroid, der regelmäßig vom Jupiter beeinflusst wird, kann man davon ausgehen, dass eine Näherung für den 1. Jan 2009 ein Jahr später ggf. mehr von den tatsächlichen Werten (einer Näherung für den 1. Jan 2010) abweicht, als bei der angebebenen Genauigkeit belanglos wäre. Natürlich kann man, so wie bei den Sternen, einfach sinngemäß angeben: "Die Werte waren für den 1. Jan. 2009 exakt". Wenn es aber eine fertige, neue Quelldatei für einen späteren Zeitpunkt gibt, dann ist es doch besser, diese zu nehmen. ÅñŧóñŜûŝî (Ð) 19:31, 20. Nov. 2009 (CET)

Da die Störungen der Bahn ziemlich genau bekannt sind (vor allem die Planeten, wie Du schon geschrieben hast), kann man diese berücksichtigen. Methoden der numerischen Integration erlauben dadurch, aus der oskulierenden Keplerbahn für einen bestimmten Zeitpunkt die oskulierende Keplerbahn für einen anderen Zeitpunkt zu berechnen (grundsätzlich über tausende von Jahren und mit grosser Präzision). Wenn die Bahndaten genügend genau bekannt sind, werden sich grössere Fehler gegenüber den "tatsächlichen" oskulierenden Elementen erst nach Jahrzehnten oder Jahrhunderten ergeben. Problematischer ist das natürlich, wenn man nur sehr wenige Positionsbestimmungen eines Kleinplaneten hat (anzahlsmässig und / oder über einen kurzen Zeitraum), dann kann die tatsächliche Bahnnäherung in der Tat sehr stark von der berechneten abweichen (deshalb gibt es auch hunderttausende von Asteroiden für die man nur einzelne Positionsbestimmungen gibt und die wiederzufinden man genau aus diesem Grund keine Chance hat). -- CHRV 19:54, 20. Nov. 2009 (CET)

Gewiss kann man das berechnen. Es passt aber besser zu den Interessen der WP, wenn wir hiereinfach nur die Werte für eine möglichst aktuelle Näherung an eine Keplerbahn haben. Das kommt WP:OmA am besten entgegen. Wer sich mit komplexeren Bewegungen als Keplerbahnen genau beschäftigen will, der nimmt nicht mehr die WP zur Hilfe. Gerade die vereinfachte Vorstellung einer Keplerbahn sollte aber aktuelle Zahlen haben. ÅñŧóñŜûŝî (Ð) 20:12, 20. Nov. 2009 (CET)

Das kann man freilich so machen. Eine andere Lösung für das "Problem" wäre, die Anzahl der angegebenen signifikanten Stellen bei den Bahnelementen deutlich zurück zu schrauben (auf zwei bis drei, je nach Objekt und Bahnelement). Dadurch würden häufige "Aktualisierungen" (die eigentlich gar keine sind) entfallen und es würden keine falschen Vorstellungen über die Genauigkeit und Natur der Umlaufbahnen mehr induziert.

Dabei spielt es natürlich eine Rolle, was man mit den Bahnelementen eigentlich will. Es muss wohl zunächst mal die Grundsatz-Frage geklärt werden, wozu wir die Bahnelemente im Artikel überhaupt angeben, welchen Nutzen / Mehrwehrt dem Leser geboten werden soll, beziehungsweise, was der Leser von einem Asteroiden-Artikel in Wikipedia erwartet / erwarten darf. -- CHRV 17:24, 21. Nov. 2009 (CET)

Sinngemäß ausgedrückt: Es sollte für einen Aufsatz über Asteroid XY im gehobenen Schulunterricht ausreichen. Die Zahlen sollten eine ungefähre Beschreibung der Bahn darstellen. Als "Grenze der Ungenauigkeit" würde ich in der Darstellung bei den Winkeln 1° nehmen (Inklination 0,1°) und bei "AU-Werten" drei Stellen. Für die Helligkeit würde 0,1 mag wohl auch ausreichen.

Soll ich mal einen Entwurf machen und bei ca. zehn möglichst verschiedenen Artikeln ausprobieren ? Dann sieht man besser, ob und wie es funktionieren kann. ÅñŧóñŜûŝî (Ð) 19:28, 21. Nov. 2009 (CET)

Die Grundsatz-Frage scheint mir noch nicht beantwortet zu sein. Für einen Aufsatz im gehobenen Schulunterricht kommen vielleicht zwei Dutzend Objekte in Frage, das kann also kein generelles Kriterium für die fast 3000 Artikel sein.

Ausserdem: Wenn es "nur" darum geht, einen groben Eindruck über den Orbit eines Asteroiden zu geben, dann reichen zwei signifikante Stellen völlig aus und es gibt keinerlei Veranlassung, die Epoche der oskulierenden Elemente regelmässig anzupassen (schliesslich spielt es vor diesem Hintergrund nicht die geringste Rolle, ob die grosse Halbachse eines Objektes nun 2,38 AE oder 2,43 AE beträgt). -- CHRV 17:53, 23. Nov. 2009 (CET)

Das bedeutet aber, dass Leser, die das Ganze evtl. doch genauer sehen, einen schlechten Eindruck vom Artikel haben. mit den von mir dargestellten Genauigkeiten sind wir auf der sicheren Seite, ohne dass wir es übertreiben. ÅñŧóñŜûŝî (Ð) 22:35, 23. Nov. 2009 (CET)

Um einen Eindruck über den Orbit zu geben, benötigt man aber im Allgemeinen keine oskulierenden Bahnelemente für eine möglichst aktuelle Epoche. Die oskulierenden Bahnelemente für eine bestimmte Epoche vermitteln kein besseres Bild der Bahn als diejenigen für eine andere. Eine Aktualisierung der Daten ist allenfalls dann notwendig, wenn es für einen Asteroiden nur wenige Beobachtungen gibt und sich durch neue Beobachtungen wesentliche Änderungen an den Bahnelementen ergeben können. Dies könnte dafür sprechen, eine Metadaten-Vorlage nur für Asteroiden ohne Nummer zu verwenden, wo dies eher gegeben ist. (Um einen allgemeinen Eindruck von der Bahn eines Asteroiden zu geben, wären natürlich mittlere Kepler-Bahnelemente (unabhängig von einer Epoche) eigentlich besser. Das Problem dabei wäre allerdings wahrscheinlich, dass der "normale" Autor eines Asteroiden-Artikels dies nicht korrekt umsetzen könnte.)

(Nur kurz zu den signifikanten Stellen, da dies mit der zu beantwortenden Grundsatz-Frage nichts zu tun hat und nur eine Detailfrage der Umsetzung einer Metadaten-Vorlage wäre: Was Du da dargestellt hast, ist einfach eine unbegründete und zufällige Wahl. Ich wüsste nicht, weshalb man damit auf der sicheren Seite sein sollte. Ich sehe auch nicht ein, weshalb man bei zwei signifikanten Stellen einen schlechten Eindruck haben soll und bei drei nicht.) -- CHRV 00:06, 24. Nov. 2009 (CET)

Wenn man weis, dass solche Werte recht genau bestimmbar sind, dann bekommt man bei zwei Stellen schon den Eindruck, dass da kräftig gerundet wurde. Insbesondere Leser, die nicht wissen, dass sich die Werte verändern. Aber das ist ein Nebenthema.

Mit den osk. Elementen ist es halt wie mit einem Linienbus. Die momentane sekundengenaue Verspätung sagt nichts über die durchschnittliche Pünktlichkeit aus. Die Anwendung auf Objekte mit kurzer Beobachtungszeit ist gewiss realisierbar. Es wäre ja das gleiche Vorlagensystem. Aber wenn man es für die "ungenau gemessenen" nutzt, dann muss man die anderen nicht aussperren. Es zeigt allenfalls, dass man nicht hetzen muss. Die existierenden Seiten müssen ja nicht allesamt in drei Tagen geändert werden. ÅñŧóñŜûŝî (Ð) 13:55, 24. Nov. 2009 (CET)

In 3 Tagen könntest Du das sowieso nicht machen, selbst wenn Du die drei Tage durcharbeitest (nur, um nochmal klar zu machen, welchen Aufwand das bedeuten würde). Ansonsten sind die wichtigsten Argumente und Alternativen wohl so langsam genannt. Wie Du weisst, habe ich jedoch keinerlei Kompetenzen, um Dir nun grünes (oder rotes) Licht für die Vorbereitung zur Umsetzung zu geben. Letztenendes muss das per Konsens passieren (was sonst passieren könnte, wurde auch gesagt).

Worüber so etwas wie ein Konsens herrschen dürfte, soweit ich das sehe, ist die Entfernung unangebracht genauer Bahnelemente aus den Artikeltexten sowie die Präzisierung der Infobox hinsichtlich der Epoche der oskulierenden Elemente. Eventuell könntest Du damit mal "probeweise" anfangen, um den Fortschritt der Diskussion etwas zu katalysieren. (Ein geringfügiger Nachteil wäre dabei, dass man die Artikel möglicherweise dann später nochmals "anfassen" müsste.) -- CHRV 21:39, 25. Nov. 2009 (CET)

Teil 3

Ich habe mal eine Box entwickelt, damit man mal etwas sieht. Ein Beispiel ist auf Benutzer:Antonsusi/Vorlagenaufruf zu finden (Eine Formel für die Umlaufgeschwindigkeit und die Epoche fehlen noch).

Was den Text angeht, müsste man im Beispiel den gelb hinterlegten Text entfernen. Ich habe auch testweise 40 Harmonia, 41 Daphne, 42 Isis, 43 Ariadne, 44 Nysa und 45 Eugenia umgestellt. Meinungen dazu ? ÅñŧóñŜûŝî (Ð) 04:57, 28. Nov. 2009 (CET)

Was ist das Konzept hinter diesem Entwurf? Das entspricht keiner der bisher diskutierten Varianten und die angesprochenen Fragen und Probleme sind in keiner Weise berücksichtigt. Sorry, aber das sieht für mich eher nach einem unausgegorenen Schnellschuss aus. -- CHRV 16:44, 30. Nov. 2009 (CET)

??? Jetzt verstehe ich überhaupt nicht mehr, worauf du hinaus willst. Das hatten wir doch angesprochen. Das Konzept ist folgendes:

1. Die von anderen Benutzern hier geschriebenen Beiträge zeigen, dass es schon zentrale Datenseiten gibt und das wohl kein Widerspruch mit den Prinzipien der WP ("Rohdaten") darstellt, denn die Seite befindet sich im Vorlagenbereich und wird im ANR nicht komplett gezeigt.
2. Der Vergleich mit den existierenden Datenseiten zeigt, dass der Server das wohl packt, wenn man nicht übertreibt.
3. Die Orbitdaten aus dem Fließtext entfernen, weil es kaum möglich ist, bei so vielen Seiten die Übereinstimmung mit der Box zu erhalten und damit auch das Haupthindernis für ein etwaiges Update weg ist.
4. Die Frage nach der Rundung hat gezeigt, dass man hier bei den meisten Asteroiden hinkommt, indem man nicht so viele Stellen nimmt. Bei TNOs (automatisch erkennbar) würde ich ganz einfach die bisherige Form belassen.
5. Die Epoche wird aufgrund deiner Erläuterungen eingebunden, weil die zu den Werten für osk. Elem. dazugehört (fehlt noch)

Was noch Sinn macht ist eine Fußnote, damit Autoren wissen, was los ist.

Es ist auch möglich, die Werte von JPL zu beziehen. Das macht eine sinnvolle Auswahl möglich. ÅñŧóñŜûŝî (Ð) 18:05, 30. Nov. 2009 (CET)

Bedauerlich ist allerdings, dass sich hier kaum einer meldet und es da wohl erst hinterher Einwände gibt, statt jetzt hier mitzumachen. ÅñŧóñŜûŝî (Ð) 18:07, 30. Nov. 2009 (CET)

Vom Aussehen her finde ich die neue Box in Ordnung, und ebenso bin ich auch sehr damit einverstanden, die Angaben aus dem Fließtext zu entfernen. Dabei handelt es sich ohnehin nur um eine überflüssige Dopplung. Was die zentrale Datenseite betrifft, bleibt die Frage bestehen, ob das wirklich mit den Prinzipien konform geht. Dass es so was bei den Einwohnerzahlen der Städte und Gemeinden gibt, ist eine Sache - da herrscht aber allgemein Konsens, dass alle Orte artikelwürdig sind und es handelt sich weiterhin nur um eine Datenangabe. Daraus folgt noch nicht zwangsläufig, dass es bei diesen Artikeln auch so gesehen wird. Das sollte unbedingt geklärt werden, bevor man sich daran setzt, alle Artikel zu ändern. Wäre ja schön, wenn das so ist, ich bin da aber immer noch skeptisch.

Das einzige, was ich mich noch frage: Welchen Umfang hat denn die zentrale Datenseite, bzw. welche Asteroiden sind darin enthalten? Sind es nur jene, die hier einen Artikel haben? Dann hätten wir nämlich das Problem, dass die Erstellung neuer Artikel zu Fehlern führt, da die Daten nicht verfügbar sind. Eine manuelle Eingabe ist ja nicht mehr möglich. Das ist unschön für den Autoren, da der Erfolg seiner Arbeit dadurch zweifelhaft wird, und ebenso für den Leser, der eine nahezu leere Infobox vorfindet. --seismos 18:23, 30. Nov. 2009 (CET)

Es ist aber doch ein Unterschied zwischen einem "Telefonbuch im Artikel" und einer Seite, von der man immer nur wenige Zeichen zu sehen bekommt. Es fragt sich auch, mit wem man das Abklären soll. Niemand hat hier die Rolle eines Chefs.

Ich habe an maximal ca. 10.000 Einträge gedacht. Es ist auch möglich, die alte Box zu erhalten und für den Fall, dass der Datensatz fehlt, diese automatisch zu nutzen. Da muss man nur noch regelmäßig die Einbindungen umstellen. Eine genaue Info für "Updater" schaft da Klarheit. ÅñŧóñŜûŝî (Ð) 18:52, 30. Nov. 2009 (CET)

Am besten wäre es, wenn Du mal ein Konzept in Worten formulieren bzw. dokumentieren könntest. Das muss sowieso gemacht werden. Soweit ich nun zwischen den Zeilen gelesen habe, hast Du bei der Umsetzung an eine Box mit oskulierenden Bahnelementen gedacht, die in gewissen, regelmässigen Abständen über eine Metadaten-Seite aktualisiert werden.

• Wer aktualisiert wie oft, was, wie?
• Wenn es sich um oskulierende Elemente handelt: Wo ist die Epoche? Wo steht, dass es sich um oskulierende Elemente handelt, woher sie kommen und wie sie geändert werden können?
• Wie werden neue Artikel angelegt?
• Wo ist die Lösung für das Problem mit der Rundung? (Ein Problem zu ignorieren ist übrigens keine Lösung.)

-- CHRV 09:44, 2. Dez. 2009 (CET)

Ok. Also in Worten: Aus dem Quelltext sollen die Werte heraus. Diese Doppelung ist nicht notwendig. Das Konzept der Infobox ist, wie du richtig erkannt hast, die Verwendung der osk. Elemente und die Aktualisierung aus einer Online-Quelle.

• Aktualisierung: Wie aktualisiert wird, kommt auf eine Beschreibungsseite, damit es mehrere User machen können. Es funktioniert bisher wie folgt:
  • Download der Daten, am besten von der JPL Small-Body Database Search Engine.
    Den String für die richtigen Einstellungen kann ich liefern, sobald Inhalt und Reihenfolge der Einträge klar ist.
  • Einlesen der Daten in eine Tabellenkalkulation.
    • Ein paar Extraspalten mit Wikisyntax einfügen.
    • Einstellen der allgemeinen Zahlenformate.
    • Speicher mit Typ "CSV", Feldtrenner "/" und Stringkennung leer.
  • Die Datei in einem Plaintext-Editor öffnen und ggf. alle Blanks in den Strings in %20 umwandeln. Das ist aber nur bei Objekten ohne Nummer nötig und kann evtl. auch noch vermieden werden.
  • Den Text in die Metadatenvorlage einfügen.
• Die Rundung kann man entweder in der Tabellenkalkulation mit Hilfe der Sigma-Werte oder den "Orbit Determination Parameters" vornehmen oder man baut es in die Wikivorlagen ein.
• Epoche habe ich noch nicht eingebaut, kommt aber noch.
• Für neue Artikel würde ich für den Fall, dass der String noch fehlt, als Lösung die bisherigen manuellen Parameter nehmen. Ich rechne nicht mit einer Flut neuer Seiten, so dass man die Werte nachtragen und die alten Parameter entfernen kann.

Sollte sich eine Möglichkeit finden, ein Programm zugänglich zu machen, welches die Rohdaten richtig gerundet in Wikitext umformt (z.B. auf dem Toolserver), dann geht es gewiss noch leichter. Ich bin davon überzeugt, dass man mit den vielen Angaben, welche man abrufen kann, die Werte korrekt runden kann. Das erspart die Tabellenkalkulation und das Nacharbeiten. Ich kann auch ein einfaches Programm schreiben und übergeben, aber das mache ich nur, wenn es sich abzeichnet, dass das System auch realisiert wird.

Die Epoche ist als Datum dargestellt, weil das besser WP:OmA entspricht. Wer das JD will oder braucht, geht sowieso auf eine andere Webseite. ÅñŧóñŜûŝî (Ð) 15:18, 4. Dez. 2009 (CET)

Sieht langsam besser aus.

Ich habe auch mal noch etwas daran rumgebastelt. Die Felder können nun überschrieben werden, etwa wenn es ein Problem mit den Werten, zum Beispiel der Rundung gibt. Ausserdem erlaubt dies den Benutzern, Artikel ganz normal anzulegen, ohne sich mit der Metadaten-Vorlage herumzuschlagen.

Für die Epoche sollte das JD noch in Klammer dazugeschrieben werden.

Was insbesondere noch fehlt, ist die ganze Dokumentation.

Darüber hinaus finde ich das massenhafte Einbinden einer Vorlage im Beta-Stadium nicht sehr sinnvoll. Zumal man dann an alle Artikel nochmal ran muss...

-- CHRV 17:26, 5. Dez. 2009 (CET)

Da hast du aber mal richtig losgelegt. ;-)

Mit dem Einbinden muss ich wohl etwas auf die Bremse treten. Es fängt halt an, in den Fingern zu kribbeln, wenn du etwas länger offline bist und ich hier so alleine bin ... ;-(

Was es die Epoche angeht, möchte ich auf keinen Fall zwei Werte auf der Metaseite. Daher würde ich das JD errechnen.

Die Metaseite habe ich übrigens mit 10000 Einträgen getestet und das ist wegen der Seitengröße wohl das Maximum. Ansonsten muss man aufteilen, was nicht so schön wäre.

Mit dem Überschreiben ist es möglich, nur die Werte für existierende Seiten zu nehmen. Das verringert die Größe drastisch. Da bedarf es noch eines Tricks, wie ich die Nummern der existierenden Seiten extrahiere.

Die "Small-Body Database Search Engine" ist m. E. die vavorisierte Quelle.

Eine Doku würde ich erst schreiben, wenn das System weitgehend fertig ist, ansonsten muss man wieder herumändern.

ÅñŧóñŜûŝî (Ð) 17:56, 5. Dez. 2009 (CET)

Welche Quelle man für die Daten nimmt, ist für mich nicht so entscheidend. Es gäbe sicher auch gute Gründe, z.B. mit MPCORB oder ASTORB zu arbeiten. Hauptsache ist, dass für den Leser - evtl. auch nach einem Klick - ersichtlich ist, woher die Daten kommen. Ich habe den Text unten in der Box mal etwas allgemeiner gefasst, er ist für meinen Geschmack sowieso immer noch etwas lang.

JD kann man errechnen, ist einfach etwas mühsam, vor allem mit der Vorlagenprogrammierung. -- CHRV 18:12, 5. Dez. 2009 (CET)

Ich glaube, da gibt es irgendwo bereits eine Konversionsvorlage. Ich schaue mal danach. ÅñŧóñŜûŝî (Ð) 18:21, 5. Dez. 2009 (CET)

JD ist drin. ÅñŧóñŜûŝî (Ð) 19:36, 5. Dez. 2009 (CET)

Ja, funktioniert, danke. Das mit dem Parameter "Nummer" hast Du ja auch gefixt. -- CHRV 22:48, 6. Dez. 2009 (CET)

Teil 4

Zwischenbilanz

1. Der Server kann die Seitengröße bis ca. 10.000 handhaben, zumal man notfalls auftrennen könnte. Eine möglichst kleine Seite ist anzustreben.
2. Schlüssel für den Zugriff ist die bei nummerierten Ast. die Nummer und bei den anderen der Bezeichner.
3. Zentrale Werte sind (in dieser Folge):
   1. Epoche als Datum
   2. Exzentrizität
   3. Große Halbachse in AU
   4. Inklination zur Ekliptik (Grad)
   5. Länge des Aufsteigenden Knotens (Grad)
   6. Argument des Perihels (Grad)
   7. Mittlere Anomalie (Grad)
   8. Mittlere tägliche Bewegung (Grad pro Tag)
   9. Periheldurchgang (Zeitstempel der Form YYYYMMTT.tttt)
   10. Periode (Tage)
4. Errechnet wird daraus:
   1. Epoche (JD)
   2. Perihel und Aphel
5. Für neue Artikel müssen direkte Eingaben möglich sein.
6. Umformung in regelmäßigen Zeitabständen, die nicht zu kurz sein sollten.

Noch zu tun

1. Suche nach einer geeigneten Methode, aus einem Download genau die Werte zu extrahieren, für die es Artikel gibt. Das minimiert die Metadatenseite
2. Frage klären, ob man für die Pflege den Toolserver nutzen könnte.
3. Festlegen, wie man automatisch unterscheiden kann, ob ein Objekt bereits zentrale Werte hat.
4. Als letzte Maßnahme eine Dokumentation erstellen.

ÅñŧóñŜûŝî (Ð) 11:10, 6. Dez. 2009 (CET)

• Zu Punkt 1 der Zwischenbilanz: Die Seite wird so gross wie notwendig (ggf. können / müssen z.B. auch Standardabweichungen aufgenommen werden). Man kann die Anzahl der Einträge begrenzen (gemäss Punkt 1 von "Noch zu tun"), aber nicht die Daten einer Zeile. Falls das nicht möglich ist, ist das Konzept der Metadaten-Vorlage aus technischen Gründen gescheitert.
• Zu Punkt 3 von "Noch zu tun": Entweder übersehe ich etwas oder ich habe Dein Anliegen nicht verstanden. Es ist doch ganz einfach: Wenn die Metadaten-Vorlage für eine Anfrage über einen Schlüssel eine Resultat zurückgibt, dann existiert für diesen Schlüssel ein Eintrag, andernfalls nicht. Wozu braucht man das überhaupt?

-- CHRV 12:15, 6. Dez. 2009 (CET)

Zu Zw. 1: Den "Record" kann man nicht beliebig klein machen, aber vielleicht ist es doch gar nicht so schlecht, die Seite zu teilen. Die populärsten Objekte auf eine relativ kleine Seite und den Rest in automatisch auffindbare Pakete. Dann liest der Server immer nur eine kleine Seite. Das ist gewiss kein großer Aufwand.

Zu ToDo 3: Wenn der Record fehlt, müssen klassische Parameter funktionieren.

Hast du eine Idee zu ToDo Nr. 1 ? ÅñŧóñŜûŝî (Ð) 15:31, 6. Dez. 2009 (CET)

Zu ToDo 3: Wenn die Metadaten-Vorlage für einen Schlüssel kein Resultat zurückgibt, es also für den entsprechenden Asteroiden keinen Eintrag in der Metadaten-Vorlage gibt, dann bleibt das zugehörige Feld in der Tabelle einfach leer bzw. wird gar nicht angezeigt, es sei denn, es wurde der entsprechende Parameter manuell in der Vorlagen-Einbindung gesetzt. Zu diskutieren wäre noch, ob ein unvollständiger Eintrag in der Metadaten-Vorlage erkannt werden soll und wie darauf ggf. zu reagieren wäre.

Der Vorlagen-Entwurf muss, wie ich sehe, noch entsprechend korrigiert werden. Momentan gibt die Metadaten-Vorlage auch dann ein Resultat ungleich dem leeren String zurück, wenn gar kein Eintrag für einen Schlüssel existiert. Das ist natürlich nicht besonders sinnvoll. -- CHRV 22:57, 6. Dez. 2009 (CET)

Zu Zw. 1: Schwierig... Ein Bot könnte wohl eine solche Liste erstellen. Eine andere Möglichkeit könnte es sein, die Liste der Vorlagen-Einbindungen zu parsen und für den erwähnten Filter zu verwenden. -- CHRV 23:04, 6. Dez. 2009 (CET)

Einen unvollständigen Eintrag zu erkennen, wäre wohl gut. Dabei sollte man es aber nicht übertreiben. Da sollte man nur prüfen, ob alle Felder Werte enthalten und ob die Zahlen im gültigen Bereich liegen. Als Reaktion würde ich den Record nicht annehmen, denn oft ist die Reihenfolge der Werte darin fehlerhaft. An einer Stelle, wo ein Winkel erwartet wird, taucht dann ein JD auf oder so ähnlich. ÅñŧóñŜûŝî (Ð) 23:09, 6. Dez. 2009 (CET)

Den Eintrag bei einem Fehler ganz zu verwerfen, erscheint mir auch sinnvoll. Was genau als Fehler angesehen werden soll und wie das am besten geprüft wird, bleibt noch festzulegen. -- CHRV 23:16, 6. Dez. 2009 (CET)

Bei den bisherigen Daten ist das recht einfach festzulegen:

Datum	1800 < Datum < 2020
JD	entsprechend
Exzentr.	0 < e < 1
Gr. HA	0 < a < 1100
Inkl.	0 <= i <= 90
Andere Winkel	0<= Winkel < 360

Andere Tests wären wohl sehr aufwändig. ÅñŧóñŜûŝî (Ð) 23:27, 6. Dez. 2009 (CET)

Ich würde es noch einfacher fassen. Es sollte reichen, zu prüfen, ob für jedes Bahnelement ein Wert gesetzt ist und evtl. ob es sich um eine Zahl handelt. Dass eine Einschränkung auf Wertebereiche nicht unbedingt sinnvoll ist, beweist obige Tabelle eindrücklich. Praktisch jede Zeile würde einen real existierenden Asteroiden ausschliessen. Dass die Werte stimmen, das ist die Verantwortlichkeit desjenigen, der einen Artikel schreibt. -- CHRV 09:45, 7. Dez. 2009 (CET)

Wieso schließen diese Wertgrenzen reale Ast. aus ? Die Winkel und die Exz. (geschlossene Bahn) können keine anderen Werte annehmen. Beim Datum muss man evtl. verzichten, um Objekte wie Sedna (Asteroid) nicht auszusperren. Die Verantworlichkeit ist aber richtigigerweise beim Autor. Mein größtes Problem bleibt aber die Extraktion von nur den Records, die einen Artikel haben. Ein Programm dazu müsste entweder auf den Toolserver oder anderweitig verbreitet werden, damit es mehrere User nutzen können. ÅñŧóñŜûŝî (Ð) 11:59, 7. Dez. 2009 (CET)

Wertebereiche: Die Exzentrizität kann auch den Wert 0 annehmen (Kreisbahn), was obige Bedingung ausschliessen würde. Die grosse Halbachse kann problemlos den Wert 1100 AE annehmen (zumindest gerundet, z.B. 2006 SQ₃₇₂) oder überschreiten (potentiell zahlreiche E-SDOs und OCOs). Die Inklination kann 90° auf jeden Fall überschreiten (z.B. 2008 KV₄₂ und alle anderen retrograden Asteroiden). Und wenn wir mal unvorsichtigerweise voraussetzen, dass die Welt 2012 nicht untergehen wird, dann sind auch Daten nach 2019 möglich... Dies zeigt, dass man bei der Festlegung irgendwelcher Wertebereiche, die Asteroiden vermeintlich nicht überschreiten können, sehr schnell Annahmen treffen kann, die mit der Realität nichts zu tun haben. Da unsere Information dahingehend bis auf weiteres unvollständig bleiben wird, sind solche Annahmen heikel und es macht wenig Sinn, Grenzen festlegen zu wollen, die wir nicht kennen.

Filter / Toolserver-Programm: Ein solches Programm ist zweifellos möglich. Es braucht nur jemanden, der es schreibt. Die Filterung bleibt auch so ein ordentlicher Aufwand, schliesslich muss die Filterliste, wenn man sie mal hat, dann auch noch irgendwie auf die von der externen Datenbank gelieferten Daten angewendet werden.

-- CHRV 14:32, 7. Dez. 2009 (CET)

Die Null bei der E. hatte ich inklusiv verstanden (Ein Typo beim Operator) und die retrograden Objekte haben auch nicht mehr als 180°. Egal wie, ich schaue mal nach dem Filterproblem für die Records. ÅñŧóñŜûŝî (Ð) 16:57, 7. Dez. 2009 (CET)

Ich will damit ja nur sagen, dass Vorsicht mit solchen Einschränkungen angebracht ist. Wenn wir da etwas übersehen, müssen es andere Benutzer ausbaden, die sich mit Recht über solche Spielereien bei der Vorlagenprogrammierung ärgern dürften. -- CHRV 00:08, 14. Dez. 2009 (CET)

Gewiss. Zum Thema Werte:

1. Es sieht nach einem kleinen Programm zur Aufbereitung aus. Wie distributiere ich das ? Geht das evtl. als PHP auf dem Toolserver ?
2. Du hast angeregt, auch die Sigma-Werte hinzuzunehmen. Dann sollten wir uns auch auf eine Formel zum Runden der Werte festlegen. Du kannst ja eine möglichst einfache beisteuern.
3. Sollte es ein Programm geben, dann könnte man die Werte auch vorher alle runden und dann in die Tabelle schreiben.
4. Zur Vermeidung unnötiger Seitenversionen sollten wir die Werte aufteilen: Die Asteroiden bis ca. 10 000 werden alle auf eine Seite geschrieben, egal ob der Artikel existiert Das erfasst mehr als 80% aller Seiten. Die Werte anderen kommen auf eine zweite Seite, wenn der Artikel existiert. Wenn klar ist, welche daten hineinkommen, kann man die erste mit Vollsperre schützen und die wesentlich kleinere zweite Seite (halb- ?) offen lassen. So muss man nur ab und zu die Werte updaten.

ÅñŧóñŜûŝî (Ð) 17:42, 15. Dez. 2009 (CET)

Zu 1: Ich bin ziemlich sicher, dass dies machbar ist. Ich habe zwar schon ein paar kleinere Sachen in PHP gebastelt, aber ich hatte bisher noch nie etwas mit dem Toolserver zu schaffen. Ich sehe mich daher ausser Stande, dazu etwas beizutragen. Bestimmt gibt es aber kompetente Benutzer, die da weiterhelfen können.

Zu 2: Ich wollte eigentlich nur ausdrücken, dass es zumindest grundsätzlich möglich sein müsste, die Fehler zu berücksichtigen (für die Rundung), dass da also keine technischen Einschränkungen bestehen dürfen. Ob, wie, wann das gemacht wird, ist eine andere Frage. Das kann ja grundsätzlich auch später noch nachgeholt werden. Folgende Überlegungen dazu meinerseits: Die oskulierenden Elemente liegen ja für die meisten Asteroiden des Hauptgürtels mit recht großer Genauigkeit vor. Hier ist es wohl vertretbar, generell eine mehr oder weniger zufällig gewählte Anzahl signifikanter Stellen anzugeben (z.B. 4 oder 5; man kann das ja auch in der Dokumenation klar deklarieren, dass diese Anzahl im Prinzip einfach beliebig gewählt wurde). Kritisch ist diese Frage vor allem bei TNOs. Dort kann man sich bis auf weiteres aber auch durch die Override-Variante behelfen.

Zu 3: Das wäre natürlich sehr praktisch.

Zu 4: Ich weiss jetzt ehrlich gesagt nicht genau, wie die Versionierung bei Mediawiki funktioniert. Ich will mal nicht hoffen, dass jedesmal eine Version in voller Größe der gesamten Seite anfällt, wenn eine einzelne Zeile geändert wird. Wenn das nicht der Fall ist, hat sich das Problem meines Erachtens erledigt. Betreffend Seitenschutz bin ich der Meinung, dass die Metadatenseiten stets frei bearbeitbar bleiben müssen. Wir sollten in der Dokumentation ausdrücklich festhalten, dass ein unbeschränkter Seitenschutz nicht erlaubt ist. Ich glaube nicht, dass eine besondere Gefährdung für die Seiten besteht und sehe deshalb auch keinen Grund für solch extreme Massnahmen.

Herzliche Grüße: CHRV 19:55, 17. Dez. 2009 (CET)

Wir haben genug Parameter, um TNOs zu erkennen und entsprechend zu reagieren. Ich schaue mal nach einer Berechnung. ÅñŧóñŜûŝî (Ð) 18:11, 18. Dez. 2009 (CET)

Toolserver

Eigentlich gehört das alles auf den Toolserver, aber ich befürchte, dass es zuwenig Mut gibt, um diesen Schritt zu gehen. ÅñŧóñŜûŝî (Ð) 11:21, 6. Dez. 2009 (CET)

Weshalb sollte das auf den Toolserver? Dafür sehe ich keinen Grund. -- CHRV 12:17, 6. Dez. 2009 (CET)

Ich meinte damit etwas, das bei diesen astronomischen Objekten (und ähnlich wohl auch bei anderen Themen) Sinn macht, aber hier in der WP soweit ich weis noch nicht existiert:

Es gibt zahlreiche Asteroiden, über die es nicht mehr zu berichten gibt als ihre astronomischen Daten, wer den Asteroiden wo entdeckt hat und evtl. die sogen. Aspekte. Es wäre sehr praktisch, wenn man, ähnlich wie beim Geohack, auf dem Toolserver ein Programm hätte, welches mit Hilfe der Online ertreichbaren Daten eine Seite mit einem Standartext, also quasi einen automatischen Ministub, erstellt. Diese Seite könnte man dann z.B. als Link auf einer Listenseite aufrufen.

Die dafür notwendige Textvorlage mit Platzhaltern könnte man projektübergreifend in nahezu jeder Sprache erstellen. Personen ohne Englischkenntnisse können die MPC- oder NASA-Seiten nicht lesen und wären gewiss froh über derartige Informationen. Jedes Wiki mit Zugang zum Toolserver und arab. Ziffern hätte dann für alle Asteroiden ohne Besonderheit einen Text. Die Möglichkeit, einen konventionellen Artikel zu schreiben, bleibt ja bestehen. ÅñŧóñŜûŝî (Ð) 15:18, 6. Dez. 2009 (CET)

Interessante Idee, aber der Zusammenhang zur hiesigen Diskussion erschliesst sich mir nicht ganz. -- CHRV 22:47, 6. Dez. 2009 (CET)

Das ist auch nur ein benachbartes Thema. Es kam mir in den Sinn, weil Ich die vielen Stubs gesehen habe. Ich erwähne es mal auf Portal Diskussion:Astronomie. ÅñŧóñŜûŝî (Ð) 23:12, 6. Dez. 2009 (CET)

Metadatenseite für den Spektraltyp

Die Spektralklasse habe ich für die neue Box (vorerst für die ersten 10000 nummerierten Ast.) zentral organisiert, um das "Gemenge" zu beseitigen. Bei denen sollte der Parameter Spektralklasse entfallen (wird hier nicht ausgewertet). Fehlt die Eintragung wird der Parameter Spektralklasse angegeben. ÅñŧóñŜûŝî (Ð) 23:07, 22. Dez. 2009 (CET)

Einige Bemerkungen zur vor kurzem gemachten Änderung, durch die alle Werte für die Spektraltypen durch diejenigen auf einer Metadatenseite (Vorlage:Infobox Asteroid 2/THOLEN) überschrieben wurden:

• Allgemein: Es wäre sinnvoll, sich jeweils zuerst ein Konzept auszudenken, es dann zu diskutieren und erst zum Schluss umzusetzen.
• Ich weiss nicht, wo die Daten für die Metadatenseite herkommen, aber es handelt sich offensichtlich um irgendwelche Datenbankwerte, die man dem Leser so nicht einfach hinklatschen kann. Man schaue sich mal (141) Lumen an. Was soll das sein?
• Wie ich bei früherer Gelegenheit schon erwähnt hatte, kann man die Werte in Infoboxen nicht einfach von einer Metadatenseite her ändern, ohne dabei jeden einzelnen Artikel zu überprüfen und anzupassen. Und bisher war nie die Rede davon, die Spektralklasse aus dem Artikeltext zu entfernen.

So wie ich das bisher einschätze, muss das rückgängig gemacht werden.

-- CHRV 23:09, 22. Dez. 2009 (CET)

1. Wenn es bisher eine Mixtur der verschiedenen Systeme bei den Angaben gibt, dann können wir das nur zentral managen. wir können nicht tausende Seiten nachprüfen. Das muss man ausprobieren um festzustellen, ob man überhaupt hinkommt.
2. Das sind die Werte für die Klassifikation vom JPL Small-Body Database Browser. Was soll daran falsch sein ?
3. Der Parameter Spektralklasse kommt zur Wirkung, wenn neue Seiten angelegt und hier ein Wert angegeben wird, vorrausgesetzt, der Asteroid hat keine Nummer < 10000. Man kann also neue Seiten anlegen.
4. Wenn es bei "(141) Lumen" nicht stimmt, dann ist es bei JPL falsch.

Warum also nicht ? ÅñŧóñŜûŝî (Ð) 23:46, 22. Dez. 2009 (CET)

Auf den wichtigsten Punkt meiner Bedenken bist Du nicht eingegangen: Wenn Du von zentraler Seite her alle Daten überschreibst, dann musst Du jede einzelne Seite nachkontrollieren, ob die Angaben in Infobox und Artikeltext übereinstimmen (was nach Deiner eigenen Aussage nicht möglich sei ("wir können nicht tausende Seiten nachprüfen")).

Es besteht kein Bedarf nach einheitlicher Verwendung einer Klassifikation. Jedoch besteht ein Bedarf nach einer brauchbaren Erklärung und Erörterung der Klassifikation eines Asteroiden im jeweiligen Artikel - gegebenenfalls auch mit Diskussion der Klassifikation in verschiedenen Taxonomien. Die Spektralklasse ist also ein klassischer Fall, der in den Artikeltext gehört und dort erläutert werden muss. Das kann nicht zentral passieren, sondern muss im einzelnen Artikel geschehen.

Die Werte sind nicht falsch. Sie müssen einfach interpretiert werden. Die von Dir verwendeten Daten stammen aus dem Planetary Data System (PDS) der NASA. Genauer von hier: [1], [2]. (Die Daten hat übrigens David J. Tholen höchstpersönlich für Dich zusammengestellt.) Das ist die Quelle für die Klassifikation von Asteroiden (und enthält Einträge für genau 1956 Asteroiden und nicht für tausende, insbesondere nicht für 10000). Diese Datensammlung verwendet für die Tholen-Klassifikation folgenden "Code": Jedem Asteroid wird aufgrund des taxonomischen Schemas ein Typ zugewiesen. Das heisst es kommt eigentlich für jeden Asteroid jeweils genau ein Buchstabe aus der Menge K = {C,B,F,G,S,X,E,M,P,A,D,Q,R,T,V} in Frage. Manchmal kann man aber das Spektrum eines Asteroiden nicht eindeutig einem Typ zuordnen. In diesem Fall werden die Typen z.B. hintereinander geschrieben (wobei die Reihenfolge eine gewisse Aussage über die Wahrscheinlichkeit der Zugehörigkeit enthalten kann). 'CPF' im Falle von (141) Lumen bedeutet also: "(141) gehört entweder zum C-Typ oder zum P-Typ oder zum F-Typ". Am Schluss der Buchstaben(kombinationen) aus K kann zur Klassifikation noch das Suffix U hinzukommen. U bedeutet: "Das Objekt hat ein ungewöhnliches Spektrum". Ferner können noch ein Doppelpunkt (:) oder zwei Doppelpunkte (::) hinzukommen. Ersteres ist ein Hinweis auf Rauschen in den Daten, zweiteres auf starkes Rauschen in den Daten. Die Zeichenfolge --- bedeutet, dass das Rauschen zu stark ist, um einen Spektraltyp zuordnen zu können. (Daneben gibt es noch Spezialfälle wie (515) Athalia, die aufgrund ihrer ungewöhnlichen Eigenschaften ein I erhalten hat.)

Wenn man dies weiss, kann man mit Angaben wir BFU:: für (282) Clorinde etwas anfangen. Dass nicht einmal Du, der Du ja wohl doch ein gewisses Vorwissen mitbringst, das gewusst hast, zeigt, dass diese Information für 99,99% der Leser bestenfalls eine Nicht-Information ist, schlimmstenfalls eine Desinformation. Ausserdem ist BFU:: kein Spektraltyp in der Tholen-Taxonomie (das sind die Buchstaben aus K). Solche Angaben gehören ausgedeutscht für den Leser in den Artikeltext.

Herzliche Grüsse: CHRV 18:17, 23. Dez. 2009 (CET)

Ich habe das sowieso erstmal deaktiviert (auskommentiert). Das mehrere Buchstaben bedeuten, dass es nicht eindeutig ist, habe ich nicht gewusst, aber vermutet. Die Doppelpunkte waren mir nicht klar. Im Web habe ich auch nichts darüber gefunden. bleibt die Frage, wie wir das Problem lösen.

ÅñŧóñŜûŝî (Ð) 19:27, 23. Dez. 2009 (CET)

Ich habe festgestellt, dass es so gut wie keine Seite gibt, auf der eine Angabe zur Spektralklasse im Fließtext steht. Wenn das der Fall ist, dann bei Artikeln über Asteroiden mit kleiner Nummer, deren Typ wohl relativ gut gesichert ist. Ich habe daher die Metaseite für beide Systeme wieder aktiviert und die wenigen Artikel auf Konvergenz überprüft. Bei den Asteroiden ohne Besonderheit muss diese Angabe m.E. auch nicht unbedingt in den Text hinein. Es ist die einzige möglichkeit, das Chaos bei den bisherigen Angaben zu ordnen. ÅñŧóñŜûŝî (Ð) 02:16, 9. Jan. 2010 (CET)

Ich sehe absolut keinen Grund, weshalb das nicht im Fliesstext erwähnt und / oder über eine zentrale Seite gemacht werden müsste und ich glaube, dass dies in keiner Weise dem bisherigen Diskussionsverlauf entspricht. Ich werde das rückgängig machen, falls Du keine geeigneten Argumente vorbringst oder sich ein breiter Konsens dafür findet. -- CHRV 07:03, 10. Jan. 2010 (CET)

Defaultsort

Gibt es irgendeinen Grund den Sortierschlüssel über eine zentrale Seite einzubinden? Ich sehe darin eigentlich nur Nachteile. -- CHRV 07:03, 10. Jan. 2010 (CET)

Seitenschutz

Wie bereits früher erwähnt, sehe ich bisher keine Veranlassung für einen Schutz der Metadatenvorlage. Im Gegenteil verhindert der Seitenschutz die Erstellung neuer Artikel (zumindest unter Verwendung dieser Vorlage) bzw. die Korrektur / Änderung von Daten in dieser Vorlage. Ich befürchte, dass dies der Qualität der Artikel abträglich sein dürfte, während mir die Gefahr der Metadaten durch Vandalismus eher gering erscheint. Wie bereits erwähnt, plädiere ich deshalb sogar dafür, den dauerhaften Seitenschutz explizit zu untersagen. Durch die Metadatenvorlage ist die Bearbeitbarkeit und damit eines der fundamentalen Grundprinzipien dieses Projekts schon genügend obstruiert. -- CHRV 07:30, 10. Jan. 2010 (CET)

Rückzug

Ich habe keine Lust mehr. Ich werfe das Projekt hin. ÅñŧóñŜûŝî (Ð) 18:23, 10. Jan. 2010 (CET)

SPK-ID

Die JPL-Datenbank benutzt die SPK-ID. Sollten wir diesen Parameter vielleicht in die "Vorlage:Infobox Asteroid" mit als optionales Eingabefeld aufnehmen? --Allexkoch (Diskussion) 13:07, 1. Sep. 2022 (CEST)