mradamcox
commented
2 months ago We've evaluated these options and addressed this need by adding documentation for how to directly access OEPS data on BigQuery from existing R libraries. This removes the need for us to ship with dummy credentials (users set up their own) and makes it so this package doesn't depend on bigrquery.
Another approach for the load_data function would be to wrap the bigrquery library and essentially curate some bigrquery operations while also writing vignettes that would help users write SQL and more advanced queries.
Pros:
1) We already have the BQ project set up, it would be nice to use it in this way. 2) This would negate any questions about data storage raised in #2 (not only for the tabular files, but also geometry files) as these are all in big query 3) This would support both simple usage (show a variable for every state) but also more complex SQL queries against the data which would include spatial functions (show all tracts within ten miles of this ZCTA, for example)
Cons:
1) I think we would be billed for any queries to our BQ project, which is unlikely to be problem but perhaps could be. 2) As far as I can tell we would have to ship with some default auth credentials (doesn't seem like a good idea...), or alternatively, could create a signup process through which we distribute new read-only credentials as needed. Either option would require a good bit of research and follow-through.