Jump to content

Template talk:COVID-19 pandemic data/United States medical cases

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Template talk:COVID-19 pandemic data

This is an old revision of this page, as edited by VanishedUser 092887 (talk | contribs) at 11:03, 23 May 2021 (→‎Split by type and year proposal). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

|topic= not specified. Available options:

Topic codeArea of conflictDecision linked to
{{COVID-19 pandemic data|topic=aa}}politics, ethnic relations, and conflicts involving Armenia, Azerbaijan, or bothWikipedia:General sanctions/Armenia and Azerbaijan
{{COVID-19 pandemic data|topic=crypto}}blockchain and cryptocurrenciesWikipedia:General sanctions/Blockchain and cryptocurrencies
{{COVID-19 pandemic data|topic=kurd}}Kurds and KurdistanWikipedia:General sanctions/Kurds and Kurdistan
{{COVID-19 pandemic data|topic=mj}}Michael JacksonWikipedia:General sanctions/Michael Jackson
{{COVID-19 pandemic data|topic=pw}}professional wrestlingWikipedia:General sanctions/Professional wrestling
{{COVID-19 pandemic data|topic=rusukr}}the Russo-Ukrainian WarWikipedia:General sanctions/Russo-Ukrainian War
{{COVID-19 pandemic data|topic=sasg}}South Asian social groupsWikipedia:General sanctions/South Asian social groups
{{COVID-19 pandemic data|topic=syria}}the Syrian Civil War and ISILWikipedia:General sanctions/Syrian Civil War and Islamic State of Iraq and the Levant
{{COVID-19 pandemic data|topic=uku}}measurement units in the United KingdomWikipedia:General sanctions/Units in the United Kingdom
{{COVID-19 pandemic data|topic=uyghur}}Uyghurs, Uyghur genocide, or topics that are related to Uyghurs or Uyghur genocideWikipedia:General sanctions/Uyghurs

Visual Editor does not work on this page, splitting proposal

As of November 30, the visual editor doesn't work in this table. Once I click on the blue button, it loads, then it received an error message. The error message is nothing in there, which is challenging with 530K bytes.

Page size

The page size adds at least several hundred characters a day, and on the 1st day of each month a month header was added, increasing its page size to 8,800 bytes.

@Bz8x8c: I've heard that this page has a missing American Samoa case column. It takes up at least several thousand bytes more.

American Samoa does not have a reliable source releasing case data. I believe covidtracking.com relies on social media posts and local informants. Fostrdv (talk) 05:28, 2 December 2020 (UTC)[reply]
covidtracking.com currently shows no cases for American Samoa. The link above suggests the 3 cases were sailors, so they were not citizens of AS - these may not be counted as AS cases for that reason. I think we should hold off until some official source actually shows cases for AS. Bz8x8c (talk) 18:36, 2 December 2020 (UTC)[reply]

Daily sources

Daily sources had stopped updating its sources on April 1st. On March 6, these sources were more aggressive until on March 20 it decreases. It completely stopped and no new sources were updated for 8 months. It is worth about 217,112 bytes worth of daily sources references.

I agree, the daily sources should be redacted; however, a not so insignificant portion of that 217k was redundant white space and in-line formatting which has been removed. Thosbsamsgom (talk) 02:08, 2 December 2020 (UTC)[reply]
list of daily sources removed. the collapsible list template they were wrapped by was one of the reasons for the page load woes. Fostrdv (talk) 05:16, 2 December 2020 (UTC)[reply]

Deaths table

The deaths table is 122,237 bytes, and it increases every day. Separating the two tables make it load a bit easier. It takes 10 seconds to load this page, as I said a number of times.

Splitting proposal

@Bz8x8c, Rider0101, and Poklane: I propose that sections Deaths table section be split into a separate page called Template_talk:COVID-19_pandemic_data/United_States_deaths. The content of the current page seems it takes more than 530K bytes in two tables including daily sources and we need to separate two tables.Evan0512 (talk) 22:46, 1 December 2020 (UTC)[reply]

