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

Pepijn Van Eeckhoudt pepijn.vaneeckhoudt at luciad.com
Fri Nov 7 11:26:10 EST 2014


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/086fb491/attachment.html>


More information about the Geopackage mailing list