[gdal-dev] Validate_gpkg and TEXT with length

Even Rouault even.rouault at spatialys.com
Wed Mar 7 14:08:16 PST 2018


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.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20180307/827b7dcb/attachment.html>


More information about the gdal-dev mailing list