Wikipedia talk:WikiProject Astronomical objects/Archive table of asteroids

Asteroid ephemerides

An emphemerides ("aspects") of 2 Pallas was introduced by anonymous user 85.74.29.233 on July 7, 2005. Judging by the contributions, it looks like this user did the same for other asteroids. My feeling on this is that an ephemerides doesn't really belong in wikipedia. Since I can't find a suitable reference I'm thinking of removing it from the 2 Pallas page. Does anybody have an objection to this, or a good alternative? Thank you. — RJH (talk) 15:40, 20 March 2007 (UTC)

I think most people support this. Also, see the discussion on similar emphemerides up above. Dr. Submillimeter 15:47, 20 March 2007 (UTC)

e.g. I support removal of these tables. They serve no useful purpose as far as I can see, clutter the articles, and are often out of date. Anyway, would you use ephemerides seen on Wikipedia without checking the source first? Deuar 17:40, 20 March 2007 (UTC)

Yes, I can only believe these tables are none too useful for planning an observing/photography session. Probably it's there mainly for astrology usage. So we could always include the Horizons online ephemeris link instead. — RJH (talk) 21:22, 20 March 2007 (UTC)

I honestly do not believe the tables were for astrology myself. They were probably created by someone who wanted to show off their ability to program an ephemeris-calculating tool. User:Lunokhod has had some problems dealing with people like that. Anyhow, the link looks like a much better alternative. Dr. Submillimeter 22:20, 20 March 2007 (UTC)

Could be. Many of the web references I found on the subject of asteroid ephemerides seemed to be related to astrology, so I just assumed... If the data is legitimate astronomical information then possibly it would make more sense to transwiki it to wikisource, for example. There is an astronomy category. Would the name "Asteroid aspects" be suitable? — RJH (talk) 20:47, 21 March 2007 (UTC)

aspects of asteroids

A whole lot of asteroids appear to have these ephemerides sections attached to them. See asteroids starting at #10, and continuing on and on and on. 132.205.44.134 21:40, 5 April 2007 (UTC)

These lists are horrible. Just delete them. (They only go up to asteroid 96.) Dr. Submillimeter 00:31, 6 April 2007 (UTC)

Thank you, I completely agree. — RJH (talk) 17:03, 6 April 2007 (UTC)

Astrological aspects for asteroids

More "Aspects" tables have been showing up on various asteroid tables. (They show on a wikipedia search for the keywords "aspects asteroid".) I believe there was a prior consensus that they would be removed as non-encyclopedic, among other objections. Anyway, hopefully nobody will object if I start ripping those out where I find them. — RJH (talk) 22:54, 14 June 2007 (UTC)

Go for it. Dr. Submillimeter 23:02, 14 June 2007 (UTC)

Done, at least for the moment. — RJH (talk) 16:44, 17 June 2007 (UTC)

Asteroid bot

Hello. My friend, Eagle 101, and I have created a bot that would create articles in userspace with infoboxes from public domain NASA data, and I was hoping the Astronomical objects Wikiproject would support it. Additionally, we would like to know if any additional sources of data are available, and if it would be wiser to go ahead and just run the bot in the article space. Thanks. Daniel Bush 06:40, 9 October 2007 (UTC)

Please note it is also very possible if we choose to, to do a rambot like generation of pages. There is enough data here I can probably get up to 4-5 automated sentences. —— Eagle101^{Need help?} 17:45, 9 October 2007 (UTC)

Oppose The overwhelming majority of these asteroids are not notable. There are plans underway to group together several asteroid-spotting observatories into a single summary/list page, since the observatories themselves apparently aren't notable enough to warrant individual pages. So certainly the asteroids discovered by these observatories don't each deserve a page. --Sapphic 18:44, 9 October 2007 (UTC)

Ok, then in that case tell me what the criteria are and we can have the bot do it that way. (by observatory or whatever). I already have the bot grabbing the data, so the formatting and layout won't be all that hard. Please also note this is a discussion, not a vote. I won't run the bot until we have addressed any and all concerns, but this bot is capable of creating all the infoboxes etc, which by the looks of it are a PITA to do by hand. —— Eagle101^{Need help?} 19:50, 9 October 2007 (UTC)

To be honest, I don't see much discussion there, and the stuff there is over a month old. If there is actually discussion on this topic please point me to it (all that is is the most wanted pages)... Otherwise lets figure something out. —— Eagle101^{Need help?} 20:24, 9 October 2007 (UTC)

