Limit precision of metrics in the combined database

[awunderground]

[malcalakovalski]

I pulled the combined county and place CSVs and checked the max decimal places for every numeric column. Here's what I found. @awunderground Let me know if you agree with these suggestions.

The worst offenders are shares that carry 10-13 decimal places of floating-point noise:

• share_transit_commuter: up to 13 decimals (place file)
• share_poverty_exposure: up to 12
• share_desc_rep_*: up to 11
• share_meps20_*: up to 11
• share_homeless: up to 10

Most other share_* columns sit at 7-8 decimals. Crime/arrest rates are also at 7 decimals.

Current precision and suggested changes:

Metric type	Current max decimals	Suggested	Notes
pctl_income_* + bounds	2–5	0	CIs span hundreds/thousands of dollars, so sub-dollar digits don't feel very meaningful. If you disagree I think rounding to 1 or 2 decimals tops would be good
share_* (most)	7–8	4
share_transit_commuter, share_poverty_exposure, share_desc_rep_*, share_meps20_*, share_homeless	10–13	4	These are the worst offenders
share_affordable_* (can exceed 1)	6–8	4
rate_crime_*, rate_juv_arrest (per 100K)	7	1
rate_injury_death + bounds	1	1	No change needed
rate_learning + bounds	7–11	2
ratio_living_wage	7	4
ratio_*_house_value_households (char "X:Y")	3	3	No change needed
count_*, population	0	0	No change needed
count_membership_associations_per_10k	1	1	No change needed
ratio_population_pc_physician, index_air_hazard	0	0	No change needed

Let me know if you'd adjust the decimal places for any of these.

[awunderground]

These look great!

[awunderground]

Addressed in #591