GeoPackage validation routine

[brownag]

• check for required tables
• check for consistency between tables (foreign key relationships)
• check for duplicate entries within tables (violated primary key constraints)
• ?
  

  gpkg/R/gpkg-validate.R

  Lines 1 to 12 in c813561

  	#' Validate a GeoPackage
  	#'
  	#' Checks for presence of required tables, valid values and other constraints.
  	#'
  	#' @param x Path to GeoPackages
  	#' @param diagnostics Return a list containing diagnostics (missing table names, invalid values, other errors)
  	#'
  	#' @return `TRUE` if valid. `FALSE` if one or more problems are found. For full diagnostics run with `diagnostics = TRUE` to return a list containing results for each input GeoPackage.
  	#' @export
  	gpkg_validate <- function(x, diagnostics = FALSE) {
  	stop("This is not implemented yet")
  	}

[brownag]

• In 37029a1 implemented basic gpkg_validate() routine (will be expanded)
  • Checks that gpkg_contents and gpkg_spatial_ref_sys exist
  • Checks that at least one tile or vector dataset (with at least 0 rows) is in the database and gpkg_contents

I think it should not be necessary to check for duplicate records--as unique constraints that (should be) set when creating required tables will cover this. If functions outside this package, and non-standard SQL is used, then the file is not a GeoPackage--technically speaking.

I don't think it is worth necessarily validating all triggers/unique/key constraints, but perhaps checking required gpkg_contents and gpkg_spatial_ref_sys table definitions against a lookup table would be a good addition. GDAL does it properly, the methods in this package do it properly, so it would simply be a protection against other avenues that might create these tables, or the user running custom gpkg_execute() statements