Hey, don't get me wrong. I'm in favor of automated generation of content in cases where it actually works as well as (or better than) what humans can do — and I think this is one of those cases — but I'm trying to prevent you from doing a lot of work only to have it undone by some deletionist. I don't know squat about astronomy and so couldn't tell you what makes an asteroid notable, but I think you'll find out from people in related projects that it's not something that lends itself well to automation (it never is.) Wikipedia just isn't well-suited to bulk content creation (yet.) I spend my time helping to update the lists and reports that are generated through analysis of the database (XML) dumps. In the past, I've processed the content of not-yet-rated biographies to sort them into classes like "probable stub" and "potential b-class" and such, to help speed up the reviewing process. My point is that there are other ways to contribute your programming skills and machine time that don't involve mass generation of questionable pages, and I'd suggest pursuing one of those instead. Otherwise, good luck with creating all those pages and don't say I didn't warn you about the likely response :) Cheers, --Sapphic 21:58, 9 October 2007 (UTC)

NOTE: Sorry about that confusing last paragraph.. I was mixing up who I was talking to. I thought Eagle 101 was the original poster until just a moment ago. Most of my comments were actually meant for Daniel Bush. Elsewhere he has proposed creating an article for every single asteroid, which I think would meet with a lot of opposition and possibly sour him on contributing such effort in the future (which I think would be a shame.) --Sapphic 22:14, 9 October 2007 (UTC)

I'll say that I'm opposed to this idea. For the moment, the list of asteroids serves the purpose of providing basic information, while articles can be created for the more notable objects. This is wikipedia not wikicatalogue after all... mail merge letters are bad enough, mail merge encyclopaedias should be left as a purely theoretical concept. BTW as one of our resident deletionists, I'd like to say there's nothing wrong with deletionism :-) Chaos syndrome 22:09, 9 October 2007 (UTC)

What if we agreed only to create articles on asteroids over 50 kilometers in diameter? Daniel Bush 01:45, 10 October 2007 (UTC)

Ok, lets ask this question... what makes an asteroid notable? Is it size? How about how bright it appears in the sky? Do we have guidelines as far as what is an important and "notable" Astronomical object? Lets hammer/figure those out first, then come back to this. The main benifit of the bot is it can generate these info boxes much faster then any human can, however I agree, we should not create 100,000 articles either. Deletionism has its place :) —— Eagle101^{Need help?} 02:00, 10 October 2007 (UTC)

Are we talking about asteroids, or asteroids and KBOs and other things with MPC numbers? If it's an cis-Jovian asteroid, magnitude, year of discovery, size, and notable events all should come into it. If it's a trans-Neptunian, all that plus roundness. I should think. All NEOs should probably count. 132.205.99.122 19:00, 11 October 2007 (UTC)

I mean all things with MPC numbers. But what if we only did numbered minor planets with official names? That would cut the number of bot articles down to 13,889. Daniel Bush 06:07, 14 October 2007 (UTC)

I had a few criteria in mind. The Asteroid is notable if it...

1. ...was discovered directly, before the advent of astronomical photography.
2. ...has recently passed close to the Earth (< 1 million km).
3. ...has been directly imaged in detail by a spacecraft or telescope, or it has been the subject of an occultation observation program.
4. ...has been the subject of a scientific journal article or news story.
5. ...is the largest or most massive member of its family.
6. ...has been identified as the source of an Earth meteorite.

— RJH (talk) 20:56, 18 October 2007 (UTC)

Asteroid articles

I've just copied this fromthe Project Astronomy talk page, as it surely belongs here aleo. Wwheaton (talk) 02:51, 25 May 2008 (UTC)

User:Captain panda has been creating thousands of stubs on named asteroids, see Special:Contributions/Captain_panda. There's some discussion above about this, but can we reach a definite consensus? I'd think the lists like List of named asteroids (A-C) could be tables containing the information currently in these stubs. Having 10s of thousands of stubs about asteroids seems like an invitation to vandalism to me. Is anyone really going to watchlist all of these articles? I'd be OK with keeping them as redirects into the right line of a table in one of the "list of" articles, but keeping each one as an "article" seems well on the other side of pointless (to me). -- Rick Block (talk) 02:26, 25 May 2008 (UTC)