I get why you're proposing to split the two tables into two separate pages. FWIW, I quit using the Visual Editor very quickly because it was painfully slow even then when there was far less content. Now, I just edit the content within the normal "Edit" function, which I now have down to a science. I am not opposed to splitting the page in two, but I will voice my concern about the impact to my required editing effort to maintain the data on two pages instead of one page. That being said, if the decision is made to proceed with separating it into two pages, I'll just have to adjust and deal with it! I don't know anything about Daily sources, which I haven't touched since I started helping maintain the page, so I guess I have no problem with them being removed. I only use the source links at the bottom of each table to access the same source sites each day. As for a new column for American Samoa needing to be added, I wonder if there's an easier way to do that without editing every row in both tables to insert the column? Bz8x8c (talk) 23:08, 1 December 2020 (UTC)[reply]
I'm personally not entirely opposed to splitting, however since I've yet to experience any issues with the page as it is I would prefer keeping things at is. I do however would like to say that I think it would be a good idea to split the page into 2020 and 2021 pages a month from now. Poklane 00:17, 2 December 2020 (UTC)
Before splitting, remove all the redundant state and date abbr.'s, as well as redundant links to the various state and region pages first. That will significantly reduce the page loads. Thosbsamsgom (talk) 00:46, 2 December 2020 (UTC)[reply]
Splitting into a new calendar year makes sense to me - nice idea. However, I will need to trust someone else to make those changes after the December 31, 2020 updates (or before, I guess), since my wiki effort to date has been limited to editing existing pages. Since I've added the new monthly headers the last few months, I'll need to make sure I don't reintroduce any content removed by recent trimming edits. (I did remove the inline comment about Florida non-residents in my saved header template.) Bz8x8c (talk) 02:59, 2 December 2020 (UTC)[reply]
As a regular watcher of the page, I'd be for the positive cases table and the death count tables being split. It takes forever to load, anymore. Devilmanozzy (talk) 03:09, 2 December 2020 (UTC)[reply]
I haven't been able to use the Visual Editor since August or so. I used to actively contribute to this page but I've stopped since then. As mentioned above, I also managed to master editing using the normal "Edit" function but eventually it became too cumbersome. I am in favor of splitting the page in two. Spaastm (talk) 15:03, 3 December 2020 (UTC)[reply]

The problem is not the amount of data, at least that's my impression. Modest images are far larger and still load quickly. The problem appears to be how long it takes to render the data in HTML table format. Splitting the file only solves the problem temporarily. It won't be long before both of the new tables are too big again. The solution is to find a better way to represent that data so that it displays faster. [anonymous user] — Preceding unsigned comment added by 161.97.246.132 (talk) 21:21, 4 December 2020 (UTC)[reply]

Using Chrome on a Chromebook, the page loads for me in ~3 seconds. How slow is "painfully slow" for you? Is it a lot longer than that? In an old browser version on an older OS I have, it takes much longer to load, so it's possible it depends on your browser/OS combo. Bz8x8c (talk) 23:22, 12 December 2020 (UTC)[reply]
7 or 8 seconds to load, using Windows 10 and Chrome, User:Bz8x8c. It's by far the worst Wikipedia page I load regularly - and yet my Internet connection is good enough to watch 4K television. And if anything, it's getting worse. Page is over 340 kB now! Nfitz (talk) 03:59, 21 May 2021 (UTC)[reply]
I suspect there is an open Template somewhere on the page (starting with {{ ) that is is not closed (a matching }} ). Thosbsamsgom (talk) 11:17, 21 May 2021 (UTC)[reply]
A text search says there's 244 of each - for what that's worth. Nfitz (talk) 15:20, 21 May 2021 (UTC)[reply]
Mine still loads on Chrome on a Chromebook in about 3 seconds. I'm not really familiar with the wiki technical aspects, as I just edit existing page content, but I'd be interested in whether wikimedia offers any diagnostic tools for analyzing page delivery issues. I don't have a clue how templates impact rendering or why you suspect an unclosed template, but I'd be glad to get input from anyone on how to diagnose or improve page delivery. Bz8x8c (talk) 20:31, 21 May 2021 (UTC)[reply]

@Evan0512, Poklane, Rider0101, Spaastm, and Thosbsamsgom: I just added the January, 1, 2021 rows to the existing page, along with the new monthly header for January 2021. As I stated in an earlier comment, I have no experience creating new article pages with necessary next and previous links. Can someone else take care of splitting this table into a new 2021 page and changing this page to specify it's the 2020 page, and add appropriate navigation between the two pages? If someone takes care of that change, I'll switch to updating the 2021 page with future edits. Until then, I'll just continue to add new data in this page. Any complaints or feedback? Bz8x8c (talk) 15:40, 1 January 2021 (UTC)[reply]

