More options on `get_eurostat_geospatial()`

[dieghernan]

I love the capability of downloading shapes from GISCO, but there are a couple of features that I miss on the get_eurostat_geospatial() function:

• Currently, only epsg=4326 is downloaded: https://github.com/rOpenGov/eurostat/blob/6e10b309aebd6b01c464d97ffaddefd2c16191d0/R/get_eurostat_geospatial.R#L170

  It is fine since it can be projected but GISCO also distributes another projection (3035, 3857) that are more suitable. I suggest to add a new parameter to the function (sf package uses crs like on st_transform) with a default value to 4326 to ensure backwards compatibility.

• NUTS 2021 is already available in GISCO. I am not sure on this one since NUTS2021 hasn't been officially released, but since is available it might be a good idea to have the chance of working with it in advance.

https://github.com/rOpenGov/eurostat/blob/6e10b309aebd6b01c464d97ffaddefd2c16191d0/R/get_eurostat_geospatial.R#L69-L71

As an example, this line works fine just including 2021 as the year:

https://github.com/rOpenGov/eurostat/blob/6e10b309aebd6b01c464d97ffaddefd2c16191d0/R/get_eurostat_geospatial.R#L160

http://ec.europa.eu/eurostat/cache/GISCO/distribution/v2/nuts/geojson/NUTS_RG_60M_2021_4326_LEVL_0.geojson

Both enhancements are quick to implement in my opinion (happy to help with them).

I have another suggestions regarding the accessibility to another GISCO data (countries, boundaries, labels, LAU, Urban Audits… see full GISCO API) but they would imply a deeper review of the source code, so I may open a specific issue on that.

Regards

[antagomir]

Great - the easiest could be if you can make a Pull Request. Seems appropriate to me.

[dieghernan]

The PR is ready now, you can check it here.

I checked on appveyor (OK), however I got an error on travis:

Installing R dist: trusty is no longer supported for language: r

So I just checked on a test branch removing dist: trusty of .travis.yml and it worked to (see here). Now travis used dist: xenial as default.

I just want you to be aware, probably if you trigger now a fake build on this repo´s travis you'll likely to get the same message than I got.

Let me know what you think, regards

[antagomir]

Great, thanks! I will wait until tomorrow to see if there are any comments before I merge.

[dieghernan]

PR accepted so this issue can be closed.

I am working on more contributions related with GISCO data, I'll better open new issues for better tracking.

Many thanks to devs and maintainers

[antagomir]

Thanksss!

[dieghernan]

Sorry to reopen this issue. I have spotted some soft improvements and fixes on this:

• Fix typo: https://github.com/dieghernan/eurostat/commit/5c7e20590ef3cb0fd4116804e7d49931c6df871a
• Move comparison to string\string instead of string\integer (now it is year == "2016"). Although string\integer worked it seems just right to perform the comparison between the same data types: https://github.com/dieghernan/eurostat/commit/f93714b18277b4bebcb1905302ced73c414f5302
• Update for caching, so now it is crs-aware. I didn't spotted this one, meaning that get_eurostat_geospatial(year =2013, crs=4326) and get_eurostat_geospatial(year = 2013, crs=3857) produced the same result (since 4326 was cached in first place and 3857was updated from cache). Potential workaround is to set update_cache = FALSE).

PR on the way, regards