I volunteered to watch a few, with some misgivings, under the hope that they would seldom change and not take much effort, but I really do think it is madness. Where do we stop? There are excellent tables at JPL and the Minor Planet Center that are maintained by professionals (and constantly updated by funded computer systems!), and how can or should we compete with those manually when tens of thousands of objects are at stake, and hundreds of thousands are obviously in store due to the NEO and LSST programs? We would not try to do this for stars. For asteroids, let us have some minimal criteria of notability, beyond being an entry in a catalog. If we just limit it to objects that require some words describing why they are interesting, and a reference or two, I think that will give us all the articles we need, and likely more than we can handle. I am sorry to undercut user:Captain panda's enthusiasm, but I really think it is necessary. Wwheaton (talk) 02:46, 25 May 2008 (UTC)

The kind of table I'm suggesting would look like this (the exact content in the table is of course subject to discussion):

Name	Alternate name	Group	Discovery date	Discoverer	More information
20813 Aakashshah	2000 SB274	Main-belt	2000-09-28	Lincoln Laboratory	JPL Small Body Database
677 Aaltje	1909 FR	Main-belt	1909-01-18	August Kopff	JPL Small Body Database
2676 Aarhus	1933 QV	Main-belt	1933-08-25	Karl Reinmuth	JPL Small Body Database

Which includes anchors for each line, so links like #20813 Aakashshah, #677 Aaltje, #2676 Aarhus would work (meaning the articles could be redirects). With this format, in cases where there is substantially more information available than "this is an asteroid" the name could be a link to a non-stub article (to show the format, I've made the first entry such a link). The concept here is that the bulk of the thousands and thousands of stubs would be redirects into a table like this, without eliminating the possibility for articles to be developed about individual asteroids. -- Rick Block (talk) 15:42, 25 May 2008 (UTC)

What defines having an article being in the proposed table or being an article? I can still add infoboxes and things like that to the articles that I have created in order to add more information to them. I do not want the articles I have written to be deleted and I am willing to improve each and every one of them if it prevents them from being deleted. Captain panda 20:43, 25 May 2008 (UTC)

While I believe that we might be taking it a little too far, I also agree with Captain Panda that articles like this that are created have the potential (however slim it may be) to be expanded. They should not be deleted, as all of them are named. If I remember from the List of asteroids (the big one), it said that only 24,000 or so of all asteroids that have been discovered are named. What if we were to create the notability criteria that they have to be named asteroids in order to get them to stay on here? Would that work? Cheers, Razorflame 21:05, 25 May 2008 (UTC)

The last ten of these that were created are: 14834 Isaev, 14812 Rosario, 14104 Delpino, 14077 Volfango, 14032 Mego, 13643 Takushi, 13477 Utkin, 13176 Kobedaitenken, 12999 Toruń, 12838 Adamsmith which all say:

<insert name here> is a main belt asteroid with an orbital period of <insert period in days here> days (<insert period in years here> years).

The asteroid was discovered on <insert date here>.

References

<link to JPL Small Body database here>

The only content here is the name, the group (main belt), the period, the discovery date, and the link to JPL - all of which could be included in a tabular format. I'm suggesting changing articles like these ten to be redirects to such a table (not deleting them). The redirects would be replaced with articles for any asteroids about which an article could be written. Facts recited from a database, even with an infobox replicating all the information in the database, does not an article make. What's the problem with including the information content in tabular form? -- Rick Block (talk) 22:58, 25 May 2008 (UTC)

I like the table a lot, but I would like it even more if some additional data were given. Of course there is a column space problem, if it gets too wide. My personal favorite items to add would be semi-major axis a  (in AU), eccentricity e , inclination i , period (in years, but slightly redundant with a ), and either absolute magnitude or estimated size and albedo when IR data are available. I think the date of discovery might be reduced to just year, and the discoverer could be dropped, as the most famous ones will have a separate article anyhow. Also, the group (main-belt, etc) has some overlap with the orbit data, so maybe we would not need both, but spectral class would be nice. (For a complete definition of a Keplerian orbit, we would need six numbers: a , e , i , plus node, argument of perigee, & anomaly, all at some epoch time.) The "More information" link could be shortened to "JPL SBDB" or MPC, or even placed as a footnote if we do not need the option of both (but then to get the page or data for a particular object, we would have to put the link in the orbit data or somewhere else for that line).

