[gdal-dev] Validate_gpkg and TEXT with length

Rahkonen Jukka (MML) jukka.rahkonen at maanmittauslaitos.fi
Tue Mar 13 03:22:28 PDT 2018


Even Rouault wrote:

>Jukka,
 
>> 
>> I checked some .gpkg database that is created by FME with the
>> validate_gpkg.py script. It gives this error:
>> 
>> __main__.GPKGCheckException: Req 5: table stand has column
>> standnumberextension of unexpected type TEXT ( 2 )
>> 
>> Excerpt from the standard:
>> TEXT{(maxchar_count)}
>> Variable length string encoded in either UTF-8 or UTF-16, determined by
>> PRAGMA encoding; see http://www.sqlite.org/pragma.html#pragma_encoding The
>> optional maxchar_count defines the maximum number of characters in the
>> string. If not specified, the length is unbounded. The count is provided
>> for informational purposes, and applications MAY choose to truncate longer
>> strings if encountered. When present, it is best practice for applications
>> to adhere to the character count. Stored as SQLite TEXT
>> 
>> Unfortunately there is no example in the standard about how the text field
>> with maxchar count should be created correctly and how it should appear in
>> the PRAGMA. I wonder if the error is caused by the spaces around number 2
>> in TEXT ( 2 ).
 
> Yes this is due to spaces.
 
> My understanding of the specification text, confirmed by the official test suite in
> https://github.com/opengeospatial/ets-gpkg12/blob/02ba0439a4d060c6cb036caa5d8225e18241e8e6/src/main/java/org/opengis/cite/gpkg12/core/DataContentsTests.java#L266
> is that spaces are not allowed, so this should be TEXT(2)
 
> The OGR driver will just recognize TEXT (2) as TEXT.

Hi,

It appeared that this suspicious GeoPackage database was initially created with some generic SQLite database design tool. FME and GDAL were only used for inserting data into already existing tables and they were not involved with the non-GeoPackage standard conformant  contents in sqlite_master. Be aware when using such tools because what is OK for SQLite is not necessarily OK for the gpkg standard.

Good news is that the validate_gpkg.py script was able to find this issue. 

-Jukka Rahkonen-


More information about the gdal-dev mailing list