[Geopackage] gpkg_contents when type is not 'feature' or 'tiles'

Pepijn Van Eeckhoudt pepijn.vaneeckhoudt at luciad.com
Fri Nov 7 12:00:07 EST 2014


The template SQL query I've always had in mind that applications would 
use to discover supported dataset is more or less

select c.table_name from gpkg_contents as c where
   c.data_type in (<supported data types>)
and
   not exists (
     select * from gpkg_extensions as e where
       (e.table_name is null or e.table_name = c.table_name)
     and
       extension_name not in (<supported extensions>)
   );

A global extension kind of breaks this.

I don't think putting a new data type in gpkg_contents should make the 
entire database inaccessible. There might still be vanilla tile or 
feature data sets that an application could display.

Pepijn

On 07/11/14 17:31, Even Rouault wrote:
> Forwarding the question/observation to Robert Coup & Ryan Lewis
>
> But I guess that putting a new value in the data_type column of gpkg_contents
> makes that the whole geopackage must support the extension, i.e. must be able
> to deal with a value that is neither 'features' nor 'tiles'.
>
> Le vendredi 07 novembre 2014 17:26:10, Pepijn Van Eeckhoudt a écrit :
>> Cool, that's the first public extension in the wild that I know of.
>>
>> Even, is it the intention that this gets applied to the entire
>> geopackage (table_name == NULL)? Or should it be applied only to the
>> aspatial tables themselves (and perhaps any feature tables that have a
>> foreign reference to the aspatial table)?
>> Applying a read-write extension to the entire geopackage means that
>> applications that don't recognize the extension will most likely reject
>> the geopackage as a whole; not just the tables that aren't supported.
>>
>> Pepijn
>>
>> On 07/11/14 16:52, Even Rouault wrote:
>>> Le vendredi 07 novembre 2014 16:45:37, Pepijn Van Eeckhoudt a écrit :
>>>> Hi Patrick,
>>>>
>>>> There was a very similar question on the mailing list some time ago
>>>> (look for thread 'Aspatial Tables with Metadata').
>>>> Two strategies were proposed then:
>>>> - Register the table as 'features' and apply a 'no geometry' extension
>>>> to it - Register the table as 'aspatial'
>>>>
>>>> I'm not sure which approach the person asking the question end up
>>>> taking.
>>> --> aspatial extension: http://www.gdal.org/geopackage_aspatial.html
>>>
>>>> Pepijn
>>>>
>>>> On 06/11/14 12:14, Patrick van Dijk wrote:
>>>>> Hi,
>>>>>
>>>>> I'd like to register my alpha only table (e.g. no geometry field)
>>>>> table in gpkg_contents as I can then store an identifier
>>>>> and description for the table and I can also add additional field
>>>>> information in gpkg_data_columns.
>>>>>
>>>>> So my suggestion is to create a gpkg_contents record with its
>>>>> data_type set to 'alpha' (instead of feature).
>>>>>
>>>>> Req 13 explains the gpkg_contents table for field data_type.
>>>>>
>>>>> Type of data stored in the table:.
>>>>> “features” per clause 2.1.2.1.1,
>>>>> “tiles” per clause 2.2.2.1.1, or
>>>>> an implementer-defined value
>>>>> for other data tables in an
>>>>> Extended GeoPackage.
>>>>>
>>>>> So I guess, what I want to do is fine.
>>>>>
>>>>> Am I right?
>>>>>
>>>>> Patrick

-- 
Luciad Email Signature *Pepijn Van Eeckhoudt*
Senior Software Architect

*LUCIAD* <http://www.luciad.com/> CONNECT •  VISUALIZE •  ANALYZE •  ACT

pepijn.vaneeckhoudt at luciad.com <mailto:firstname.lastname at luciad.com> • 
  T +32 16 23 95 91
Follow us on LinkedIn <https://www.linkedin.com/company/luciad>or 
@LUCIADconnect <http://www.twitter.com/LUCIADconnect>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geopackage/attachments/20141107/cf966fc5/attachment.html>


More information about the Geopackage mailing list