NOTE: rgdal::checkCRSArgs: no proj_defs.dat in PROJ.4 shared file

[irenge]

when i run readOGR(".", "E06000042") on Rstudio on a Fedora 23 , 64bit, it brings me this problem ,
it runs but bring me this warning NOTE: rgdal::checkCRSArgs: no proj_defs.dat in PROJ.4 shared files
Any assistance please.
Thanks

[hobu]

No idea, but this looks like an rgdal issue. @rsbivand I assume you know what this issue represents.

[irenge]

Thanks for your reply Hobu , but I m completely newb to R , just venture in like one week ago and stumbled on this issue . Is it a bug that is awaiting to be fixed ?

[rsbivand]

This is caused by PROJ 4.9.0 and 4.9.1 being released without the nad/proj_defs.dat, which inserts automatically ellipsoid settings if none are given by the user. You can see this in the proj list thread: http://lists.maptools.org/pipermail/proj/2015-September/007209.html
and an issue from May last year: #274

The resolutions are either to add the missing file to the share/proj folder from:
https://github.com/OSGeo/proj.4/blob/master/nad/proj_def.dat
or update your PROJ to 4.9.2 (or a patched 4.9.1 - I seem to recall Fedora/RHEL packagers responding to the cited thread. It was Howard who committed the required fixes in Proj, but he is so busy that it slipped his mind. Bottom line, 4.9.0 and 4.9.1 as released (unpatched) are critically broken when users do not explicitly declare +ellps= (or equivalents). 4.9.2 is fine. The message is to alert the user to the need to fix their PROJ4. Users of Windows and OSX CRAN binaries of rgdal are protected already because Proj is statically linked and the missing file added to share/proj, but if you install rgdal from source and provide your platform PROJ, rgdal will try to protect you from known issues in your installation. Googling for proj_defs.dat would have told you all of the above.

[irenge]

Thanks , so i either create a folder called nad in the /usr/share/proj directory and input the proj_def.dat inside or i remove rgdal and compile it from source

[rsbivand]

No, neither. nad/proj_defs.dat is where it is in the sources. Place a copy of proj_defs.dat in /usr/share/proj and see whether the message disappears. Better still, upgrade proj to 4.9.2, which fixes other bugs too. None of this is a PROJ issue, as it was resolved when 4.9.2 was released.

[irenge]

thanks for your help , i compile the file https://github.com/OSGeo/proj.4 install then it installed in /usr/local/share/proj then i moved the file to /usr/share/ , replacing the proj file overther and it worked . i was almost giving up . ha ! almost thought of buying a laptop with windows OS

[irenge]

[coreysparks]

I just compiled the proj.4 and rgdal found it automatically, didn't have to move it to /usr/share

[Tzhong16]

Hi, coreysparks

I am interested in your solution, do u mind share it here? thankyou

[rsbivand]

@Tzhong16 : what is your question? If this is an R-sig-geo question, ask on R-sig-geo. Always state your OS, and if you installed PROJ.4, how you did that and what version. Before, Windows users were those who simply assumed that everyone used the same systems as they did, now it is definitely OSX user, who expect things to happen without any effort from them. If you are an OSX user of the CRAN rgdal binary, and are seeing the above message:

"Until we get it fixed, please see if you can download the equivalent Windows binary package:

https://cran.r-project.org/bin/windows/contrib/3.3/rgdal_1.2-5.zip

unzip it (do not install it), and copy the proj/ and gdal/ folders with
their contents to the folder shown (in R) by:

system.file("", package="rgdal")

The problem you found was that the person building CRAN rgdal OSX binaries
forgot to set configure arguments to package these two folders."

[Tzhong16]

Thank you so much for your reply, @rsbivand. Finally I solve the problem.

What I did:
my system : macOS Sierra 10.12.3

Step 1: Install PROJ.4

Before install PROJ.4 I need to install xcode from App Store

I follow the the website to install my PROJ.4
https://docs.djangoproject.com/en/1.10/ref/contrib/gis/install/geolibs/

curl -O http://download.osgeo.org/proj/proj-4.9.1.tar.gz
curl -O http://download.osgeo.org/proj/proj-datumgrid-1.5.tar.gz
........
.........
..........

Step 2: Add missing file proj_def.dat

the proj default install to /usr/local/share/
add the missing file proj_def.dat into /usr/local/share/proj
the proj_def.dat download from https://github.com/OSGeo/proj.4/blob/master/nad/proj_def.dat

Step3: Copy the proj document from /usr/local/share/ to /usr/share/

sudo cp -R /usr/local/share/proj /usr/share/

Before copy the proj document from /usr/local/share/ to /usr/share/ , you need to disable Apple's
System Integrity Protection (SIP) on your Mac. Otherwise, /usr/share/ cannot be write

disable Apple's SIP can follow http://apple.stackexchange.com/questions/208478/how-do-i-disable-system-integrity-protection-sip-aka-rootless-on-os-x-10-11

Remember enable SIP after your copy.

[erpansing]

os x version 10.12.2, R version 3.3.2 sincere pumpkin patch

I addressed this issue using the fix available here:
https://geographicdatascience.com/2017/01/17/solutions-to-the-proj4-issue-with-rgdal-in-r/

[rsbivand]

I am the rgdal maintainer. Do listen when I tell you what to do: what I say is authoritative:

If you are an OSX user of the CRAN rgdal binary, and are seeing the startup warning message, check the contents of:

list.files(system.file("", package="rgdal"))

If the proj and gdal directories are missing, you have installed a recent CRAN OSX binary which was built without two key metadata directories. Repeating:

"Until we get it fixed, please see if you can download the equivalent Windows binary package:

https://cran.r-project.org/bin/windows/contrib/3.3/rgdal_1.2-5.zip

unzip it (do not install it), and copy the proj/ and gdal/ folders with their contents to the folder shown (in R) by:

system.file("", package="rgdal")

The problem you found was that the person building CRAN rgdal OSX binaries forgot to set configure arguments to package these two folders."

This is also mentioned on the authoritative list, the one package maintainers follow, look for this thread.