Re notability, I believe asteroids get a number when the orbit is well-determined, before that they just have a year & letter code. Maybe a name is a reasonable criterion for a separate article. The the article could then at least tell the story of the name, which would seldom fit in a table. But I'm not really advocating mass deletion of the articles User:Captain panda has created. Even among the numbered ones (& maybe even some of the more famous pre-numbered variety), that have remarkable properties, or orbits, or appeared dangerous for a while, etc, whenever there is important information that does not fit into whatever table format we settle on, that would be a clue that a separate page may be called for. Also, if there is anyone in our project who has contacts at JPL or MPC, it might be a good idea to solicit input from them as to what would be most appropriate here in the light of what they are doing and their plans for the future.

This latter is an important consideration, I think, as what with the NEO concerns and the LSST on the way, there really will be an explosion in numbers that will likely tax our ability to keep tabs and maintain the information correct and up-to-date if we are not thoughtful. For example, I believe there is some provision at MPC for computer maintenance of the tables, including updating orbit computations based on recently submitted observations, with minimal human intervention. Even keeping the table current could be a chore in the worse case scenarios. (NB there may be copyright restrictions on actually reading external data automatically and putting it into our table.) Wwheaton (talk) 23:28, 25 May 2008 (UTC)

I don't think there's any reasonable way to include a,e,i,etc. without making the table overly wide or using a show/hide sort of approach. Using show/hide, this might look like the following (note there are 2 physical lines per entry since show/hide seems to introduce a 2nd line):

Name	Alternate name	Group	Discovery date	Discoverer	Orbital/physical characteristics	More information
20813 Aakashshah	2000 SB274	Main-belt	2000-09-28	Lincoln Laboratory	Data table H: 14.4 a: 2.6767409 e: 0.1117672 i: 2.98933 Node: 196.60418 peri: 307.92848 M: 164.07487 Epoch: 3871.4664786	JPL SBDB
677 Aaltje	1909 FR	Main-belt	1909-01-18	August Kopff	Data table H: 9.70 a: 2.9548394 e: 0.0497858 i: 8.48963 Node: 272.90478 peri: 280.18136 M: 123.27949 Epoch: 3965.1872566	JPL SBDB
2676 Aarhus	1933 QV	Main-belt	1933-08-25	Karl Reinmuth	Data table H: 12.8 a: 2.4032459 e: 0.1263205 i: 4.55345 Node: 289.75298 peri: 45.51728 M: 12.54766 Epoch: 4553.0696866	JPL SBDB

I'd be willing to write some code to construct tables like this (based on the data at JPL or some other available source). -- Rick Block (talk) 01:10, 26 May 2008 (UTC)

Here's my cut at a table, for the same three objects Rick Block has done above:

No. / Name	Alt. Name	Year	H	a	e	i	Node	Arg Peri	Anom. M	Epoch TJD	Full data
20813 Aakashshah	2000 SB274	2000	14.4	2.6767409	0.1117672	2.98933	196.60418	307.92848	164.07487	3871.4664786	JPL SBD
677 Aaltje	1909 FR	1909	9.70	2.9548394	0.0497858	8.48963	272.90478	280.18136	123.27949	3965.1872566	JPL SBD
2676 Aarhus	1933 QV	1933	12.8	2.4032459	0.1263205	4.55345	289.75298	45.51728	12.54766	4553.0696866	JPL SBD

I have included the absolute magnitude H, and the six principle orbital elements. In order for the orbital elements to be meaningful, it is also necessary to give the epoch time when they apply, since M changes rapidly and the others may also change, though usually very slowly. In order to save column space I have given this as Julian Date - 2450000.00. The choice of 2450000 will work for epochs from around 1995 to ~2023. (I am just guessing all the data at JPL have been generated for epochs since 1995, but there might be a few with no recent observations that are earlier.) There would need to be an explanatory header at the beginning defining all these, or a footnote at the bottom.

I have just copied the values from the JPL pages, but I actually am in doubt whether we need to have quite so many digits. Anybody doing high precision work is likely to go to the JPL tables directly anyhow, and I suspect we could get by with about 6 digits for the six primary orbital elements, and 7 or 8 for the epoch. This would save ~12 to 15 spaces. I have omitted the nominal size and albedo because these are not available for the newer objects, since they need photometric observations in visual and IR. We could add them if we think we have the space, and don't mind leaving them blank when unavailable.

