This PR therefore imports the regions.csv with id (and all variables, like before) set to character. I also simplified the get_region() function a bit. It now uses the relatively new curly-curly rlang syntax, i.e. it requires rlang >= 0.4.0. If that is a problem, we can revert to the !!enquo() syntax used before, see https://github.com/CorrelAid/datenguideR/commit/2835e1860ce20ab98477fd1dddaf6df652ac5644.
The left_join() of dg_regions to the api_results in dg_call() could also be simplified now. I don't understand yet, however, why it is necessary in the first place, because all queries I tried so far return the id and name already. In other words, I think it might be better to make sure the id and name are returned by the API than to add it to the results after the fact (unless the former is not possible for some reason).
IMHO it is best to handle the Amtlicher Gemeindeschlüssel as an ID with leading zeros and therefore as of type
character
, see for example Amtlicher Gemeindeschlüssel (AGS): Definition - Statistisches Bundesamt or Amtlicher Gemeindeschlüssel – WikipediaThis PR therefore imports the regions.csv with
id
(and all variables, like before) set tocharacter
. I also simplified theget_region()
function a bit. It now uses the relatively new curly-curly rlang syntax, i.e. it requires rlang >= 0.4.0. If that is a problem, we can revert to the!!enquo()
syntax used before, see https://github.com/CorrelAid/datenguideR/commit/2835e1860ce20ab98477fd1dddaf6df652ac5644.The
left_join()
ofdg_regions
to theapi_results
indg_call()
could also be simplified now. I don't understand yet, however, why it is necessary in the first place, because all queries I tried so far return theid
andname
already. In other words, I think it might be better to make sure theid
andname
are returned by the API than to add it to the results after the fact (unless the former is not possible for some reason).