Open ouzor opened 10 years ago
Issue needs a bit more description.
The shape files for each election district division mentioned above are available from different sources. It would be handy to have a function to retrieve the selected division, for instance: "get election districts used in Turku 2014". Helsinkin districts are available through HRI, Turku districts from Lounaispaikka
What I had in mind here was function get_election_district(city, year), and then each available combination would be hard coded. So currently combinations (Helsinki, 2011), (Helsinki, 2014), and (Turku, 2014) would work, others would result in NULL.
Is there anything else but Helsinki in the package currently (a83a0cbcb5dad598d1d7902d57bd8db5de34cf39)?
No, there's currently only election maps for Helsinki region (year 2011), implemented in get_helsinki_aluejakokartat(). So it should be removed from there, and created to a new function get_election_districts(). Then (Helsinki, 2014) and (Turku, 2014) could be added to the new function.
At least not for Turku but the shape files for that would be readily available from Lounaispaikka as soon as there is time to add to package. Check http://paikkatietokeskus.lounaispaikka.fi/fi/aineistot/ for "Turun Kaupungin Äänestysaluerajat" and also many other GIS data sets
Right, I'll see what I can do for rOpenGov/gisfin#11 first and then can come back to this unless someone wants to take a stab at it.
I created a new branch fix/issue9 which has the following new features:
download_data()
get_helsinki_aluejako()
renamed to get_helsinki_adminboundaries()
which now uses download_data()
turku_spatial.R
which a single function get_turku_adminboundaries()
which functions analogously to its Helsinki-counterpart
Next steps from here:
get_election_districts()
which could call get_helsinki_adminboundaries()
and get_turku_adminboundaries()
accordinglyNote also that get_helsinki_adminboundaries()
and get_turku_adminboundaries()
are structurally very similar and could be refactored into a single function. The most flexible approach would be to separate the data source definitions from the implementation, e.g. a JSON or YAML file could include the necessary URLs, layer names, EPSG codes, years etc. Might be a bit of a pain to implement this, but the outcome would be much easier to maintain than coding an almost identical function for each city or creating one massive function with all the information hard coded. Thoughts?
Sounds excellent! I agree that my first implementation had a lot of repetition and hard coding, so you suggestion sounds much more easier to maintain in the future when the number of data sets (and cities providing data) will grow.
Update then data(aluejakokartat) in helsinki.