So, installing rgdal, which is an important R package for spatial data analysis can be a bit of a pain on the mac. Here are two ways to make it happen.
The Easy Way
- In R run: install.packages(‘rgdal’,repos=”http://www.stats.ox.ac.uk/pub/RWin“)
The Hard Way
- Download and install GDAL 1.8 Complete and PROJ framework v4.7.0-2 from: http://www.kyngchaos.com/software/frameworks%29
- Download the latest version of rgdal from CRAN. Currently 0.7-1
- Run Terminal.app, and in the same directory as rgdal_0.7-1.tar.gz run:
R CMD INSTALL --configure-args='--with-gdal-config=/Library/Frameworks/GDAL.framework/Programs/gdal-config --with-proj-include=/Library/Frameworks/PROJ.framework/Headers --with-proj-lib=/Library/Frameworks/PROJ.framework/unix/lib' rgdal_0.7-1.tar.gz
6 replies on “Installing rgdal on a Mac”
NO!! Please do check properly, also for logic, before giving advice.
In the easy way, all you need to do is:
setRepositories(ind=1:2)
install.packages(‘rgdal’)
because the ind=2 repository, CRAN extras, includes all the binary dependencies built for Intel architectures (generously built and updated by Prof. Brian Ripley). The install from KyngChaos will not interface the CRAN extras rgdal binary and is redundant. This has been repeated time and again on the R-sig-geo list. The rgdal page on CRAN says: “rgdal binaries for OSX are available from the CRAN (extras) repository”.
If however you need the extra drivers in William Kyngesburyes version, you can install his rgdal binary of 0.6-33 for R 2.12 or R 2.13, available a little further down the quoted page at GDAL. The CRAN rgdal changelog from January 2011 shows which changes are made subsequent to the release of 0.6-33, mostly modifying error handling, not at the user level. If you need the current version with KyngChaos frameworks, install from source as indicated, but making sure that the configure arguments are appropriate for your platform.
I would be obliged if this comment could also be flagged on rbloggers.com, as people unfortunately do not usually bother to read more than the first few lines of entries.
Thank you for the contribution. The post has been edited to remove the framework install from the “easy way.”
I might add that if the issue comes up “time and again” then perhaps you have not been clear enough in communicating the proper install procedure. How is the user supposed to know where/what the CRAN extras repository is, or how to access it? The pages that come up searching for “rgdal mac install” are less than informative on the subject of doing a simple binary install.
You haven’t fed through to rbloggers, as for instance an erratum.
Why should it be easy? It isn’t easy for any other “unix” platform, it is only “easy” for Windows because there is no way that a regular Windows user will be able to install the compile and build trains needed even to link to GDAL, PROJ.4 and Expat libraries. Even I have not succeeded in building current GDAL on Windows using the standard MinGW compilers.
The reason for the difference between Windows and OSX is that Prof. Brian Ripley and Uwe Ligges can insert the external dependency binaries into the CRAN build train, but cannot do this for OSX. Consequently, Prof. Ripley hosts his OSX rgdal binaries in his own repository, for which he deserves considerable thanks. The level of complexity in rgdal and its external dependencies is substantial, and it does no harm if the user has to learn something more about the computing systems s/he is using along the way.
With regard to clarity – had we had one and only one channel to which users would turn, things would be easy. However, the blogosphere and similar stackoverflows are dominated by half-baked information that gets SOE’d ahead of anything as simple are reading the CRAN package page, which says what I quoted. Should it say “I think OSX users are dumb, so I’ll explain what the CRAN extras repository is too”? It is in the R FAQ 5.1.2, foot of section. I don’t think making it plainer there (that is in the DESCRIPTION file for the package for all platforms) would help – people don’t read before complaining.
If someone with plentiful access to time, OSX platforms, and leverage with the R OSX CRAN build system could ensure that the external dependencies were met there, so that it was built in the standard way, the problems would go away. So far, nobody has stepped forward. Every time someone complains about rgdal/OSX, my motivation to continue maintaining rgdal takes a hit, I’m afraid.
For me, it does add some harm to have a non-trivial set-up process. The spatial GUI package that I developed is going to be distributed and used by high school students and teachers (see: two posts ago). Simplicity of install is key in this regard.
The reason I had the extra step (which did not harm anything by the way…) was that I thought that the binary provided by Brian Ripley was just the rgdal package binary assuming a framework install, not self contained rgdal/GDAL/PROJ.4 binary. Binary used in this sense is ambiguous.
Your tone is snarky and confrontational, but I’ll answer your rhetorical question anyway. No, the DESCRIPTION shouldn’t say “I think OSX users are dumb, so I’ll explain what the CRAN extras repository is too.” It should say “Mac OS X binaries (including GDAL and PROJ.4) are not maintained on CRAN, but can be installed from the CRAN Extras repository with: setRepositories(ind=1:2);install.packages(‘rgdal’)”
Perhaps your motivation would take fewer hits if you added this sentence.
We would prefer that they were built in the usual way – like Windows – but the OSX build lead has other priorities. It is unusual to include platform-specific information in a DESCRIPTION file. Committed on R-Forge – please check here.
My tone would be less “snarky” if (say) before posting and being unsure, you had asked me (package maintainer) first. I would have replied promptly with the correct information, and it would have taken me less time than having to monitor rbloggers and responding to inaccurate and obviously flawed (did you check the shared object size in the CRAN extras binary – it is built static and includes all relevant parts of GDAL, PROJ.4, and Expat?) postings. No, you didn’t check – running gdalDrivers() in R against gdalinfo –formats on the command line would show the difference (two different GDAL libraries).
The key difference which you still haven’t mentioned is that GDAL provides varied sets of drivers for different file formats, depending on its external dependencies, with CRAN extras having a restricted set and KyngChaos a broader set, so the user choice is really between a default set of drivers (CRAN extras) and an extended set (Kyngchaos). In addition, only KyngChaos may permit PPC installation (if the user has XCode – a recent user had too liitle free disk to install, so we couldn’t confirm this). I don’t see that you mentioned the need to install XCode and other source package install tools before trying the KyngChaos route.
With reference to your needs and OSM – did you choose not to use osmar on CRAN? It may be orthogonal to your use. There is also plotKML on R-Forge.R-project.org.
I’m glad that something constructive has come out of this conversation.
osmar and plotKML are two interesting projects. What makes DeducerSpatial’s OSM map loading and plotting functions different is that they are not file based. The images are loaded into memory and plotted on standard R graphics devices, rather than downloaded to png (or jpeg). The ability to do these plots with pure R code is important, but only a part of what DeducerSpatial does. The majority of the code is devoted to a Java based GUI where you can plot your data on a map, zoom/pan the view (as you would on Google Maps), and graphically subset your spatial data based on a bounding box drawn on the map. This is all made possible by integrating the JMapViewer library with R graphics.