Non-spatial attribute data are entities (e.g., tuples or rows) of observations that may not have an explicit geometry property. In GeoPackage, this data is stored in user-defined attribute tables. These tables may contain properties such as an ID or geo-locatable address that allow them to be relationally linkable to rows in other attribute, feature or tile tables.
Examples of attribute data include:
-
meteorological readings from a weather station
-
flow readings from a stream gauge
-
traffic volumes from embedded highway sensors
-
lists of customers
-
delivery stops
-
work orders
Non-spatial attribute data is stored in user-defined Attribute tables. Attribute sets are rows in an Attribute table. The attributes are columns in a Attribute table. (A GeoPackage is not required to contain any Attribute data tables. Attribute data tables in a GeoPackage may be empty.)
A GeoPackage MAY contain tables containing attribute sets. Every such attribute table SHALL be structured consistently with Table 1 and [example_attributes_table_sql].
A table SHALL have a primary key column of type INTEGER and that column SHALL act as a rowid
alias.
Note
|
The integer primary key of an attributes table allows features to be linked to row level metadata records in the |
A GeoPackage MAY contain views containing attributes. Every such attributes view SHALL have a first column of type INTEGER and that column SHALL contain unique values for each row.
Note
|
Since the concept of primary keys does not exist for views in SQLite, this requirement provides a way to produce a compliant attributes view with a discoverable key-like column[K17]. |
Column Name | Col Type | Column Description | Null | Key |
---|---|---|---|---|
|
INTEGER |
Autoincrement[K6a] primary key |
N/A[K6b] |
PK |
|
TEXT |
Text attribute of feature |
yes |
|
|
REAL |
Real attribute of feature |
yes |
|
|
BOOLEAN |
Boolean attribute of feature |
yes |
|
|
BLOB |
Photo of the area |
yes |