The orbital period is redundant with a, but so useful I think it might be added also, in years to say, 3 digit accuracy. It seems to me we have the space if we reduce the accuracy on the orbit elements a bit. I dropped Group as largely redundant with the orbital elements; if we want to re-instate it I think I would put it in as a 2 or 3 character code, (eg, "M-B"), with an explanation decoding it in the footnote. Spectral class could be treated in the same way; it is not available for most objects. I reduced date of discovery to just Year, since it seems to me that it really only tells us if an object may have lots of (likely lower-precision) earlier observations or not. I also thought the discoverer was of marginal scientific interest, and therefore punted that.

My goal here has been to put the data in a form that can be used quickly by anyone looking for moderately accurate information about the main properties, in a format that could be read by computer for some statistical purposes, or even to generate rough (arc minute?) ephemermis info, but not good enough for high-precision positional work. Anything that drastically breaks the table format we choose -- whatever it is -- should likely have an article with the details in any case.

Being unfamiliar with the coding, I have given no consideration to the difficulties in generating a table, for thousands of objects, in this format. It may be impractical, in which case I bow to the necessities of the case. Anyway, let me know what you think. Bill Wwheaton (talk) 16:01, 26 May 2008 (UTC)

A possibility for group is to have the lists be by group, in which case it would not be needed. I'm not an astronomer so don't really have any basis to comment on the information content - although truncating digits doesn't seem like a great idea. I've revised the show/hide table above to include the same content (in a data table that appears if you click "show"). I guess the question is what would be the intended use for these tables? Is anyone likely to want to print the tables for reference, or search for an asteroid with (say) some specific eccentricity? If yes, making the data always visible is probably a good idea. My goal is to obviate the need for most of the stub articles - in which case I think the content in the table entry should match or exceed the content included in these stubs. Another consideration is the accessibility of the wikisource. The show/hide version is considerably more wikisource (and fairly complex wikisource as well).

Regarding generating these tables - I don't think any well defined format would be significantly easier or harder than any other. Truncating digits would be slightly more difficult than not, computing epoch differences relative to some Julian offset would be slightly more difficult than not (and, unless this is very commonly done I'd think we probably shouldn't) - but overall neither of these would make a significant difference in the coding effort.

I think regardless of whether we change most of the stubs to be redirects it would be worthwhile creating data tables. Let's agree on a format and see where it goes. -- Rick Block (talk) 17:39, 26 May 2008 (UTC)

Not much comment from others, let's wait a bit more on the format issues. I am working in astronomy, though not on asteroids. It would be nice to get some other experienced opinion. I do think it would be good if we could have the table(s) computer readable, so people could do searches and statistics. I think the full precision of the best determined orbits would only be necessary for someone doing long-term high-precision orbit calculations, as for collision prediction, and that requires such complex orbit extrapolation programs that anybody doing it will go to the horse's mouth for data anyhow. Truncation of Julian dates is widespread for convenience, the main question being what is the actual range of epoch times that occurs. I may ask David Morrison, Steve Ostro, or some of other experts to render an opinion if we don't get some more input here.

Anyhow, what about the issue of Captain Panda's 10,000 stubs? How do they get updated as new observations come in (and how do our tables, for that matter) and protected against vandalism? I think the tables should maybe be semi-protected, to restrain mischievous junior high students (bless them, of course), but I have no idea about the problems of doing that for so many articles. Otherwise I think I would be in favor of letting them be; some truly are notable, and will get filled out, others will perhaps wither unless we can figure out a way to update the data. I must say, I hope more than four people are thinking about this! Wwheaton (talk) 05:53, 29 May 2008 (UTC)

I'm no asteroid expert, but I think the table looks fine. As for my asteroids, I am in the process of adding infoboxes to each of them, but I suppose that it will take a few months or longer to complete adding of the infoboxes for each article that I wrote. I've only written 1,000 (as opposed to 10,000) so it can be done. If necessary, I can add the articles that I have written to my watchlist and keep an eye on them for vandalism. The articles don't get edited much so it wouldn't be much of an inconvenience. Captain panda 12:57, 29 May 2008 (UTC)

It should be pretty easy to build a wiki template that links an asteroid name (on the list of asteroids pages) to the JPL Small Body Database entry, for those cases where an article doesn't already exist. That should be sufficient for 99.999% of the asteroids discovered.—RJH (talk) 18:30, 29 May 2008 (UTC)

