This template is within the scope of WikiProject China, a collaborative effort to improve the coverage of China related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ChinaWikipedia:WikiProject ChinaTemplate:WikiProject ChinaChina-related
This template is within the scope of WikiProject COVID-19, a project to coordinate efforts to improve all COVID-19-related articles. If you would like to help, you are invited to join and to participate in project discussions.COVID-19Wikipedia:WikiProject COVID-19Template:WikiProject COVID-19COVID-19
This template is within the scope of WikiProject Disaster management, a collaborative effort to improve the coverage of Disaster management on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Disaster managementWikipedia:WikiProject Disaster managementTemplate:WikiProject Disaster managementDisaster management
This template is within the scope of WikiProject Medicine. Please visit the project page for details or ask questions at Wikipedia talk:WikiProject Medicine.MedicineWikipedia:WikiProject MedicineTemplate:WikiProject Medicinemedicine
This template is within the scope of WikiProject Viruses, a collaborative effort to improve the coverage of viruses on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.VirusesWikipedia:WikiProject VirusesTemplate:WikiProject Virusesvirus
Shouldn't the graph include all cases, China and otherwise?
@Colin dm: First, 97% of cases are Chinese so far. Second : only the Chinese government publish reliable daily reports so far, upon which we can build such diagram. WHO doesn't, or I'am not aware of it. This makes the gathering of world information per day tricking, because we have no stable source for the daily tally. Yug(talk)15:59, 29 January 2020 (UTC)[reply]
@Yug: Wikipedia has implemented mainland china data AND worldwide confirmed cases, so we can just use the main chart. I don’t think sources is the problem, its finding the history and re-doing the entire chart.
@Yug, Akira CA, GyozaDumpling, Eyesnore, Samozd, and Mardus: What to do you think of including projected cases based on current spread rate? I've did some math and found the following percentage growth for the respective days. With an average of 33.5%. Also have calculated the following graph based on the 33.5% spread per rate and included a estimate forecast for the next week. Do you think this should be included? RandomAccount1235423 (talk) 10:54, 29 January 2020 (UTC)[reply]
Confirmed cases in Mainland China in orange according to the National Health Commission daily reports[1] Projected cases in red based on the average spread rate as of 29 January 2020
But we should be able to give a projection with the current numbers for a short term. So we have 10.000 cases yesterday and can project 50.000 cases in one week. If it holds true then we can project another week with 250.000 cases — Preceding unsigned comment added by 92.117.135.34 (talk) 19:44, 31 January 2020 (UTC)[reply]
Or the other way round with current infection growth of 25% and 10000 cases we have 2 month left until all mankind is infected. 10000 * 1,25^60 = 6 Billion
Making a straight projection using latest % of growth will have very high chances or giving misleading results anyway, because over time the % of growth tends to "slow down". So, such a projection would have to take into account, not only the current % of growth, but also the rate at which that % of growth is, itself, slowing down. Basically, you have to try to find the S curve that fits best, not the exponential curve that fits best. Which is a bit more math-extensive. Using a pure exponential "fits best" curbe leads to ridiculous things like say in 3 months, more than 12 billion people will have become infected, which is evidently false because that would be more than Earth's entire population. Even for only a couple days in the future, pure exponential curve gives a 100% certainty give results that would be definitely overshooting. We want the best real "cold analysis" result, with sources, not some "scare-mongering" misdirection based on a Wikipedia contributor's edits alone. Unless there is a reasonably quite high % of confidence in a prediction curve's values, and for more than 2 or 3 days in the future, then it is probably a better approach to just not try to make such predictions in the first place. What could be much more useful is the chart showing the tracking of the number of deaths, in addition to the chart of the number of confirmed infected cases. In any case, using red for predicted values, visually shrinks down a lot the confirmed yellow values bars, and seems to downplay a lot the importance of the real data compared to some uncertain potential future.
I think it can be shown on the same chart, it just needs to be presented properly. For each day we have two bars, one for confirmed cases and the other for death cases. — Preceding unsigned comment added by 137.132.211.138 (talk) 06:15, 3 February 2020 (UTC)[reply]
I second the "two bars in the same chart" approach. However, because the number of deaths is only around 2-3% of the number of confirmed cases, I suggest using two different horizontal scales, one for confirmed cases, the other for deaths. Also, the two number data columns should be colored to color-match the color of their respective bars, and adopting two colors that are very easy to tell apart and that are easily readable (yellow is not all that much readable as text). For the few people with color blindness, some other trick should also exist. Maybe the bars for deaths are "full solid color" bars, while the bars for confirmed cases is a "hacked diagonal lines" texture. — Preceding unsigned comment added by 173.178.47.171 (talk) 18:15, 5 February 2020 (UTC)[reply]
Some have used the growth percentage to project the future infected cases. Should we add the growth percentage to the graph? To see if it goes down over time? Or create another graph?
Expected is the growth goes down because people in infected regions are in quarantine and all confirmed cases are isolated.
So if we had 33% growth last week then maybe next week it may only be 20% — Preceding unsigned comment added by 92.117.241.19 (talk) 10:49, 1 February 2020 (UTC)[reply]
@92.117.241.19: Symptoms takes 4~10 days, so there is delay between general alert (23th) and effects (29th and later).
Here's the daily percentage growth since 16 Jan, it has dropped to about %20 now from %50 in the first two weeks. Could be due to the lockdowns, but I've also read on Twitter that the number of patients that can be tested for the virus per day is only 2,000. Though I don't know how true that is. 38 95 64 47 51 30 45 55 53 38 64 32 29 25 21 22 20 CoronaVirusUpdates (talk) 07:21, 3 February 2020 (UTC)[reply]
I don't know how to fix this, otherwise I'd have done it directly, but it seems there is one dash character ('-') too many between the parenthesizes after the number 45 in the first data line. — Preceding unsigned comment added by 173.178.47.171 (talk) 18:22, 5 February 2020 (UTC)[reply]
Simple suggestion. Now that we have a lot recoveries in the stats (more than half the total cases) shouldn't we calculate the growth percentage with a ratio : "new cases / ACTIVE cases", instead of : "new cases / all cumul. cases"? This will represent the current progression more accurately. For 2020-02-29, 0.7% will become about 1.4%.Narringa (talk) 17:02, 1 March 2020 (UTC)[reply]
View issues when viewed on iPhone both in app and mobile web version.
The text size in relation to the column width causes the date to be split into two lines.
I’m using the default text size so I don’t think it’s that I’m also not sure if it’s only certain models/screen sizes of the iPhone.
I would modify the column widths but My knowledge of formatting elements like that isn’t that good.
I can also see that as soon as the numbers of cases hits the 100,000 mark or the percentage increase hits triple digits that column will also start to wrap its text around to a second line.
It’s confusing to read.
The center column with the actual graph bars can definitely be narrowed down a little. Kjpmi (talk) 18:58, 3 February 2020 (UTC)[reply]
This issue should have been fixed by the recent formatting change, which attempts to force the width of the chart elements. I can't test for all devices though, so notices and suggestions are welcome. Alexiscoutinho (talk) 13:22, 15 February 2020 (UTC)[reply]
I added a new bar to the template since consensus seemed to indicate that deaths should be shown in the same chart. It seems natural to me to also have a bar showing recoveries but I'm wondering if the chart is getting too cluttered. I'm putting my proposed chart here for the time being and if there are no objections I'll move it to main space. CheeseBuffet (talk) 16:29, 7 February 2020 (UTC)[reply]
The February 8th bar appears incorrect - I looked at the code and the numbers for confirmed cases are different in the text and in the formula used to calculate bar length.—Anne Delong (talk) 00:21, 9 February 2020 (UTC)[reply]
Anyone else think it should also show the numbers for the total death count and amount of recoveries? Having only bars doesn't really tell a lot.
Poklane 00:29, 9 February 2020 (UTC)
As of time of writing, the source in the template has yet to publish the 02-12 report, but someone already put the supposed numbers in, as well as a percentage increase that contradicts the actual increase. Atheist723 (talk) 00:17, 13 February 2020 (UTC)[reply]
The caption now says "As of February 12, 2020, numbers include clinically diagnosed people." How is this different than the previous numbers? Presumably this means they are not comparable? Are comparable numbers available that would make the graph more meaningful? -- Beland (talk) 01:04, 13 February 2020 (UTC)[reply]
@Beland: No there are no comparable numbers available. China just changed the definition of a confirmed case to include clinically diagnosed cases in order to give them the same kind of treatment as an originally confirmed case. Jayab31401:47, 13 February 2020 (UTC)[reply]
Currently there is a description of why the number has jumped but it's not obviously linked to the last figure and it's likely people will look at the graph and not the caption. Ideally there needs some kind of bar or spacing between the two epochs (I don't know enough to do so unfortunately), if not a separate graph. At least some kind of footnote marker on the number to indicate to the reader that there is more to the 12 Feb statistic. Sabretoof (talk) 01:53, 13 February 2020 (UTC)[reply]
@Beland: I must mention that people were added to the total number today who had tested positive in a kit. Today's additions were not all clinically diagnosed. Jayab31402:03, 13 February 2020 (UTC)[reply]
So the old numbers were all people who had been tested by kit or professionals, and the new numbers included people who were clinically diagnosed by some means other than a kit? And also some others with as-yet-unspecified characteristics? -- Beland (talk) 02:10, 13 February 2020 (UTC)[reply]
@Beland: Short answer, yes. Long answer, today's new 14,840 were a mix of people who had newly tested positive (probably ~2,000) and people who have symptoms but have yet to test positive by a kit (the other ~12,000). Jayab31402:16, 13 February 2020 (UTC)[reply]
I edited the "explanation" since it makes much more sense if the testing is for the virus SARS-CoV-2, not for the disease COVID-19. Boud (talk) 02:24, 13 February 2020 (UTC)[reply]
According to Medical diagnosis#Related concepts, "clinically diagnosed" means "visited a doctor who did a face-to-face checkup, asked for self-reported symptoms, observed symptoms using standard doctor's office equipment and concluded 'seems to be COVID-19' - this patient is ill". This is contrasted with "laboratory diagnosis" which means something like "had a blood sample taken that confirmed 'SARS-CoV-2' is present in the blood, independent of symptoms". Boud (talk) 02:42, 13 February 2020 (UTC)[reply]
I took a quick look, it wasn't obvious to me though what would be a good colour given the legend uses Location dot files, so it needs to be one of those available colours. Perhaps if someone has more time. Sabretoof (talk) 03:26, 13 February 2020 (UTC)[reply]
Please check this here https://wiki.riteme.site/w/index.php?title=Timeline_of_the_2019%E2%80%9320_Wuhan_coronavirus_outbreak_in_February_2020&diff=prev&oldid=940551077 . I understand that this is not related to what is being said here, but the side note is that if China is actually considering those to be clinically diagnosed as diagnosed, it should be considered diagnosed don't you think. Thus it should also be inputted into the data table as well, otherwise there may be a skew from what the chart numbers show compared to what it should be. I think the number of clinically diagnosed should also be added to the cumulative number. If not, then there has to be another chart added, otherwise that data is going allover the place and there will be comprehension difficulty. Aceing_Winter_Snows_Harsh_Cold (talk) 05:22, 13 February 2020 (UTC)[reply]
@Sabretoof:I do not think that is representing the information correctly. The point here being is that if clinically diagnosed is now being considered as diagnosed by officials, then it should be considered as confirmed. Thus placing N/A is unrealistic. However, to do the 33%* it can easily be done by doing the following 33%<'nowiki'>*</'nowiki'> just do not add the apostrophe in the nowiki tags. Thus this can easily be done. In fact, after February 14th's data is added, even if the clinically confirmed and tested confirmed cases are added together, the % will be looking like a normal value because it will be relying only on the previous value. Aceing_Winter_Snows_Harsh_Cold (talk) 05:29, 13 February 2020 (UTC)[reply]
If some of the stuff that I stated in the two comments above do not make any sense, it is probably because I added those comments when the page looked different than it was when I saw it latter on. Aceing_Winter_Snows_Harsh_Cold (talk) 05:57, 13 February 2020 (UTC)[reply]
The Health Commission of Hubei province actually publishes with a breakdown of how many cases are clinical diagnoses and how many are confirmed diagnoses. Link for 12 Feb: http://wjw.hubei.gov.cn/fbjd/dtyw/202002/t20200213_2025581.shtml . I tried to add this to the graph but somehow the section that I add won't show up in my editing preview. The CD figure for 12 Feb is 13,332. Could anyone add this to the bar graph?Rethliopuks (talk) 03:19, 13 February 2020 (UTC)[reply]
Done. As I suspected it was an issue of the template, which I have now modified. I took out the 12 Feb data here because the NHC actually hasn't reported any yet; if you calculate just the confirmed cases alone you'd get a decrease which surely couldn't be the case.Rethliopuks (talk) 04:30, 13 February 2020 (UTC)[reply]
The wording is wrong, should reword "As of 12 February 2020" - "as of" suggest that that the new methodology is valid up to the date, rather than the new methodology will be applied from that date onward. Also, the change in methodology is due in part to testing kits being in short supply [3], the previous decline in new cases may be due to testing kits running out rather than an actual decline. Hzh (talk) 11:05, 13 February 2020 (UTC)[reply]
Noted. The wording wasn't actually mine. The change is actually also due to 1) the virus being difficult to detect (e.g. the nucleic acid testing can identify only 30%-50% of the positive cases; cases may turn positive after testing negative); 2) there being limited capacity of running the nucleic acid tests in hospitals; 3) many people require medical attention and COVID-19 patients get special treatments including medical fee exemption; 4) political and medical directive of "rather mistaken than missed".Rethliopuks (talk) 15:12, 13 February 2020 (UTC)[reply]
Where does the number 46,472 come from, defining the orange part of the bar for 2020-02-12 in the chart. The bar chart is for all of mainland China. Do the data provided by the Health Commission of Hubei Province also cover mainland China, or just Hubei Province? (The website does not load for me, so I cannot check myself.) If the latter, we are comparing lemons and radishes here, and the change needs to be undone. If it is indeed all of mainland China, the source needs to be added in the article; currently readers are only referred to the website of China's National Health Commission. Is the "bisque" number 13,332 reported anywhere, or is that based on original research? --Lambiam17:48, 13 February 2020 (UTC)[reply]
@Lambiam: Only Hubei uses the category of clinical diagnosis, so what Hubei reports is what is nationally. Alternatively you can just check the NHC report; iirc it should include a figure of 13,332 clinical diagnoses. Subtract that from the total and you get the number. That said, it is a good idea indeed to archive the webpages so that it be accessible for all (hopefully), although unfortunately on my end, Wayback Machine cannot access the HC Hubei report for 02-12 either. An alternative would be to check (mainland) news sources, which generally report these reports basically verbatim. Rethliopuks (talk) 03:49, 14 February 2020 (UTC)[reply]
seem to use different colors and data - perhaps the colors could be harmonised so deaths is the same color on all for example. SO that "suspected cases" are removed after a time (say a month / evidence that people tested negative AND then not subsequently found as a false positive). ALSO harmonised with this graphic. — Preceding unsigned comment added by 88.115.204.102 (talk) 21:17, 13 February 2020 (UTC)[reply]
The numbers included in the graph and data do not match those provided in the reference, and in some cases (like the confirmed cases on the 13th) aren't even available in the referenced documents. Seems wrong. Martinwuhan (talk) 04:03, 14 February 2020 (UTC)[reply]
The 12 Feb data includes verified subtractions reported in the 13 Feb report. The 13 Feb confirmed case number comes from the Health Commission of Hubei's report for that day, for which a link is provided in the source code of the editing page. Rethliopuks (talk) 04:48, 14 February 2020 (UTC)[reply]
Wait, so, the figure of 13,332 for the 12th, and 15,384 for the 13th is subtracted from the national total number of cases?? Only Hubei is counting clinically diagnosed cases in its total?? — Preceding unsigned comment added by Martinwuhan (talk • contribs) 05:45, 14 February 2020 (UTC)[reply]
Yes. This is because the category of "clinical diagnosis" is only used in Hubei. The national diagnostic standard doesn't use the category elsewhere. Rethliopuks (talk) 14:09, 14 February 2020 (UTC)[reply]
There have been a lot of color schemes used in this article and due to the risk of WP:COLORWAR it seems like a good idea to settle the color debate. After all, it's a bit confusing for regular visitors to the article to see the chart change style constantly. As far as I know these are all the proposed colors for the various bars (used in different constellations):
Deaths: black , crimson , red
Recoveries: blue , dodgerblue
Tested confirmed: orange , red
Clinically confirmed: #Eb6e00 , khaki , limegreen
Personally I prefer the red/dodgerblue/orange/#Eb6e00 combination which looks like this:
My issue with this combination you use is accessibility; the scheme doesn't work in greyscale. Red and dodgerblue look almost identical, and #Eb6e00 is only slightly lighter than the two but darker than the orange in the middle.
From a tri-coloured perspective, #Eb6e00 is darker than orange and in between it and red, which seems to suggest it's in between the seriousness of the two, but clinical diagnoses are actually in between suspected and confirmed. Rethliopuks (talk) 04:25, 15 February 2020 (UTC)[reply]
Testing around a bit, an alternative color scheme with better lightness/luminosity might be:
My main concern with the current colors is that khaki is hard to make out on the white background, which is why I liked the darker #Eb6e00. You're right though that the clinically diagnosed cases should have a color that makes them seem less (and not more) severe than the confirmed ones. CheeseBuffet (talk) 10:19, 15 February 2020 (UTC)[reply]
Why there is a change in color from Feb 18th (light yellow) to Feb 19th (dark yellow)? Even the statistics suggests that the numbers are same. Shyam(T/C)07:05, 23 February 2020 (UTC)[reply]
From the perspective of an average WP user, this chart is overly complex and confusing, containing statistics that are not essential.
Rethliopuks wrote: "believe it or not the numbers are essential" - can Rethliopuks, or anyone else, please explain why the numbers are essential for the average WP user?
Rethliopuks wrote: "I don't find this chart any more complex or confusing than the basics of the situation." I do find it more complex and confusing than is absolutely necessary to understand the basics of the situation. Is the objective of the chart to present the data in a manner that is just as complex and confusing as the basics of the situation, or is it preferable to simplify the presentation of the data as much as possible - without grossly oversimplifying or distorting the information - to help the average reader to understand the basics of the situation? --- Ijon Tichy (talk) 04:33, 16 February 2020 (UTC)[reply]
The figures of the WHO reports used to agree with those from the NHC but seem to have diverged now. Then again, I'm not really sure if we even have the right figures since the data here doesn't agree with [5] (unless it's using a different definition of China?). An issue with the WHO reports is that they don't have any recovery statistics which I think would be a loss not to include.
Furthermore, the WHO reports don't go as far back as the Chinese reports (the first was on 21 Jan). If we mix both sources we'll probably get time of reporting issues, which is quite bad. Ideally, one should be able to gather good data with a common time reference (UTC maybe) by digging into the sources of the NHC and WHO to find the time of each case. However, this is extremelly hard to do. It would be more feasible to find historic WHO data before 21 Jan (does it exist?). Alexiscoutinho (talk) 17:24, 16 February 2020 (UTC)[reply]
I do agree though that we could merge the clinically diagnosed cases and tested confirmed cases as long as the change in methodology before and after the 12th is kept clear. CheeseBuffet (talk) 17:12, 16 February 2020 (UTC)[reply]
I mostly disagree. True, ideally the chart shouldn't be bothered with/show those clinically diagonosed cases as they aren't as important. However, it was China that forced/created this confusion (it's here that I agree with "I don't find this chart any more complex or confusing than the basics of the situation"). We cannot remove the clinically diagnosed cases and keep the tested confirmed since it would confuse readers who would, likelly, be expecting the larger number, which many, if not most, media outlets report. If we keep the clinically diagnosed and remove the tested confirmed, it would confuse readers in the future who would find the jump strange and awkward and would wonder what was the reason behind it. I think it's best to keep the template as it is, unfortunately. I dislike how China mixed statistics with politics and is now forcing us to do the data separation. Alexiscoutinho (talk) 17:24, 16 February 2020 (UTC)[reply]
I think Ijon Tichy had a good solution in his linked edit by only showing the clinically diagnosed edits on the day of the methodology change, then merging them into the main bar. The problem in the long run is that as recoveries (and hopefully not deaths) start to increase we won't know which bar to start "chipping away" from. I don't believe we have any way of knowing whether a recovered case is clinical or tested. CheeseBuffet (talk) 20:14, 16 February 2020 (UTC)[reply]
In a way, showing a separate bar only for 12 Feb is somewhat clear, but merging the bars while keeping the tested confirmed color is wrong. The new, larger, bars should have a different color and label. Alternatively, the merged bar could use the clinically diagnosed color and the transition bar could have a unique color and no label (only comment in caption). However, even if Ijon's proposition doesn't create confusion for future readers, it will still hurt them by omitting the more important and meaningful statistic, tested confirmed. Remember that China's decision to start reporting clinically diagnosed was mostly political and not because it is a better statistic. By the way, it doesn't make sense for a recovered case to chip away the clinically diagnosed bar. If a person recovered from something that wasn't tested confirmed as COVID-19, then nobody cares. Alexiscoutinho (talk) 22:10, 16 February 2020 (UTC)[reply]
Surprisingly, it appears that authorities don't differentiate between deaths from lab-confirmed and clinically diagnosed people as implied by "Deaths in table 1 include both lab-confirmed cases and clinically diagnosed cases of COVID-19" from WHO's situation report 27. Therefore, CheeseBuffet's final worry is justified. What a shame, China managed to break statistics. Alexiscoutinho (talk) 14:27, 17 February 2020 (UTC)[reply]
Without going into the politics, I agree that the problem comes from the mass dumping of a new non-laboratory tested category for 12 Feb. The problem of merging clinical diagnosis (CT imaging only; Hubei only) and confirmed diagnosis (lab test positive) is multi-fold. One, it confuses the medical basics and risks including people with similar CT results but who would turn out to be not infected with COVID-19. This in the long run would make this article factually erroneous. Two, by conflating two different standards that have caused massive practical implications, it obscures the reality of the situation by conflating two distinct national situations. The new bar would be conflating apples and oranges; no province outside Hubei uses clinical diagnosis as a category, so it reports neither the number of all the cases meeting a clinical diagnosis in the country nor all those meeting a confirmed diagnosis, but a mix that has no real justifications other than "that has been the total of all the data released". Three, it confuses the average reader because otherwise the massive 14k-odd jump on 12 Feb would be absolutely unexpected, provoking an immediate question of "why" that it then refuses to answer. For example: To what extent was there an escalation on 12 Feb which may or may not have been curbed in the days that followed? If the new category caused the increase, to what extent was it responsible for it? How meaningful was the new category? Was there really no separate data for the new category at all? If I am reading it around mid-Feb 2020, how scared should I be regarding it being a potential pandemic now? If I am reading it years later, what should/can I say about the overall progression of the outbreak? Rethliopuks (talk) 03:25, 17 February 2020 (UTC)[reply]
Not to mention that a patient can be first diagnosed clinically and then be confirmed later via the nucleic acid test. So the same patient can be counted twice! And if the patient is cured or, heaven forbids, died, he or she is likely be counted once. The rationale behind the decision by the Health Commission of Hubei to release a figure on C.D. patients is that it "would help patients receive treatment as soon as possible and improve their chances of recovery", since the nucleic acid tests would "take days to process". It has nothing to do with statistics.
I recommend that the C.D data not be used at all in the graph: not from now on (since the Health Commission of Hubei has stopped releasing data on C.D. cases anyway), nor include them even for the period from Feb 12 to Feb 15. The graph would be much cleaner and statistically correct. 98.207.237.179 (talk) 22:06, 17 February 2020 (UTC)[reply]
If Chinese official statistics do not separate death and recovery counts into lab-confirmed-and-died, clinically-diagnosed-and-died, lab-confirmed-and-recovered, clinically-diagnosed-and-recovered, then I agree that we have a problem that will get more significant as the numbers of recovered (and deaths) increase as a fraction of the total confirmed cases (either definition). Epidemiologists could build models with reasonable hypotheses and do model-based splits, but we don't have that option.
Ignoring clinically diagnosed cases won't solve the problem that deaths+recoveries could in 2-3 months' time become greater than the total number of lab-confirmed cases, even while the number of cases still alive-but-not-recovered is clearly positive (not negative). For epidemiologically reasonable data, Hubei doctors would have to systematically lab-confirm C.D. patients who either die or recover. That's out of Wikipedians' control.
Weak proposal A: We could make a naive model (for Hubei): once we get to 12 Feb + n days, attribute recoveries and deaths according to the proportions of lab-confirmed and clinically confirmed cases from n days earlier. The value of n would be a published median (e.g. from WHO? from Chinese medical sources?) of the delay between lab (or clinical?) confirmation to recovery or death.
Problems in this proposal: the algorithm is not so simple; it depends on a value whose estimate will vary with time and sources; n_lab and n_clinical would in reality differ because of non-COVID-19 pneumonia case in the clinically diagnosed cases; the model is too naive. Advantage: less naive than Weak proposal B.
Weak proposal B: choose a fixed proportion to attribute recoveries and deaths to the two types of detections.
Advantage: simple to apply and explain; disadvantage: even more naive and inaccurate than Weak proposal A.
Weak proposal C: Hope that WHO convinces Chinese medical authorities to provide cleaner statistics "soon enough" before the inhomogeneous nature of the numbers in the graph becomes too obviously inconsistent (e.g. total deaths+recoveries is greater than the number of lab-confirmed cases).
Feel free to rework any of these weak proposals into something better...
I think proposal A and B are heroic, but are akin to original research; so I'd go with C (and now that we're only get one number then that's all we got). This outbreak is without precedent. Unlike other outbreaks, it is very hard to determine what the data measure. Clearly, for several days, the "lab only" data weren't measuring the outbreak -- they were measuring the maximum rate of testing. So I think we would want to steer people away from reading too much into the "lab only" number. Chris vLS (talk) 16:57, 18 February 2020 (UTC)[reply]
The argument "for several days [...] they were measuring the maximum rate of testing" cannot be true. During the first 10 days of February the daily increase in cases followed a smooth curve, no ceiling. Furthermore, the Chinese only started to publish the clinically diagnosed cases after the daily increase of confirmed cases started slowing down. So there's no excuse for anyone to switch to the C.D. number just because of that quoted argument. Alexiscoutinho (talk) 00:49, 19 February 2020 (UTC)[reply]
I think "cannot be true" is a little strong when the authorities themselves changed the method because of a testing backlog. So we know that the testing rate was applying some type of maximum. If the testing rate wasn't applying some kind of limit, there wouldn't have been a backlog of thousands of cases. Since we don't know what the actual infection rate is, it is hard to make a strong statement that the changes in the reported data are an artifact of the real infection rate and not at least partially an artifact of the testing rate. But don't take my word for it, read the reliable sources that covered the change in methods. For example [6]. Your analysis of the shape of the curve may be indicative of a change in the outbreak. But for the period of time that we had two numbers, we didn't know what the criteria were for testing as opposed to CT. So the changes in the confirmed count could represent testing triage rather than a change in the outbreak. Basically, my point is that for much of this time, experts have been cautioning people from dumping this data in excel and drawing conclusions from it because it is a very turbulent environment. It's fine that we a including the numbers, but we are inviting people to do just that. Including both lab and CT encourages that even more, even though we just found out a good reason not to do it -- becuase testing capacity led to a big backlog. Anyway, it's moot since we're not getting both numbers anymore. Chris vLS (talk) 03:21, 20 February 2020 (UTC)[reply]
It appears that Hubei and NHC have both not released the number of clinical diagnoses. Yet that doesn't mean we won't have the data: the WHO situation reports always separate it from tested cases because the WHO only counts lab tested ones. At this moment the 17 Feb sitrep (for the global situation up to the end of 16 Feb) hasn't been released yet; when it is released we should hopefully have the separate data then. Rethliopuks (talk) 03:31, 17 February 2020 (UTC)[reply]
It looks like the data is out and that WHO is not giving the breakdown anymore. This one [7] has one column where the one from the day before [8] has two columns
I think this is actually a good thing. The data and the chart both imbue room much importance to the break down of the two numbers. They lead the observer to treat the rate of growth of lab-confirmed cases as something real about the outbreak. But as we have learned from the sources, the numbers might only be showing us the testing capacity, not the rate of infection. And it is even more complicated than that, given the changing lockdown rules. Chris vLS (talk) 23:23, 17 February 2020 (UTC)[reply]
As far as I can tell, this template just keeps getting wider as more cases are added. It's currently taking up something like 90% of the width of the article space on my screen at the moment, which is completely ridiculous. Of course this doesn't affect everyone to the same extent; nevertheless, it is out of hand.
Can the numbers be colocated/overlapped with the bars? Can some sort of scaling be used? Can the whole thing be rendered out as an SVG and then just handled as a regular image? pauli133 (talk) 13:28, 17 February 2020 (UTC)[reply]
GorillaWarfare recently tried to increase the width to fix wrapping, but where was the wrapping issue, in the date? If yes, then it means the {{nowrap}} didn't work, thus, a possible solution could be to put the date in a container with fixed width, like the {{Wikitable}}. If the chart is still too wide at 570px, then the only way I see to decrease it would be to decrease the space for the bars or decrease the font size of the numbers (better). What do you think? Alexiscoutinho (talk) 14:47, 17 February 2020 (UTC)[reply]
I'm a little bit concerned of no original research particularly in the use of recoveries as a data point. Whilst the Chinese are using it, it is not standard in outbreak investigation or communication to use as a statistic. Can someone point me to a WP:MEDRS source doing this? The Chinese themselves have a great discussion on the use of statistics here (sorry about the google translate, which I guess is WP:MEDRS compliant. Problems with the recovery data point include
1. Who defines recovery? if it becomes a pandemic, this will not be standardised worldwide.
2. When there is reporting into a surveillance system (which is what is happening) the data point of "positive test" or "death" is far more likely to be close to correct, due to clinician's sense of "urgency" of reporting these, as opposed to reporting recoveries.
3. Loss to followup - if you're well, many people won't tell their doctor so they can even be reported as recovery. Admittedly these cases are being followed very closely in this outbreak, but its a unique outbreak with a lot of active surveillance as opposed to passive surveillance. --Almaty (talk) 16:59, 18 February 2020 (UTC)[reply]
Should the Coronavirus 2019 outbreak graph be an epidemic curve or remain the current graph
The steps to doing so would be 1. Using the daily new case rate rather than the cumulative rate.
2. Deciding on the data points but these are around case rates, can be stratified by diagnosis or symptoms sometimes - epidemic curves don't show recoveries. I would make the date bars much much smaller and put separate bars and colours for diagnostic method personally but there's options
3. Making it horizontal
Thats it then you have a proper epi curve as has been replicated in the WHO situation reports, follows WP:MEDRS and shows the data in an easily understandable way. Sorry I did try give this a shot to visualise - no hope in wikicode --Almaty (talk) 06:53, 20 February 2020 (UTC)[reply]
Comment 1. There are already two graphs of daily counts in the estimates section, any new one would need to merge them, otherwise it will simply duplicate the information. 2. I have no opinion on whether to add recoveries or not, but I can see one that include recoveries for MERS, see below. It's simply one that's made horizontal. 3. It is inevitable that it will need to be made horizontal, otherwise it will become impossibly bulky if this goes on for months.
if you include recoveries, it’s not an epi curve. Also deaths. Data is around date of diagnosis and symptoms which can be stratified as as seen in the medrs__Almaty (talk) 15:46, 21 February 2020 (UTC)[reply]
I'm not bothered if recoveries are included or not, the more important question is how would you avoid duplicating the information that are already there in the other graphs in the article? Merge them or present different data set?Hzh (talk) 19:17, 21 February 2020 (UTC)[reply]
I created another chart which includes Recoveries. This is quite similar to current chart. I think it is quite difficult to merge two charts into one. ―― Phoenix7777 (talk) 03:19, 22 February 2020 (UTC)[reply]
I think we should use the chart above ("the cumulative chart" [9]) as the first one in the article (though we could also do well to also include the epidemic curve below it). IMO showing cumulatives makes visualizing the epidemic much easier (especially for the general reader) while avoiding the risk of confusion a secondary axis can bring. Whatever chart(s) we end up using should probably also include some note regarding the change of case definition on February 10th/12th. CheeseBuffet (talk) 22:03, 22 February 2020 (UTC)[reply]
This template is getting too tall and we must find a solution soon! If we want to keep the personality of this chart we have 2 options:
1- A temporary patch might be to decrease the font size, but this isn't neat and decreases accessibility.
2- A cool solution would be to create clickable tabs for each month, below the title, so that readers can switch to the bars/data of specific months. However this doesn't seem simple. The closest dynamic thing I can think of in Wikipedia is the collapse template (does anyone know of a more similar feature?). Therefore, we would need to use parser functions and more to customize our Bar Box. Does anyone have knowledge on this? Otherwise, I'll try to learn them in the near future.
If nothing is done, we will need to completely scrap the chart and start a new one without the numbers on the right. If we get to this stage it might be better to just do an epi curve like suggested in the previous section. Alexiscoutinho (talk) 20:31, 21 February 2020 (UTC)[reply]
DONE. However, it would be better to also use JavaScript to solve that "month and last 10 days intersection issue". JS would also allow the chart to show data for different countries. Alexiscoutinho (talk) 07:43, 4 March 2020 (UTC)[reply]
Hello RayDeeUx, I'am confused by your edits, which I inspected all, together with their renderings. You visibly only modified part of the widths affecting the size of the row and table (a misuse of code+template), therefor ended up with broken table, and therefor undid the work of others editors to return to an ancient code and colors we voluntarily moved away from. I encourage you to slow down, get hold on all the variables, and join the boat. If then you have improvement (merge-split the columns with numbers), it's welcome by improving upon current code of the template. cc: @Wikilucki, Rethliopuks, and Alexiscoutinho:Yug(talk)14:02, 1 March 2020 (UTC)[reply]
Hello, Yug. Please refer to my imgur links attached in my other topic "Custom stacked bar issues" in this talk page. I am not alone in experiencing these issues; IjonTichyIjonTichy also had issues once before and so has FredTC. RayDeeUx (talk) 00:47, 3 March 2020 (UTC)[reply]
As IjonTichyIjonTichy has mentioned, there's the color issues and the number/percentage change issues that FredTC has mentioned. I still feel that the older format was more ideal. [Side note: I'd love to move this discussion to my "Custom stacked bar issues" heading but it seems like we chose to have it here instead, which I don't mind in any case.] RayDeeUx (talk) 02:55, 3 March 2020 (UTC)[reply]
On my laptop (that has a really top quality screen) I have no problems with the colors. On my smart phone however the colors are indeed quite similar. But I also have the problem that the numbers in the right hand text column do't display correctly (see my edit below), which is also visible on my laptop when I change to mobile view. --FredTC (talk) 07:04, 3 March 2020 (UTC)[reply]
Can you make much smaller and concise version now for the 2019-20 coronavirus outbreak page? Because I think the data isn't super relevant for where it is in the page now. My edits might be reverted but i think its not as important as it was even just 2 days ago.
Also would appreciate any epidemic curves for any country. Or you can make an overall epidemic curve, I think this is better, have said a few times why. --Almaty (talk) 13:12, 25 February 2020 (UTC)[reply]
Dear all, there seems to be much confusion on these wikipedia talk pages about coronavirus outbreak data. I see a lot of "original" thoughts and interpretations ... I'm trying to be kind ... alas, most of it should be removed asap. Stick to the data ! For example, the D/C (case fatality ratio) vs. D/(D+R) debate is ridiculous: just plot them both on the same graph as functions of time and ask yourself *is this understandable* ... it is not ! How does one justify to show / plot a quantity that has varied from 64% down to 9% during the past month and try to push it as an indicator of the severity of this very serious planetary event ? All those content in building anti-WHO/anti-Government conspiracies based on the fact that CFR is misleading should be ashamed. CFR is just CFR and it's a pity if some of you don't understand it. Should it be shown as a single large index supposed to clarify everything ? NO, absolutely not ! Again, these wikipedia pages should focus on clear understandable data (the following table is hilariously full of originality and should be cleaned up once and for all https://wiki.riteme.site/wiki/Template:2019–20_coronavirus_outbreak_data/China_medical_cases ) with clear graphical representations ... now this is a bit trickier because *everyone* has their fav-plot. What is certain is that semi-log plots are not an option for the general public (don't get me wrong, I love them (semi-)logs ... in a previous life, I spent 5 years of my life sleeping with stretched exponentials). If you give it a think, we can do without semi-log plots for all this data.
I addition to my "get rid of all this originality", I have 2 suggestions:
- stop using "," as a separator in the numerical data.
- make a useful-for-all graph out of the data like a stacked plot of Deaths / ill (=#Cases minus D+R) / Recovered ( https://wiki.riteme.site/wiki/File:Covid-test01.png ). It is a very intuitive way of showing such data because you can easily see WHEN the number of people that are ill declines (or will decline) - remember, a lot of people have difficulties with cumulative data plots. This type of plot was previously used for the wikipedia page on the MERS outbreak.
As of 27 February 2020, there is a greater number of increase in cases outside of China then inside of it. In fact South Korea alone has reported more cases on this date (+505) than China +(433). It seems that the spread in China no longer represents the majority. Nabu-Kudurri-Usur Yaniv (talk) 10:56, 27 February 2020 (UTC)[reply]
It would be interesting to switch to global cases, but we need to find a way to make the template less tall. Why doens't wikipedia have a Tab extension?! Alexiscoutinho (talk) 17:32, 27 February 2020 (UTC)[reply]
Hello. I don't wish to cause an edit war, but I did have to swap the table back to the old style (without the custom stacked bar issues).
This is a screenshot of the table with the custom stacked bar, where the number of cases are quite distorted: https://imgur.com/a/Ieel2ny. "Show preview", unfortunately, doesn't exhibit those behaviors of distorted numbers.
This is a screenshot of the table in the original style [w/o the custom stacked bar}: https://imgur.com/a/DLEwmpN.
If possible, I'd like to see screenshots of both of these two different table styles on your devices before we start fighting over which style is better, etc. Then we can reach a consensus of which style to use and how to fix the width issues.
Until such a consensus is reached, I suggest that we stick with the style without the custom stacked bar for the sake of the readability of this table for others.
Good day/night.
EDIT: I do wish to note that the browser add-on that makes everything dark in my attached screenshots is Dark Mode Reader for Firefox, with the Contrast setting at +50.
@RayDeeUx: Ok, thanks for the screens. It's really messed up. You also appear to have a dark theme, which surely doesn't help. Yet we have an issue. We need something sharper.
As for the code, the code your propose has setbacks for maintainance : row style and severity colors hardcoded in each single row. The template is expected to be a simple factorization of this, with no differences in the final rendering. If otherwise, then it's simply that the template's code is not upgraded properly.
It's fixed now. I just had to increase the span widths because the font-size seems larger, by defualt, on mobile. Sorry for not noticing that back when I calculated the minimum span widths. Alexiscoutinho (talk) 20:29, 3 March 2020 (UTC)[reply]
Please take a look at the mobile view. The numbers in the right column show up like this:
80,02 (+0.3%
6 )
But it should look like:
80,026 (+0.3%)
--FredTC (talk) 02:03, 2 March 2020 (UTC)[reply]
Hi FredTC, I am also experiencing the same issues with the table. I've been trying to swap the table back to the old style, but the people involved in creating the custom template are trying their hardest to keep their format on the table instead. We're discussing the situation under the topic "Colors: Death and confirmed colors too similar" and would like your input. Thanks. RayDeeUx (talk) 02:59, 3 March 2020 (UTC)[reply]
It's fixed now. I just had to increase the span widths because the font-size seems larger, by default, on mobile. Sorry for not noticing that back when I calculated the minimum span widths. Alexiscoutinho (talk) 20:14, 3 March 2020 (UTC)[reply]
It is OK now on my laptop, switched to mobile view. However, nothing changed on my smart phone. I have 2 browsers on my smart phone, both have the same bad result. --FredTC (talk) 01:00, 4 March 2020 (UTC)[reply]
Yes, the last percentage is too large to fit in the inline-block. It should either be rounded or 2 s.f. should be used on all numbers (all widths would need to be changed then). Alexiscoutinho (talk) 07:57, 4 March 2020 (UTC)[reply]
I tested on my shitty smartphone and the table worked fine, except the last row. Maybe this issue only happens to you. Try copying the {{custom bar stacked}} to your sandbox and increase the width of those inline-blocks (see changes on a preview of the chart template). Tell me if it worked. Maybe the solution would be to use relative widths. Alexiscoutinho (talk) 07:57, 4 March 2020 (UTC)[reply]
That's an unusual Wikipedia layout... The problem is with the 2+2 {{inline block}}s of the custom bar stacked template. I could increase the current widths, but I would be doing it blind and I don't want to excessivelly increase it as the chart is already quite wide. What browser is that? How can I reproduce that layout? Alternatively, you may carefully adjust the template yourself. If you prefer the latter, I can help you (give instructions), if you want. Alexiscoutinho (talk) 05:28, 5 March 2020 (UTC)[reply]
Thanks, but the problem in the first has already been localized. The issue is that I don't know how to reproduce your viewports to fix it myself, so you might need to carefully adjust the custom bar stacked in your sandboxes and then push the best version to the actual template page. The second problem has its own section below, so I moved the picture. Alexiscoutinho (talk) 16:34, 5 March 2020 (UTC)[reply]
@Alexiscoutinho: Thanks for adding the collapsible feature. However, the "Last 10 days" option is a bit too short of a period to be that useful. Either half a month or 15 days, or "last two weeks" (14 days) would be better. There could also be an "All" option to sit alongside the months and "Last xx days" options. Zarex (talk) 17:29, 4 March 2020 (UTC)[reply]
Your suggestions are nice and I would implement them if it weren't for limitations with the toggle method I used. I could change to "Last 15 days" right now, but I'm not sure if it will be too tall for the main article (possibly upsetting the editors there, causing the template to be removed, again). Does someone disagree? Ideally, there should be multiple toggles with different time periods and an "All" toggle, like you said, but the average user might get confused because multiple toggles can be active at the same time, hiding, in obscure ways, the intersections. I think the only way to fully unleash the toggles would be to create a sub JavaScript to make sure only one toggle is active (or to, somehow, use extensions like Tabber). I still don't know how to do that, so until then (or until someone else does it), I'll try to be minimalist with the toggles. Alexiscoutinho (talk) 18:38, 4 March 2020 (UTC)[reply]
I recently started the {{2019–20 coronavirus pandemic data/Australia medical cases chart}} template, and I was wondering how one can implement a toggle for months and last 15 days like this template currently features? I want to add toggles for the first two months (Jan and Feb), March, and the last 15 days. I couldn't work it out on my own unfortunately, and there's absolutely no documentation on this feature, it seems. – PhilipTerryGraham (talk·articles·reviews)19:14, 12 March 2020 (UTC)[reply]
I didn't make a documentation for the toggle features because they are WIP (I need to find a Gadget or code some JavaScript myself to handle toggle groups, which I won't do soon as I'm focused on converting old charts to the new template). However, if you are interested, the process works like this: each collapsible element (row) is connected to a toggle via an id and class, respectively. You should only have one id per HTML element, but you can have multiple classes for one toggle/button. Therefore, if a row should be affected by two different toggles, its id should be a combination of the two, for example: mw-customcollapsible-feb-l15. The toggle for February would thus need a simple class, mw-customtoggle-feb, and a combined class, mw-customtoggle-feb-l15, to affect the February rows which are not and are also within the last 15 days, respectively. {{Medical cases chart/Row}} internally takes care of the id attribution and its initial state based on the date provided (if you don't put a valid date, i.e. you have a time jump, the current implementation won't work properly) if you activate the collapsible parameter. The {{2019–20 coronavirus pandemic data/China medical cases chart/Month button}} simply creates two alternating buttons which toggle their appropriate rows. However, it only accepts one month at time so, if you want to combine (Jan and Feb), you will need to manually create the alternating buttons with at least these classes on each: mw-customtoggle-jan mw-customtoggle-feb mw-customtoggle-feb-l15. The 'Last 15 days' button follows the same principle, it only affects the bars with -l15 appended to their ids. All these buttons lie on a bar which is just a centered <div>, but you still have the freedom to make whatever bar HTML. Summarizing:
1 - Each row gets an id automatically appended with its month and, optionally, -l15 (if it's a recent date), if collapsible=(yes|y|1);
2 - Each button is connected to those ids through its classes;
3 - Buttons are actually 2 alternating buttons which show the border only if the toggle is active;
4 - The togglesbar is just an HTML that arranges the buttons in an ordered way;
@PhilipTerryGraham: Sorry for the huge delay in helping you out. It turned out that there were more important issues to fix before the standardization of all charts, like implementing the data parameter. Furthermore, giving support to all country templates is extremely time and energy consuming, so I stopped midway to finally do your request. I hope you like it. Is it what you wanted? Alexiscoutinho (talk) 01:36, 28 March 2020 (UTC)[reply]
However, it only provides an existing (instead of cumulative) number of asymptomatic patients. I'm not sure if we should include this data in the chart, and if we do, how would we go about adding it. --Efly (talk) 04:59, 1 April 2020 (UTC)[reply]
@Ahecht: Is it strictly necessary to "destroy" this template's structure by not using {{Medical cases chart}}? The current implementation is bad because it won't automatically receive updates from {{Medical cases chart}}. Manually expanding the template should only be done as a very last resort. Moreover, if this were to be done, then why not put in the HTML directly? Why stop halfway? Alexiscoutinho (talk) 21:31, 9 April 2020 (UTC)[reply]
.svg){kind=small}
![[9]](https://wiki.riteme.site/wiki/File:2020_coronavirus_patients_in_China.svg){kind=link}
