Is geopackage-validator a suitable tool for validating gpkg in general (not specifically for PDOK)

[velle]

I was looking for a tool for validating my geopackages and I found this one. I only read the documentation cursorily and missed the fact that it was built specifically to validate for PDOK-requirements. I only realized this a few days later. I am not working with/for PDOK, and in fact I never heard of it before.

It seems this tool was built/supported/sponsored by Dutch authorities to meet their needs and my needs/questions are outside the scope. But perhaps this question will help others like me looking for such tools :)

Which of the RQ and RC are specific for PDOK? If most of them are, then perhaps there are better tools for validating geopackages that I should use intstead. Are you able to recommend other tools for validating geopackage files when not writing for PDOK?

Sincerely

[RoelvandenBerg]

I will have updated the README to make this more clear.

Geopackages are a data format that have a deliberately broad application, so many of the requirements are dependent on your use.

Excluding the legacy ones the validations that you need in case you want to have a valid geopackage:

• RQ5
• RQ13
• RQ15
• UNKNOWN_ERROR

I would advise:

• RQ9 (rtree validation)
• RQ10 (rtree validation)
• RQ11 (OGR indexed feature counts)
• UNKNOWN_WARNINGS

Dependend on your situation:

• RQ2 <- it is possible to have geopackages with tables with no data. This does not fit our requirements though and it is a good thing to check if you expect there to be data.
• RQ4 <- if you do not want views to be defined
• RQ7 <- good to have an index
• RQ8 <- in case you want to validate against an expected schema
• RQ14 <- this is a subset of the possible values
• all recommendations as yet (RC17 trhough RC20)

PDOK specific:

• RQ6
• RQ12
• RQ16

The table:

Validation code**	Description
UNKNOWN_ERROR	No unexpected (GDAL) errors must occur.
RQ0	LEGACY: * Geopackage must conform to table names in the given JSON or YAML definitions.
RQ1	Layer names must start with a letter, and valid characters are lowercase a-z, numbers or underscores.
RQ2	Layers must have at least one feature.
RQ3	LEGACY: * Layer features should have an allowed geometry_type (one of POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, or MULTIPOLYGON).
RQ4	The geopackage should have no views defined.
RQ5	Geometry should be valid.
RQ6	Column names must start with a letter, and valid characters are lowercase a-z, numbers or underscores.
RQ7	Tables should have a feature id column with unique index.
RQ8	Geopackage must conform to given JSON or YAML definitions.
RQ9	All geometry tables must have an rtree index.
RQ10	All geometry table rtree indexes must be valid.
RQ11	OGR indexed feature counts must be up to date.
RQ12	Only the following EPSG spatial reference systems are allowed: 28992, 3034, 3035, 3038, 3039, 3040, 3041, 3042, 3043, 3044, 3045, 3046, 3047, 3048, 3049, 3050, 3051, 4258, 4936, 4937, 5730, 7409.
RQ13	It is required to give all GEOMETRY features the same default spatial reference system.
RQ14	The geometry_type_name from the gpkg_geometry_columns table must be one of POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, or MULTIPOLYGON.
RQ15	All table geometries must match the geometry_type_name from the gpkg_geometry_columns table.
RQ16	All layer and column names shall not be longer than 53 characters.
RC17	It is recommended to name all GEOMETRY type columns 'geom'.
RC18	It is recommended to give all GEOMETRY type columns the same name.
RC19	It is recommended to only use multidimensional geometry coordinates (elevation and measurement) when necessary.
RC20	It is recommended that all (MULTI)POLYGON geometries have a counter-clockwise orientation for their exterior ring, and a clockwise direction for all interior rings.
UNKNOWN_WARNINGS	It is recommended that the unexpected (GDAL) warnings are looked into.