Oh dear. I was already in quiet despair about the over 10k of these that had already been created, I believe mainly by a run of CobiBot_II. Those were bad enough, but these seem to be seriously content-free. I can't see what purpose they serve as articles, and from a stub-sorting point of view they seriously swamp the much smaller number of stubs-with-possibilities, and what's more seem to be effectively "unsortable": lacking data like spectral type, there's basically no way to split these up into more manageable chunks, at least that I can see. (If someone has any ideas on this that are workable, I'll be their friend for life and biggest fan.) Put me down as being in favour of merging to some better-integrated format, though I have no strong opinions as to what that should be. I might also be able to help out on the automation front, once it's clearer what's required there. Alai (talk) 17:44, 8 June 2008 (UTC)

I have been passively thinking about this and can not think of a great solution. But I think it is kind of pointless to have 10k+ form letters for asteroids. These form letters will not have current orbital data and are no match for the JPL Small-Body Database Search Engine. We still have major asteroids like 451 Patientia that still do not have an infobox.

When I start an asteroid article I do it like I did for 2007 VL305, 2004 VN112, 14827 Hypnos, and (137108) 1999 AN10. They are more useful than a form letter. -- Kheider (talk) 18:18, 8 June 2008 (UTC)

As just some dude who came hunting for this discussion after hitting one too many asteroids on random, I have to say that the proposed solution by Rick Block (or something very similar) is almost exactly what I had in mind when I stumbled in here. Whatever drawbacks this proposal has, I'm 100% sure it beats letting things go on as they have been. I am very pleased to see that this matter is getting the attention it deserves, and will be keeping an eye on this discussion. J293339 (talk) 21:58, 8 June 2008 (UTC)

We have at this point inputs from seven or so people. I am still hoping for more comments from interested editors. But before too long we need to converge to a definite proposal, with all the loose ends thought out, so it makes sense and actually works. It seems to me we are fairly well agreed we would like a table of essential information, for as large a number of asteroids as Wikipedia & practical folks like Alai (talk) can cope with, which I think should restrict us to just one line per object (? there will be over 10,000? lines already, and very likely 100,000 lines in five years or so), in order to avoid having an equal number of articles, one per object. I would like very much for the table to be in a format can fairly easily be read by computer, or which can easily be used to make a computer-readable one, on the theory that it is likely to be used for studies of asteroids as a class, rather than individually.

One concern I have is that even the table may be too big for Wikipedia to be able to handle easily. Another is that if we are going to put any precision information into it (eg, orbit data) then we have to be able to maintain it, which means updating thousands of entries as new observations come pouring in. Clearly we cannot do this by hand, and it would be a disservice to the community to make a static table, which was immediately out of date and therefore more and more untrustworthy with the passage of time. The same problem comes up for the 1,000 (or 10,000 ?) separate articles, of course: how are those data going to be kept up to date? Even without vandalism, this is a serious problem. If we cannot come up with a good solution to the maintenance problem, then I think maybe we should give up and try to provide instead the most useful possible links to JPL and Harvard MPC, where this is already done well by computers and full-time paid people. The maintenance problem becomes a bit less severe if we are willing to settle for slightly less accurate data (? 6 or 7 digits, I would think ?), because the more precise the data are, the more often they will have to be updated.

