I'm using R (v4.0.3) on my university's High Performance Computing cluster, loading gdal (v3.3.1), geos (v3.6.1), sqlite (v3.32.3), udunits (v2.2.26), and proj (v7.1.0) libraries prior to opening R. With both sf and terra packages, I have been unable to open .gpkg files. The sf package returns Error: Cannot open "library/4.0/sf/gpkg/nc.gpkg"; The source could be corrupt or not supported. See st_drivers() for a list of supported formats. while the terra package returns Error: [vect] Cannot open this file as a SpatVector.

I am able to open geopackage files just fine outside of the HPC system (on my own Mac laptop and a Windows computer that's accessed remotely), so I'm not sure why it doesn't work on the HPC?

Here's some code just to read in gpkg files using the sf package.

gfile <- system.file("gpkg/nc.gpkg", package = "sf", mustWork = TRUE)
test <- read_sf(gfile)
  • Have you take the advice to See st_drivers() for a list of supported formats.? I'd guess your GDAL on the HPC was compiled without GeoPackage support for some reason. Ask your admins to try again with GeoPackage support. You could compile GDAL yourself but its a headache especially when it requires system packages and you dont have root permissions. But check st_drivers to see if I'm on the right lines first...
    – Spacedman
    Sep 9, 2021 at 19:08
  • I had, and GeoPackage isn't actually on the list, and that was when the GDAL version was 2.2, so I had requested the admin to update to the most recent one, but that didn't resolve the issue... I will check about compiling GDAL with GeoPackage support, that sounds like a step in the right direction, thanks! Sep 10, 2021 at 8:33
  • Also note that HPC are often connected to distributed file systems. In my experience sqlite and derivatives (like gpkg) do not play well with distributed file systems. If the problem persists after resolving the driver issue, this could be an explanation for the error. Sep 10, 2021 at 11:32

1 Answer 1


The GeoPackage driver for GDAL requires an installation of sqlite3 since the underlying database is an SQLite3 file. On a system without an sqlite3 installation, when configuring GDAL for building it will skip the GeoPackage driver. An admin unaware of the importance of GeoPackages might not be concerned by this since several other messages about drivers might be appearing, and they may assume this is not important. Not having sqlite3 is probably the most common cause of lack of GeoPackage support in GDAL.

The driver docs for GeoPackage are here, and give the dependencies:


A correctly installed GDAL with GeoPackage support can be detected this way from the Unix command line (to save an Admin having to run R):

$ ogrinfo --formats | grep GPKG
  GPKG -raster,vector- (rw+vs): GeoPackage

Note that any R packages using GDAL will need to be reinstalled from source after GDAL changes.

GeoPackage support in R can be tested using R at the command line:

$ R -q -e '"GPKG" %in%  sf::st_drivers()$name'

which should print TRUE and not FALSE.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.