@Evan0512, Bz8x8c, Rider0101, Spaastm, and Thosbsamsgom: I think the best thing to do would be to move the current page to Template:COVID-19 pandemic data/United States medical cases/2020, and then make Template:COVID-19 pandemic data/United States medical cases/2021 the page for 2021. I'm also not too sure on how to do proper navigation, but I think simply adding "For 2021 data, see Template:COVID-19 pandemic data/United States medical cases/2021" at the top would be good enough for now.--Poklane 17:00, 1 January 2021 (UTC)
I disagree with such a hard split without more input from the editors who are using the data from this template/table as a source for other articles. Leave the tables in place for now, is my recommend. If we have no amicable solution by Jan 31/Feb 1. Then split. Thosbsamsgom (talk) 19:40, 1 January 2021 (UTC)[reply]
OK by me - I trust your judgement. I'll just continue editing this existing page until such time as someone decides to perform the split. Bz8x8c (talk) 20:23, 1 January 2021 (UTC)[reply]
Personally, I created a LibreOffice spreadsheet for my own use that's been importing this data every week or so, ever since it first became available several months ago. If it's split into separate pages by years I could adapt my spreadsheet easily enough, though of course there would be some effort. (On the positive side, if the 2020 data becomes frozen as its own page, that somewhat reduces the future archival risk of page vandalism and/or format changes. Also it would load faster, though the loading speed hasn't been a big problem for me so far.) If the years stay together, please start adding years to the dates on each line. I had to change some formulas today because LibreOffice suddenly decided that all dates without explicit years must be in 2021. Also the redundant monthly headers often complicate the calculations. But I can understand leaving those in place if it makes reading the data easier for site visitors. To all of you who have been collecting and entering this data so diligently for so long - thank you! Bouncey (talk) 01:48, 2 January 2021 (UTC)[reply]
As for whether to split the deaths from the rest: I mostly just use the combined national data. The state data would be much more useful if it included recoveries along with cases and deaths (or split recoveries into a separate page too). I don't know how common that is in the state-level sources though. I tried going directly to the source for one particular state, but found that they published in formats too complex for LibreOffice to import. Bouncey (talk) 02:04, 2 January 2021 (UTC)[reply]
@Thosbsamsgom: With respect to your changes this morning, I like that you moved the "Notes" out of the totals row and into their own row, which will ease some of the editing effort (The notes really complicate the task of updating the totals). However, some of the states had notes for just cases, notes for just deaths, and notes that applied to both sections. It appears you didn't create the same notes structure in the new notes content. Do we need to discuss that detail and decide how to approach that distinction between data sections' notes? Also, what was the reason for adding value formatting? That will require some additional effort in the value pasting part of the edit effort, as I currently just paste integer values into each cell. Bz8x8c (talk) 14:58, 2 January 2021 (UTC)[reply]
I am working on the bottom table ATM. Will post in next 30–45 minutes. Thosbsamsgom (talk) 15:07, 2 January 2021 (UTC)[reply]
Formatting the daily values helps with their readability. Otherwise, the table is a wall of incomprehensible 0s, 1s, 2s, etc. imho. Fostrdv (talk) 15:17, 2 January 2021 (UTC)[reply]
Lower table updated. And yes, agreed. Number formatting was for readability. However, that can be removed if need-be. Thosbsamsgom (talk) 15:58, 2 January 2021 (UTC)[reply]
well done with the edits.!! Fostrdv (talk) 16:59, 2 January 2021 (UTC)[reply]
@Thosbsamsgom: Thank you for your work cleaning up (and hopefully speeding up) these tables. Was it necessary to remove the state headers from the beginning of every other month? I have a massive Google Spreadsheet that pulls data from this page, and had compensated for all the monthly headers, so now everything is out of whack. (My personal preference would be just freezing the headers at the very top so they are always visible so monthly headers aren't neede, but I have no idea if that's possible on Wikipedia.) If I'm the only one scraping this data, I'm happy to adjust my spreadsheet, but I suspect I'm not the only one doing so, so I don't think we should be making changes to the positioning of data, like deleting headers and splitting the tables onto multiple pages, willy-nilly. Craig Butz (talk) 21:00, 2 January 2021 (UTC)[reply]
You can restore the monthly headers, yes? Nothing is set in stone on Wiki. I hope you understand. Fostrdv (talk) 04:24, 3 January 2021 (UTC)[reply]
@Thosbsamsgom: After entering one day's worth of data, I must say I like being able to paste a group of state totals into the table without having the notes get in the way. The only minor frustration I will voice is having the grand totals on the lower-right side appear below all the notes in the edit frame, since they appear to the right of the notes instead of the right of the state totals in the table! This means the final edit of the day requires me to scroll through all of the notes after entering state totals in order to update the grand totals. As I said, a minor frustration, but still an annoyance none the less. I'm also wondering if it's possible to stuff some hidden markers into the totals rows in order to identify the region groupings, since the notes actually served as 'markers' before to figure out where to enter totals values. Everything else was easy-peasy, nice and easy. Thanks for all your efforts! Bz8x8c (talk) 03:42, 3 January 2021 (UTC)[reply]
@Fostrdv: Thank you for taking the initiate to move the grand totals up a line last night. However, we need to think about the removal of the state labels at the bottom of the table. Right now, it's not a problem, but in two weeks I'm going to have a tough time finding the right source links for each state when the state labels are off the top of the screen. I'm trying to figure out where to reinsert them in a way that preserves the new position of the grand totals but restores my ability to locate specific states' refs once the top labels are no longer visible. Any suggestions are welcome. Bz8x8c (talk) 17:21, 3 January 2021 (UTC)[reply]
How about the last row? Fostrdv (talk) 05:52, 4 January 2021 (UTC)[reply]

Semi-protected edit request on 8 March 2021

The Confirmed Total cases for March 6, 2021 is incorrect. Change 27,047,306 to 27,043,306. 2603:7000:4502:FAF6:4DE9:BF3B:75AB:EBA5 (talk) 01:25, 8 March 2021 (UTC)[reply]

 Not done: please provide reliable sources that support the change you want to be made. Ididntknowausername (talk) 01:44, 8 March 2021 (UTC)[reply]

In the following talk page section, I explain an error I discovered in CA's case data entered for March 6 that resulted in the daily total cases being too low by 4,000 cases, which contributed to the issue with total cases raised in that talk page section. Looking back at this section, I realized this is the reason for the impression that the total cases was incorrect for March 6. It turns out the total cases is correct, but the daily cases was what was incorrect. Another user caught and corrected the error in CA's daily cases back on March 7, but the daily cases was still off by 4,000 until just now, as I just finished fixing it. This should resolve the original issue raised by the OP above, where they thought the total cases was off by 4,000. Bz8x8c (talk) 01:51, 28 April 2021 (UTC)[reply]

Total cases for 4/4/2021 is incorrect

The total cases for 4/4/2021 is incorrect. The correct total should be 28,521,865.— Preceding unsigned comment added by 2601:240:4980:24e0:b553:aa32:fae6:c076 (talk) 20:57, 7 April 2021 (UTC)[reply]

The accumulated total cases for 4/4/2021 is shown as 28,526,077. This is incorrect. The correct total should be 28,521,865.— Preceding unsigned comment added by 2601:240:4980:24e0:4cdd:8a7a:6f97:f480 (talk) 23:27, 15 April 2021 (UTC)[reply]

The April 4 total cases is based on the sum of the state total cases as of April 4, with supporting data that was collected from all of the states on that date. If you think it's incorrect, can you explain why you believe it's wrong and explain your source for that information? Bz8x8c (talk) 02:17, 20 April 2021 (UTC)[reply]
Today I discovered that I had a typo in my data spreadsheet on the daily cases for two different states on two different dates. March 6 CA cases, which Evan0512 had fixed on March 7, and April 4 MD cases, which had not been caught by anyone yet. These entry errors affected my calculated total daily cases that were entered at the end of the daily row for these two dates but had no affect on any other totals. It turns out that the total error in these two daily case totals was the same as the difference noted in the unsigned comments above, although the total cases was actually correct. If the OP was summing the daily case totals, that would account for the claimed discrepancy. The daily cases for these two dates has now been fixed, so this issue should be resolved. Bz8x8c (talk) 00:41, 28 April 2021 (UTC)[reply]

Split by type and year proposal

Due to excessive length, I propose splitting Template:COVID-19 pandemic data/United States medical cases into the following Templates ordered by data and by year:

In all likelihood this data will continue to be complied well into 2022, and possibly into 2023. Therefore, templates may be further split by year, etc. I have boldly created two Templates for 2020 by truncating the existing tables and merging the Efn's. Many thanks extended to Evan0512 for initiating discussion to split this template in December 2020.

The fans on my computer have spun up when rendering this page. So yes, is very much needed. Great job with the bold-ly-go work you've already done. Fostrdv (talk) 04:27, 22 May 2021 (UTC)[reply]

I was content to leave the page as is, but I looked at today's update using a ten year old mac. The fans went warp speed as the page overflowed and each column came into existence from the cyber-ether. Welp.! Might as well with the split, I say. ;) Thosbsamsgom (talk) 04:30, 22 May 2021 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:COVID-19_pandemic_data/United_States_medical_cases&oldid=1024645134"