Wikipedia:Bots/Requests for approval/PALZ9000

The following discussion is an archived debate. Please do not modify it. To request review of this BRFA, please start a new section at WT:BRFA. The result of the discussion was

Approved.

PALZ9000

Operator: Penyulap (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 23:59, Friday March 16, 2012 (UTC)

Automatic, Python, Source code not available

Function overview:

The initial task of PALZ9000 will be to fetch Two-line elements (orbital trajectory information) from the Heavens-Above website and add it to a sub-page of the relevant space station article, so that editors can transclude it to the article. (inserted clarification, the bot may place all the data into a single template rather than sub-pages of the articles) There are no copyright issues for the Heavens-Above website according to the owner, Chris Peat, whom I initially contacted about images for the article about that website, Heavens-Above.

Links to relevant discussions (where appropriate): none.
At this stage, no articles will be affected directly, only by transclusion, so normal edit/revert can be done by any editor.

Edit period(s): Less than a dozen edits per day total, one per space station per language, plus a status report to the main programmer and myself. The Heavens-above website updates its data about 4 or 6 times a day from it's source, which changes about once per day only.

Estimated number of pages affected: 6-12,
additional talkpages where it issues reports on its status to opted-in users.

Exclusion compliant (Y/N): No,
it only works on pages specifically set up for this bot.

Already has a bot flag (Y/N): No
It is being requested simultaneously on Russian wiki and Japanese wiki

Function details:

PALZ9000 parses data of the source page with BeautifulSoup then updates wikipedia page using pywikipedia, the data is copied into Template:ISSIB.

Discussion

Note: This bot appears to have edited since this BRFA was filed. Bots may not edit outside their own or their operator's userspace unless approved or approved for trial. AnomieBOT ⚡ 05:21, 17 March 2012 (UTC)[reply]

I don't get it. Why not link to the external website instead? They've even got a pretty picture. Josh Parris 06:48, 17 March 2012 (UTC)[reply]

Whilst the heavens-above site does have a pretty picture and fresh data, the data in the infobox for the ISS article is out of date. there are small errors, 3 orbits for example in the tally of orbits calculated from an age in days template someone put in there in comparison to the TLE data from the US gov. The orbits per day of the station is inversely proportional to the altitude, which changes constantly. That is a bigger problem, this graph shows change over a large period, this shows the change over a shorter period, and how much the infobox is out, it's pretty much better that editors use just a range in the infobox as it dates so fast. A docked ship fires it's engines about every fortnight to boost the station. Having a stated altitude in the information box appears popular with editors and I project that they'd resist it's removal. Altitude has not been updated this year, editors have little interest, so the article is simply wrong.

Basically I think editors would resist the removal of the altitude data from the infobox, but can't be bothered to update it manually. There are a lot of parameters like this. Also, with the bot operating, it would become possible for the editors to choose other information if they desire and place that into the infobox or articles as they please.

The orbital Epoch is the time and date that the data is valid for, an 'as of' date if you will, and for parameters such as eccentricity, perigee height, apogee height, right ascension of ascending node, and argument of perigee it is important as the data becomes 'stale' within days, and is useless after mere weeks. I have no idea if editors will care for data such as right ascension of ascending node and argument of perigee, but it's very easy to give them that option when addressing the more pressing issue of simple things like orbit number and altitude. I'd like to ask the astronomy guys if it's useful, and then have it appear in the infobox in a collapsible section when there is valid data to present, and make it disappear completely when it's a little out of date (I think the astronomy guys can tell me how far out, but it's a minor thing).

So I figure that the altitude and orbits is a simple and clear task for PALZ to start with. Penyulap ☏ 08:40, 17 March 2012 (UTC)[reply]

I think such frequent updating of statistics unusual; please bring this BRfA to the attention of the talk pages of the affected articles, highlighting the frequency with which you intend to update the data. We'll give other editors a few days to bring an opinion one way or another. Josh Parris 09:55, 17 March 2012 (UTC)[reply]

That sounds great. I can also mention other tasks beyond the scope of the request. Although, for launch tables and putting them on foreign wikis, there may well be nobody to talk to, as some of those articles are so quiet and undeveloped. Penyulap ☏ 10:03, 17 March 2012 (UTC)[reply]

I'm thinking that it's easier to change most of the parameters in the article to ones that do not need updating at all. Like Apogee have minimum, maximum, and possibly average across the station's life. I'd figure the article would be better quality and I should edit it that way and see if there is any resistance. Penyulap ☏ 01:16, 19 March 2012 (UTC)[reply]

That sounds like a more conventional approach. Do you want to keep at this BRfA or abandon it? Josh Parris 02:14, 19 March 2012 (UTC)[reply]

I posted comments on the talkpages of the two space stations, one as recent as yesterday, and there has been no response yet. I think as a courtesy to editors who may wish to comment I'd like to leave it say, a week before deciding, as people may be busy during the working week. Does that sound logical ? Penyulap ☏ 02:43, 19 March 2012 (UTC)[reply]

Sounds good. Josh Parris 03:34, 19 March 2012 (UTC)[reply]

Well, it's been about a week now, and I've had positive results on the Tiangong 1 talkpage. The article's largest contributor commented "That sounds pretty useful - are you going to use this bot on a lot of spaceflight articles? " [1] There haven't been any other comments yet, and that is the case on the ISS talkpage. I thought it might be good for some other articles, and added data for Genesis I and Genesis II. I didn't bring it up on those talkpages. One of the talkpages hasn't had any comments for many years, and the other is blank.

Overall, I think this small task is helpful and I can foresee it would be in demand for articles about satellites which are likely to be destroyed or hit the Earth such as Fobos-Grunt, a Sino-Russian interplanetary ship which glitched and came back to Earth, it landed in the public spotlight. The data itself is exceedingly boring for me to mess with, and looking at the articles, it's popular to have it in place, but not popular to update it, I think that's for the same reasons. So a bot is perfect. Let's proceed ! Penyulap ☏ 05:08, 25 March 2012 (UTC)[reply]

{{BAGAssistanceNeeded}} So, from re-reading the above you're now looking to update the minimum and maximum values; could I suggest that if the change from the last isn't material, no change be made? Do amateur stargazers and satellite nerds use this data, or would they go hunting elsewhere, such as the source US gov site? I think I'm wondering: why is this data in an encyclopedia article? Are you ready for a trial? Do you think a one week trial would be enough to exercise this task thoroughly? Josh Parris 00:16, 27 March 2012 (UTC)[reply]

Yes it makes sense to change only when required. I know that the data on Chris Peat's Heavens-Above website is updated about every 3 or 4 hours, but each TLE for the separate stations are updated only about once every day. An analysis of PALZ edits show that the TLE's are issued at random times of the day, so an average for the change of at least one TLE is every 6 hours. PALZ is working at 12 hour intervals at present.

An analysis of PALZ last 10 edits show that he made a material change to a stations height 9 times. In some cases, no change to the height was made, in other case he updated 2 or 3 at a time. The 10th last edit, where he added new data for Genesis I and Genesis 2, was counted as only 1 change for Tiangong 1. Over the 10 edits, he made a material change to at least one stations altitude in 70% of edits.

I figure I shall put the TLE's into the TLE article, so that the current example given in that article is a little fresher, I think readers who are trying to work out TLE's would like that, as they may be reading the TLE article in relation something in orbit at the present moment, and an example they are working on, given in the article, would be like, sweet ! I have not discussed it on the talkpage. The talkpage is not empty, it has 3 conversations total, the most recent 13 months ago. I brought up the TLE's with last editor on that talkpage, but on re-reading the discussion on his talkpage, I notice that I had not actually outlined PALZ operation properly, I think this has resulted in some confusion (link). To be safe, I will assume that the inclusion of TLE data in the TLE article is disputed and won't include it until RadioFan approves. I'll put a demonstration onto the talkpage of that article instead, properly invite RadioFan to examine it, and see if it attracts any comments or suggestions.

The apogee and perigee for 5 station articles are combined into a single edit to the ISSIB template. I could let the data for the 2 minor stations 'queue up' behind the data for the two major stations, until PALZ detects a change for the ISS or Tiangong 1, and then write all data to the template. That would increase his material edit rate for space station data to 100%, and reduce the rate of edits, (projecting from his last one dozen edits where 8 out of 12 had a change), to every 18 hours on average, from the present 12 hours.

The TLE's as well as the apogee and perigee data all come from the single edit. There is no updating to the articles directly, not at the moment anyhow, it's just the single template so all 5 stations parameters and TLE's are combined into the single edit. At the moment there is good reason to reduce the frequency of edits to increase their material value of all edits from 70 to 100 %, however, because the issue of TLE data in the TLE article has not yet been resolved, it's difficult to say if the TLE data should be counted as a material change.

If TLE data were to be counted as a material change, then 10 out of 10 of the last edits would count as a material change.

I'd like to suggest, that rather than add further functionality to PALZ to filter out the TLE data and remove the 30% of edits where it is the only change made, that the Bot is trialled, so the altitude data which has support can be incorporated, and the TLE data can be transcluded to the TLE talkpage from the ISSIB template, giving a practical demonstration which may make it easier for other editors to understand PALZ in the case where I have failed to explain properly. This trial might help stir interest amongst editors, for example, rather than use the current expressions

Perigee 376 km (234 mi) AMSL (1 October 2011)
Apogee 398 km (247 mi) AMSL (1 October 2011)

something more educational and informative may be used,

Perigee 378 km (235 mi) AMSL (for the epoch commencing 26 March 2012)
Apogee 399 km (248 mi) AMSL (for the epoch commencing 26 March 2012)

"amateur stargazers and satellite nerds" might see this, and those editors comments can be incorporated into fine-tuning this bot task, as I do not know if TLE data will be quite popular with those editors.

Alternately I'd suggest putting it on hold for less than 1 week, so I can canvass commentary on the TLE data from the astronomy wiki-project, RadioFan and others, and the TLE talkpage, although I think it may be easier to simply consider it disputed for now, not transclude into the TLE article, transclude onto the talkpage, and then based upon that, decide later if PALZ 12 hour edit rate should be re-engineered. The possibility exists that other editors, "amateur stargazers and satellite nerds" may like the data, or even demand updates when they are available. The US government website startrack requires login details and legal agreements prior to access, as per PALZ userpage under the humorous topic 'approvals and bans', it actually contains the real links to explain that situation. Penyulap ☏ 02:59, 27 March 2012 (UTC)[reply]

I think for some technologies, it's difficult to know how people will respond until after they see the possibilities demonstrated and decide for themselves. So for some of the functions there is support, for the others, I guess we won't know until editors understand what they can do and decide if it's valuable or not. For example, the data contained within the template can be used to draw maps of the earth, with the orbit of the space station, and an accurate marker for the space station placed upon the map, giving the current position of the station. An example off wiki is here, but only if you zoom out, and only if it keeps showing the track, although I would not make it an animation like that, due to server load. The one here is better, but it uses a globe that doesn't show the sinusoidal form of the groundtrack which is what I would like to illustrate. In print, it gives the position at a particular epoch, and illustrates in an encyclopedic fashion the shape of the orbital ground-track, online it adds to the functionality that whilst people are reading the encyclopedia they can realize that they can walk outside and see the station, and where to look. Currently the article has a weak illustration of orbit, showing an animation of the station orbit, although I see no reason to argue with the person who put it there of course. But I think explaining the possibilities of what can be done is not always as easy as simply doing it. Sometimes I figure putting an example onto the talkpage is easier than describing what I am proposing. If I try to explain imagemapping and linking and ask to change the standard form of a userbox image, I could be weeks in discussion, but if I just demonstrate like this

people can make a complete analysis and summarize their response as 'it sucks' or 'cool' in 10 seconds, (or a minute if they hover their mouse), so discussion is very important, but on the other hand, discussion combined with demonstration is part of discussion. Demonstration it can be argued, is the best form of discussion. Penyulap ☏ 03:44, 27 March 2012 (UTC)[reply]

It may help all concerned to see the bot in action. Let's run for a week and see if it clarifies things for others. My understanding is that the bot will edit a in template space rather than article space.

Approved for trial (7 days). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Josh Parris 04:02, 27 March 2012 (UTC)[reply]

Trial

The last dozen edits or so, over the last week or so, properly describe the operation of the bot.

The only changes that will be made (that I can think of at present) to PALZ operation would be the following.

bot editing his own user-pages to report his status, operating / not operating / next edit in X hours minutes / last edit was X hours and minutes ago. This is done once after each update of the ISSIB template. The countdown templates are used with show text before a particular date and time, and alternate text afterwards.
<noinclude>{{Documentation}}</noinclude> will be added to the ISSIB template
the web-page access date will be added to the list of the information in the ISSIB template. I added the epoch date as the accessdate as a temporary illustration of my own editing in the ISS article. The changing epoch date is now in the reference to show what time the data was accessed from the reference page, but the epoch and access date are not the same, so i want to add the accessdate to the template.
The time of day that the edits are made would change, but not the edits themselves or their frequency. They won't be done at 12.00 or 00.00, don't worry about that though.
The bot would look for 'edit this text to switch off PALZ 9000' on his userpage, if he can't find it, he doesn't edit until it is returned. That is for any non-admin who wants to switch off the bot to test their editing in an article without PALZ updating the template.

I don't think further demonstration edits would vary from those already made, and the edits I made to the ISS article illustrate how the data is used in an article. I shall add documentation to the ISSIB template so that other editors can also make use of the data in other space station articles if they wish to do so. I wrote some of the instructions here in two sections, one shows how to add apogee and perigee the other shows how to do some math for orbital period all using bot-updated data. The only thing left to do copy n paste that to the docs, and fill in instructions for other items, and how to do the references.

For the demonstration, it's as demonstrated as it gets, because the only changes scheduled to PALZ program are either minor, for the docs, or to his own userpage(s) which as I understand is considered uncontroversial. There have been no further comments by other editors on the relevant article talkpages. I'm not sure there is merit in continuing the trial for the remaining two days and 13 hours, unless you'd like me to include the above minor polish into the bots code. Penyulap ☏ 13:23, 31 March 2012 (UTC)[reply]

This is the editors code:

apogee = {{convert|{{ISSIB|ISS|apogee_height}}|abbr=on|km}} [[Above mean sea level|AMSL]] ({{Str crop|{{ISSIB|ISS|epoch}}|9}} [[Epoch (astronomy)|epoch]])<ref name="heavens-above-Palz-tle-data">{{cite web|url=http://www.heavens-above.com/orbit.aspx?satid=25544|author=Chris Peat, Heavens-Above |title=ISS orbit|accessdate={{Str crop|{{ISSIB|ISS|epoch}}|9}}}}</ref>
perigee = {{convert|{{ISSIB|ISS|perigee_height}}|abbr=on|km}} [[Above mean sea level|AMSL]] ({{Str crop|{{ISSIB|ISS|epoch}}|9}} [[Epoch (astronomy)|epoch]])<ref name="heavens-above-Palz-tle-data"/>
period = {{Str left|{{#expr:60*{{#expr:24/{{ISSIB|ISS|revolution_per_day}}}}}}|2}} minutes {{Str left|{{#expr:60* {{Str right| {{#expr:60*{{#expr:24/{{ISSIB|ISS|revolution_per_day}}}}}} | 3 }}}}|2}} seconds ({{Str crop|{{ISSIB|ISS|epoch}}|9}} [[Epoch (astronomy)|epoch]])<ref name="heavens-above-Palz-tle-data"/>

I'll put that into the docs in the same, clear manner as on the ISS talkpage Penyulap ☏ 01:01, 1 April 2012 (UTC)[reply]

Looks good; given the lack of complaint, I don't see any great problems from the trial, operator is attentive and operating in a narrow area.

Approved. Josh Parris 01:03, 1 April 2012 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. To request review of this BRFA, please start a new section at WT:BRFA.