[gdal-dev] Validate_gpkg and TEXT with length

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] Validate_gpkg and TEXT with length

jratike80
Hi,

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 ).

-Jukka Rahkonen-
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Validate_gpkg and TEXT with length

Even Rouault-2

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


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Validate_gpkg and TEXT with length

jratike80
In reply to this post by jratike80
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-
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev