Incorporate with rio?

[jhollist]

@rkrug I agree that having some simpler wrappers to rgdal for GeoPackage (and other spatial data) would be useful. Are you familar with rio? If you aren't, the basic idea is similar to what you've proposed with rGeoPackage. A simplified import and export functionality.

There is a fairly simple extension mechanism and might be nice to build up a set of spatial imports that make reading in data with rgdal easier with just an import("mydata.gpkg"), import("mydata.shp"), etc. Simple export and conversion could also be supported.

I'd be happy to contribute to this effort and will watch this repo!

[mdsumner]

I think this is a good idea. Also, the focus on GeoPackage is a bit too specific - this could simply be a simplification of read/writeOGR that does nice things for any GDAL vector data source:

• assume first layer is to be read, and report on other layers (a la raster() on a 3D data set)
• report on anything that's available about the data source, even if reading fails

But, it does make sense to have a format-specific project for investigating the space here. There's a similar issue with NetCDF and related formats for rio - the scope is huge, these formats are very general!

[jhollist]

@mdsumner Keeping this space to begin to flesh out the idea does make sense.

Also, agree that rio for spatial is a broad topic. You mention raster and that already does simplify reading in a lot of raster formats. Maybe a focus on vector only would be a good first step. I'd bet with 5 or 6 formats (geopkg, shp, file geodatabase, geojson/topojson, and WKT) you'd take care of a large majority of use cases.

[rkrug]

@jhollist That sounds like an interesting idea.

But one aspect is missing from rio: the possibility to register additional formats. I think it is the wrong approach to have the responsibility to implement new formats to the authors of the package. It would be much better to have a system where one has a basic set of formats supported, and additional can be registered easily. Looking at the code of rio, that shlould not be to difficult.

But I agree with mdsumner that this leads away from the discussion of rGeoPackage, in which a the GeoPackage format should be supported not only for reading and writing, but possibly also metadata, comments and other things. So one could keep rio in mind, but focus here on GeoPackage. rGeoPackage could then become one "provider" for a rioSpatial package.