Map Viz Issues

[zackarno]

Can use this issue to document map visualization as we iterate?

Was just using this took take notes as flipped through the map pngs so is not totally comprehensive and perhaps I can reorganize.

I'm putting the pngs I'm looking at in the drive here: Predictive Analytics/HDX Signals/tmp/20240516_map_test so we are looking at the same thing (I guess next time we can set a random seed).

Random important:

• [ ] Ukraine png blank

General

• I think legend placement is good overall! But hard to tell completely as text size is way too small and could be affected by adjustments to extent which are flagged.
• [ ] City label size seems to be changing with zoom. Lot's are illegible
• [ ] General text sizes seem to change in raw pngs vs those in embedded in email. Maybe we should download raw png from mailchimp and see if those look like the ones here or the ones in email
• [ ] bubble breaks - there are the occasional cases where there is just 1 or 2 bubbles in legend when you'd think there should be 2 or 3 (for example AFG).
• Generally big countries look fantastic but smaller ones less so two factors related to zoom level/extent (and yes i am making up terms and acronyms).
  • Small Island Dispersion (SID) - small islands spread far apart - hard to map
  • Polygon Simplification (PS) - often related to zoom extent, but some appear overly simplified.

City placement

just flagging, 1. cities that fall outside of polygons, 2. a couple specific examples where text is hard to read (this is an issue that needs to be fixed more generally though).

• [ ] BHR: city outside of polygon.. Also polygons simplification looks a bit too much
• [ ] HKG: Hong Kong outside of poly
• [ ] ISL: Reykjav.... outside of poly and not text to small to be legible
• [ ] ISR: city text too small
• [ ] OMN : city text very unreadable
• [ ] PAN hard to read city text

PS & SID

• [ ] AIA: PS
• [ ] AND: PS
• [ ] ASM: PS & SID
• [ ] ATF: SID
• [ ] ATG: SID (borderline)
• [ ] BES: SID
• [ ] BHR: PS
• [ ] BHS: PS (borderline)
• [ ] BLM: PS
• [ ] BRN: PS
• [ ] BVT: PS
• [ ] CCK: PS
• [ ] COK: PS
• [ ] CXR: PS
• [ ] DNK: PS (borderline)
• [ ] EST: PS (borderline)
• [ ] FLK: PS
• [ ] FRO: PS
• [ ] FSM: PS
• [ ] GGY: PS
• [ ] GIB: PS
• [ ] GRC: PS (bordreline)
• [ ] GUM: PS
• [ ] HKG: PS
• [ ] HMD: PS
• [ ] IMN: PS
• [ ] IOT: PS
• [ ] KIR: SID
• [ ] LIE: PS
• [ ] MAC: PS
• [ ] MCD: PS
• [ ] NDV: SID
• [ ] MHL - SID
• [ ] MKD - PS
• [ ] MLT - PS
• [ ] MNP - SID
• [ ] MUS - SID
• [ ] NCL - SID
• [ ] NFK - PS
• [ ] NIU - PS
• [ ] NLD - PS (borderline)
• [ ] NRU - PS
• [ ] NZ - PS (borderline - but should be better file available)
• [ ] PHL - PS
• [ ] PYF - SID
• [ ] REU : PS
• [ ] SFS: SID
• [ ] SHN: SID
• [ ] SJM: SID
• [ ] SYC: SID
• [ ] TKL: PS
• [ ] TUV: PS
• [ ] WSM: PS

Other issues/Ideas

• [ ] would it be good to include neighboring countries? The map of Canada looks very odd w/ out the USA as do many others.
• [ ] EGY: a bit weird the way the poly is split... kind of looks good, but not standard with others
• Some countries have lakes/rivers cut out of polys
• [ ] MWI: lots of slivers in poly looks funky

[hannahker]

We should definitely adopt SID and PS <3 How were the bubbles generated for testing? I'm assuming it doesn't matter that most of them are outside a country's boundary?

[caldwellst]

would it be good to include neighboring countries?

For now, keeping extremely simple. Otherwise you start having to deal with edge matching, we don't actually care about the other countries there as the data is entirely to a specific country. Also, if we include other countries, we start needing to maybe include data in those places as well. Which could be nice for context, but I think maybe too complex as you can't necessarily associate cross-border events, so should probably be left to others.

SID

Agree on the SID, but not much we can do. If you have good ideas that create a general map fix for them that's good, but otherwise we wait til we have data and need to send an alert and likely just don't use a map. If they are too small, we don't care.

PS

Yes, good catch. In the generation script, I smooth out and simplify the polygons. Probably can reduce the smoothing based on size. Definitely something we should do, no need for a country list, just automate based on polygon size I think.

MWI: lots of slivers in poly looks funky

Yeah, strange, shall we infill them?

City label size seems to be changing with zoom. Lot's are illegible

Definitely not the case that Mailchimp is editing the PNGs. You can see that my machine produces plots like Mailchimp, I added a folder next to yours in tmp/seth_map_test.

bubble breaks - there are the occasional cases where there is just 1 or 2 bubbles in legend when you'd think there should be 2 or 3 (for example AFG).

I also don't have this problem, see my AFG map. Are you sure everything is running fine on your machine?

[hannahker]

@caldwellst @zackarno did you want me to try and generate the maps on my end?

[caldwellst]

Yes please! https://github.com/OCHA-DAP/hdx-signals/pull/75#issuecomment-2116074917

[hannahker]

Aha yes I remembered seeing the yesterday and then couldn't find where the comment was again 😆

[zackarno]

I also don't have this problem, see my AFG map. Are you sure everything is running fine on your machine?

yeah I'm just running the test/manual/maps/implement_map_test.R script without changing anything. I've tried running directly from terminal as well as R-studio and had the same issue in both

Oddly the only fix, the way that I could get it to reproduce the results of your 2 machines was to run this prior to the purrr$map() call intest/manual/maps/implement_map_test.R

showtext::showtext_opts(dpi = 300)

interestingly adjusting the dpi argument in ggsave() didn't have the desired effect. I wonder if somehow gghdx() is calling/initializing showtext differently on my machine and if that is a result of something in the {gghdx} package itself or something I've done by accident in the repo or elsewhere!

Also found this issue documenting the same: https://github.com/yixuan/showtext/issues/51

[caldwellst]

So annoying. Outside of Markdown, it shouldn't be ggsave() taking in the show text arg for DPI, but it's a mess. Reality is we should move to {ragg}, the modern text package, which deals with all of this and has consistent sizing from font/glyph size in R and pixel output. https://github.com/OCHA-DAP/gghdx/issues/31

Will try and get to this next week.

[caldwellst]

I think the only thing remaining in here is finding an alternative data source to the UN GeoData because it's far too simplified. Should close this and create a smaller, clearer issue so we remember to address that eventually.

[hannahker]

Closing this as main issue remaining is the visuals for small island locations. We'll address this as the need arises.