Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://cmu-delphi.github.io/delphi-epidata/api/covidcast-signals/usa-facts.html below:

inactive USAFacts Cases and Deaths

• Source name: usa-facts
• Earliest issue available: June 24, 2020
• Number of data revisions since May 19, 2020: 2
• Date of last change: November 3, 2020
• Available for: county, hrr, msa, state (see geography coding docs)
• Time type: day (see date format docs)
• License: CC BY

This data source of confirmed COVID-19 cases and deaths is based on reports made available by USAFacts.

These signals are taken directly from the USAFacts COVID-19 Map by County and State without changes. The 7-day average signals are computed by Delphi by calculating moving averages of the preceding 7 days, so e.g. the signal for June 7 is the average of the underlying data for June 1 through 7, inclusive.

This data is similar in intent to our JHU Cases and Deaths source, but as USAFacts collects and aggregates its data in slightly different ways, the data is not identical. Users should evaluate which source better fits their needs. Users should evaluate which source better fits their needs, or use the combination signal of both USAFacts and JHU data.

1. Limitations
2. Geographical Exceptions
   1. New York City
   2. Mismatched FIPS Codes
   3. Grand Princess Cruise Ship
   4. Non-Integral Counts
   5. Counties Not in our Canonical Dataset
3. Source and Licensing

USAFacts reports cumulative cases and deaths, so our incidence signals are calculated by subtracting each day’s cumulative count from the previous day. Since cumulative figures are sometimes corrected or amended by health authorities, this can sometimes result in negative incidence. Health authorities can also change reporting standards in ways that dramatically increase the number of cumulative deaths, resulting in an apparent spike in incidence. This should be interpreted purely as an artifact of data reporting and correction.

There is no information provided for Puerto Rico in USAFacts’s data. There are unallocated cases/deaths reported for different states, and New York City. Due to differences in state reporting standards, certain counties are not reported in the USAFacts data or are reported combined with other counties; these exceptions are explained below.

Standard errors and sample sizes are not applicable to these metrics.

New York City comprises five boroughs, each of which is a county:

USAFacts reports cases and deaths for each of these counties, but also reports New York City counts not allocated to a specific county. We split unallocated cases and deaths evenly among the five counties, which results in non-integer counts.

All NYC counts are mapped to the MSA with CBSA ID 35620, which encompasses all five boroughs. All NYC counts are mapped to HRR 303, which intersects all five boroughs (297 also intersects the Bronx, 301 also intersects Brooklyn and Queens, but absent additional information, we leave all counts in 303).

There are two FIPS codes that were changed in 2015 (see the Census Bureau documentation), leading to mismatch between us and USAFacts. We report the data using the FIPS code used by USAFacts, again to promote consistency and avoid confusion by external users of the dataset. For the mapping to MSA, HRR, these two counties are included properly.

Besides, Wade Hampton Census Area and Kusilvak Census Area are reported by USAFacts with FIPS 02270 and 02158 respectively, though there is always 0 cases/deaths reported for Wade Hampton Census Area (02270). According to the US Census Bureau, Wade Hampton Census Area has changed name and code from Wade Hampton Census Area, Alaska (02270) to Kusilvak Census Area, Alaska (02158) effective July 1, 2015.

Data from the Grand Princess cruise ship is reported by USAFacts as its own distinct geographical area, with FIPS code 6000. We do not report these cases and deaths in the API.

Because the MSA and HRR counts are computed by combining multiple counties, weighted by their overlap with the MSA or HRR, the count data at those geographical levels may not be integers.

Due to technical limitations in how our system relates ZIP codes, county FIPS codes, and MSAs or HRRs, a small number of county FIPS codes can’t be directly mapped to MSAs and HRRs. These counties appear correctly in the API, but when they are aggregated into MSAs and HRRs, our code must first disburse their counts to other counties that share ZIP codes. This may change the reported MSA and HRR results slightly.

The full list of affected FIPS codes, and the FIPS codes they are disbursed to, is

SECONDARY_FIPS = [   # generated by notebooks/create-mappings.ipynb
	('51620', ['51093', '51175']),
	('51685', ['51153']),
	('28039', ['28059', '28041', '28131', '28045', '28059', '28109',
                    '28047']),
	('51690', ['51089', '51067']),
	('51595', ['51081', '51025', '51175', '51183']),
	('51600', ['51059', '51059', '51059']),
	('51580', ['51005']),
	('51678', ['51163']),
    ]

This data set is republished from the USAFacts known cases and deaths datasets, under the terms of the Creative Commons Attribution 4.0 International (CC BY 4.0) license.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4