ropensci / osmdata

R package for downloading OpenStreetMap data
https://docs.ropensci.org/osmdata
314 stars 45 forks source link

Consider replacing the dependency on rproj with sf #271

Closed jlacko closed 2 years ago

jlacko commented 2 years ago

Dear maintainers,

first of all let me thank you for this package; it is awesome and makes my life so much easier!

Secondly: your package depends on {reproj}, which in turn depends on {proj4} package. The {proj4} package is by now somewhat dated, and has issues with current releases of PROJ library (tested on PROJ 9.0.0), in effect making the entire {osmdata} package unable to install from source - which is somewhat unfortunate given the recent release of R 4.2.0 & associated invalidating of packages built under R 4.1.X

Given that the reproj package seems to be used in a limited fashion (I count 3 calls in trim-osmdata.R, but I may be wrong) it need not be too much of an effort to adjust the code to use the {sf} package instead - which is arguably the current go-to tool for reprojecting vector data.

I would be happy to provide a pull request with the functionality described in the paragraph above, if agreeable to the maintaners.

Thanks for your consideration!

mpadge commented 2 years ago

Thanks @jlackom, that's actually not directly an issue because proj4 is regularly updated, and is works with any locally installed PROJ >= 4.4.6, including up to v8.X. Any breaking changes with v9 will be addressed by proj4, and need not be addressed here. The latest update was at the end of Jan 2022, presumably in response to PROJ 8.2.1 release on Jan 1st. PROJ9 was only released 1st March, so I guess updates will ensue.

Importantly, note that this package has been designed from the outset to have as minimal a dependency footprint as possible, and so does not depend on sf, which is way too large a dependency just to implement coorindate transformations. One viable alternative would be tolink to the libproj package and write the required functions directly in C++ using the header files exposed there. But that package bundles its own internal version of PROJ, so still has a pretty large footprint. That all means that proj4 remains the most convenient way to link this package to system-installed versions of PROJ, so will continue to be used for the timebeing.

mpadge commented 2 years ago

Update: I just did a complete install of PROJ9 from source and was able to install both proj4 and osmdata. So the issues you mention would seem to be OS-specific, and not general. Feel free to provide further detail if you like. Thanks

jlacko commented 2 years ago

Thank you for your considering my suggestion. I have resolved my immediate issue via a workaround, but I felt that other users might not be in position to do so - I use {osmdata} in teaching, and I know how challenging environment issues can be to some students + how awkward it is to have to use valuable lecture time to help with troubleshooting installations.

But if my issue was specific to me - my bad for not checking more widely before opening a ticket - it likely does not deserve a change of projecting approach.

In addition I agree in principle with your dependency light approach; {sf} is a beast of a package.

So thank you, and I agree to have this rest.

mpadge commented 2 years ago

Great, thanks @jlacko, and no worries about not checking. PROJ9 updates are a work in progress in many ways...