Open eclee25 opened 1 year ago
reran the initial values data after the new updates on initial values
HASH: 6772ea9da4f43ddc3da11c494a573af2ca3dd3c8
Convergence, fits, Rhats, match to GAM input all look good.
Opinion: Approve
Model run:
HASH: 211913e0eb7d570ed62c48bc1ae9ecd6671a6cbc
Rerun on dev_u_combs_fix
HASH: e56580fa5ddab00293e31ff90139351f80ae3f6c
All look good.
One potential issue: duplicated observations for 2015 (there are multiple OCs with the exact same number of total annual cases 10568). also maybe consiering using a hight censoring threshold based on 2015 data pattern.
Model diags look good. As Qulu says, the 2015 annual obs in Tab 6 look like a mess but I don't think it's affecting the inference too much.
Not sure why there are "unknown 1-7" admin 2 level units (in the output shapefiles -- should be a GADM shape) -- perhaps take a look at this in get_country_admin_units taxdat function. Where are they located and what are they called in rgeoboundaries?
Approve after investigation of unknown 1-7 units.
@eclee25 I just checked that the those unknown 1-7 are pulled from gadm. I tried to find the same location from rgeoboundaries, but the overlapps between gadm and rgeoboundaries does not seem to be consistent (see the screenshot below: the yellow line is rgeoboudnaries and the black boundary is from gadm) The red areas are those unknown locations. I feel like what we can do is to switch to rgeoboundaries for KEN since there are no unknown location names in admin2 for ken in rgeoboundaries.
The KEN rgeoboundaries shapefiles have some misalignment between admin levels unfortunately... (black: adm2, blue: adm1, red: adm0) I think maybe we stick to GADM for now unless we get pushback about the admin unit names later.
Sep 2023 Production run: all OK.
Check if rgeoboundaries are used as discussed in the thread above.
Suggestion: accept.
Approve - these are the GADM units.
Data pull: HASH:
10db6c83d6486774d3148785df24b3145f375bb2
config