Re sorting (Alai (talk)'s bane...) I think we almost have to do it by asteroid number, because if we do it any other way, we will constantly be having to insert new lines as new objects are discovered and classified, and I think it would be vastly easier to only add to the end of the table rather than having to resort and rebuild it again and again. The only reasonable alternative I can see would be to sort by period (which is equivalent to semi-major axis a , of course), as that corresponds very roughly to orbit family, and is probably the most stable property with time (again as new observations come in) and will hardly ever change beyond the last digits. Low-precision things like size estimates, H magnitudes, spectral class, etc, will change much more often as better measurements are made, affecting and re-shuffling the entire table.

I really think we should ponder hard whether this is a reasonable thing to do at all, in an encyclopedia for general readership, if we only duplicate (& not as well) the professional work being done elsewhere. I hope everyone will think carefully about this scope issue. Once we have more clarity about what we want, then I think we should ask some professional folks from the asteroid community to look over our plan and tell us if we are about to do something useless, doomed, or really stupid, given the size and complexity of the problem. Wwheaton (talk) 07:38, 10 June 2008 (UTC)

• Merge them at best to a list. The 10K+ substubs about non-notable or barely-notable asteroids are really clogging up several parts of the encyclopedia. Stifle (talk) 08:05, 10 June 2008 (UTC)

How do articles interfere or clog one another? I don't see how the asteroid articles would negatively affect any other articles. Captain panda 14:40, 10 June 2008 (UTC)

Well, just as an extreme example that may help make the point, suppose we were to try to have articles for stars. We could then go to the 2MASS or USNO catalogs and generate (hundreds of) millions of articles with a detailed map of the galaxy in 3d (4d actually, since stars move...), star by star. No doubt that will be what we will want to do in a century or a millennium, but right now it would crash our search engines and overflow our buffers. Wikipedia has "only" 2.4 million articles, after all. The problems are practical and tend to be rather grubby, yet very real. I do not have to deal with the practical problems personally, but experience suggests some caution is wise. We do not want to make Alai (talk)'s life miserable.

The first practical problem here, for articles or for a table, is maintaining the information current. For every asteroid there are a hundred or a thousand discrete observations of the star-like object, that are fit to a very complicated celestial mechanical orbit model to generate the set of orbit parameters that best fits those observations for that object. These orbit parameters would be strictly constant for pure Keplerian motion, of course, if we had perfect observations, but there are perturbations and the observations are not perfect. So if this week six astronomers call in with 20 new observations, you have to rerun the fit program and generate a new set of best-fit orbit parameters, taking into account the effects of Jupiter, and Saturn, and .... JPL & the MPC do this routinely, I think observers can send in new data electronically and it gets run almost without human interaction, and their tables are updated. So all these precision orbit elements are going to change in an erratic, irregular way. Most of them will not change very much (in the 5th decimal place?) very often; 99942 Apophis is certainly going to change radically in 2029; and a fair number (hundreds?) will be changing more than a smidgen but not so drastically. So the information in the articles is going to go stale steadily as time goes on, in a complicated and erratic way, but more and more like an avalanche in the next decade as the flood of new data comes in. Even for just the 10,000 objects we have, there will be many many new (and better) observations because there are faster and deeper sky surveys, both for science and Earth protection against NEOs. Spitzer sees some asteroids in almost every observation near the Ecliptic. LSST will crash us for sure. I am not saying we should delete all those new articles, at the least discretion is needed. But seriously, Captain panda, your effort has been quite heroic and even noble; but ask yourself how you propose to deal with this issue? And as Alai (talk) points out, there are other problems we have not even thought of. I suppose this is just the agony and the ecstasy of astronomy. I know for a fact that the 2MASS all sky survey was deliberately and carefully designed not to be too sensitive, lest it crash the computers that were available (when it was specified and designed) to analyze the 25 TBytes of data they took. Because computers are getting better so quickly there is great hope for the future in this direction, but still our plans for data presentation need to take account of current realities, in both human and computational terms, and advance together.

Apologies for this windy & no doubt tedious tutorial, but everybody here needs to have some understanding of these issues. Wwheaton (talk) 20:59, 10 June 2008 (UTC)

Sorry if it sounded like I was being confrontational. Admittedly, it would be quite impossible to write an article on every star found currently. I think it would be enough to have articles on the named asteroids. What I had in mind is not very different from what everyone else is suggesting. I am fine with the idea of a table (although I am not sure how much info to put on it). I just think that each named asteroid should have an article. I am working on adding infoboxes to the articles that I have created and hopefully will finish eventually. Just clarifing my thoughts. Captain panda 01:54, 11 June 2008 (UTC)

And I apologize if I seemed to be beating you up, in any sense. I have no problem with an article for each named asteroid, as long as the human labor of updating the material does not make it impractical. That probably boils down to the question of whether we can devise a scheme for automatically updating the infoboxes from the JPL/MPC master files, and whether that is legal (I think MPC may have copyright restrictions, so there may be problems there, but I am not certain) and practical. Much the same problem arises with regard to the table(s). With either the issue could be made less severe by reducing the number of digits we give in the orbital elements, so that significant  changes are less frequent.

Or, we could just reduce the number of objects in the articles & table until we can maintain them manually with the human resources we have available. It seems to me that these issues need further research before we can make an informed decision. I am going to ask around here (IPAC) and JPL and see if I can get any advice from folks who really know the story. Best, Wwheaton (talk) 03:02, 11 June 2008 (UTC)

Re comments on the difficulty of maintaining the asteroid articles, I must point out that all our other articles also pose maintainability issues. I see no reason to single out asteroid articles in this respect. Spacepotato (talk) 02:25, 11 June 2008 (UTC)

So to summarise where we are with these: no-one wants them, no-one is ever going to expand them with useful level of detail, no-one knows what to do with them once we have them, but Captain panda is continuing to create them anyway. Admittedly the situation was already so bad given Polbot's efforts that this makes very little difference either way, but it certainly dispels any possible illusion or hope of progress. I suggest we proceed on one (or both) of the following bases:

• • AfD a sample count of CP's articles, in order to get rid of the "inherent notability" argument. Then merge and redirect all the rest that are similarly content-free;
  • Retag the existing Category:asteroid stubs and Category:Main Belt asteroid stubs, not according to spectral classes and orbital groups, as I've been trying to do thus far, but on the basis of meaningfulness of content. If we get the articles that some meaningful editorial effort has gone into separate from the ones created by bot or semi-bot activity from database entries, then we can keep the former in the "real" stub category, ignore the latter for stub-sorting purposes, declare victory, and go home. (Precise terminology for these not-even-actual-stubs categories to be determined.)

Does that make any sense to anyone else? Alai (talk) 22:52, 27 June 2008 (UTC)

Is it practical to delete articles that have never been edited (or created) by a human editor? I personally would hesitate to delete something a human has worked on. Re the sorting problem, the two viable candidates I think of are:

• • • (1) object number (never changes; roughly corresponds to size and prominence, that is ease of detection; and finally to chronology--date that a good orbit was first established),
    • (2) orbital semi-major axis a  (essentially though not strictly constant; corresponds to orbital period, and also, roughly, to family, as main-belt, Trojan, resonance gtoup, etc; and also to orbital energy per unit mass)

It seems to me this may be essentially what you (Alai) are suggesting above? I still suppose we would like to make a summary article with a table if this is deemed practical. No response yet from my first (feeble) attempt to get suggestions from the asteroid community. Will keep trying. Wwheaton (talk) 00:27, 2 July 2008 (UTC)

It'd be doable in theory, but it'd require an adminbot that's aware of article history, of which mine is neither. Though just listing candidates, or turning such articles into redirects, wouldn't require an admin bot, of course. But the latter would make more sense to do after creating the merged/summary articles, I'd imagine. The actions of "Captain panda" create a difficulty here, since he's a human editor, but he's creating lots and lots of very "templatey" articles. Alternatively, it could be done by matching against article-text templates, to allow for redirecting articles that might have undergone very minor (or schematic) edits by humans, but are still lacking any significant individual pieces of text or data. And we'd have to get consensus for the bot doing such a thing, of course.

Regarding splitting by orbital number, over at WPSS, one of m'colleagues has suggested much the same thing. If no-one objects, then, what I'll start to do is to split the articles that lack any usable group, family, or spectral class data on that basis, and leave the somewhat more detailed articles, that hopefully have received and will receive more in the way of individual attention in the existing categories, or split them out by group/class as becomes feasible. Please comment over there on that aspect of the situation. Alai (talk) 20:58, 7 July 2008 (UTC)

Returning to this discussion, I just found that these articles are doing a marvelous job of clogging up Special:UnwatchedPages, which only lists the first 1000 articles, bringing it up to 14708 Slaven. Unless you folks are volunteering to watch them, I'd strongly suggest batch deletion.--SarekOfVulcan (talk) 17:10, 18 July 2008 (UTC)

I think this piece of data speaks volumes for the 'inherent importance' of these topics. Delete/merge 'em all. Alai (talk) 03:12, 19 July 2008 (UTC)

The only bot created article that I can recall editing was 3754 Kathleen since it was the second largest object that Clyde Tombaugh discovered. Had the article not already existed I may have just made the article without an infobox like I did for Neptune trojan 2007 VL305 (though none of the Neptune Trojans have infoboxes). -- Kheider (talk) 03:43, 19 July 2008 (UTC)

That seems like an instance where a pattern-matching approach (or indeed a history-based one) would pick it up as having had non-schematic content added, so would be left alone by the sort of auto-merging process I suggested. Though it's still lacking the other type of data I mentioned, such as spectral class, so the solution I suggested for stub-sorting would place it in the "lower tier". I sense we're inching towards a basis to proceed on these, but we're perhaps not quite home and dry... Alai (talk) 17:09, 19 July 2008 (UTC)