year of census data

[boshek]

Now that census geographies are being updated in the catalogue to 2021 we will need to think about how to manage this. I see three options:

• Replace the 2016 census geographies with the 2021 geographies and simply commit to having the most recent version in the package
• Add an argument to census_* that specifies the year of the census with the current boundary at the default (create new functions census_2016_* and census_2021_*)
• Bind the two datasets together and manually filter for the census year of interest

[stephhazlitt]

@boshek does {bcmaps} get the Census data from the BC Data Catalogue via {bcdata}?

[boshek]

It does. It doesn't have to be that way but that is the current workflow.

[stephhazlitt]

So maybe the {bcmaps} package should follow the API in the B.C. Data Catalogue, which appears to be a record for each census year?

Which I guess is a +1 for this option from your list:

Add an argument to census_* that specifies the year of the census with the current boundary at the default (create new functions census_2016_* and census_2021_*)

[boshek]

Forgot a word in there:

Add an argument to census_* that specifies the year of the census with the current boundary at the default OR (create new functions census_2016_* and census_2021_*)

But yeah that logic makes tons on sense. Adding an argument means only minimal breaking changes.

[stephhazlitt]

I would lean to this option:

OR (create new functions census_2016_* and census_2021_*)

This design aligns better with the the other functions/the overall package imo -- one function per record. Re: breaking changes, we could leave the current set of census_*() as 2016 to avoid breaking changes but deprecate them in the docs.

And now that I have said all that, I have to say that I think option 1 is good too. If {bcmaps} is a package of convenience functions, then perhaps just the most recent year census boundaries would suffice? We could add some documentation re: using {bcdata} to get the older versions.