From c83c2d6b8bf8b5f962bfc2d4d18b6d125ad48eae Mon Sep 17 00:00:00 2001 From: Greg Buehler Date: Tue, 29 Aug 2017 14:09:23 -0400 Subject: [PATCH] moved footnotes to endnotes --- spec/1_base.adoc | 19 +++-------- spec/2a_features.adoc | 16 +++------- spec/2b_tiles.adoc | 40 +++++++----------------- spec/annexes/extension_metadata.adoc | 33 ++++++------------- spec/annexes/extension_schema.adoc | 5 +-- spec/annexes/extension_spatialindex.adoc | 4 +-- spec/annexes/tilesexample.adoc | 4 +-- spec/index.adoc | 2 ++ 8 files changed, 36 insertions(+), 87 deletions(-) diff --git a/spec/1_base.adoc b/spec/1_base.adoc index c6a8eb42..03bb8607 100644 --- a/spec/1_base.adoc +++ b/spec/1_base.adoc @@ -24,24 +24,19 @@ Using SQLite as the basis for GeoPackage simplifies production, distribution and ====== File Format -:req1_foot1: footnote:[SQLite version 4 (reference B25), which will be an alternative to version 3, not a replacement thereof, was not available when this standard was written. See Future Work clause in Annex B.] -:req1_foot2: footnote:[SQLite is in the public domain (see http://www.sqlite.org/copyright.html)] -:req2_foot1: footnote:[With SQLite versions 3.7.17 and later this value MAY be set with the "PRAGMA application_id=1196444487;" SQL statement, where 1196444487 is the 32-bit integer value of 0x47504B47. With earlier versions of SQLite the application id can be set by writing the byte sequence 0x47, 0x50, 0x4B, 0x47 at offset 68 in the SQLite database file (see http://www.sqlite.org/fileformat2.html#database_header for details).] -:req2_foot2: footnote:[Older GeoPackages use a different versioning mechanism. Instead of using the user_version, they have an application ID of "GP10" (for GeoPackage 1.0 and 1.0.1) or "GP11" (for GeoPackage 1.1).] - [[r1]] [caption=""] .Requirement 1 ==== A GeoPackage SHALL be a http://www.sqlite.org/[SQLite] <<5>> database file using http://sqlite.org/fileformat2.html[version 3 of the SQLite file format] <<6>> <<7>>. -The first 16 bytes of a GeoPackage SHALL be the null-terminated ASCII <> string "SQLite format 3" {req1_foot1}. {req1_foot2} +The first 16 bytes of a GeoPackage SHALL be the null-terminated ASCII <> string "SQLite format 3" ^<>^ ^<>^ ==== [[r2]] [caption=""] .Requirement 2 ==== -A GeoPackage SHALL contain a value of 0x47504B47 ("GPKG" in ASCII) in the "application_id" field of the SQLite database header to indicate that it is a GeoPackage. {req2_foot1} A GeoPackage SHALL contain an appropriate value in "user_version" field of the SQLite database header to indicate its version. The value SHALL be in integer with a major version, two-digit minor version, and two-digit bug-fix. For GeoPackage Version 1.2 this value is 0x000027D8 (the hexadecimal value for 10200). {req2_foot2} +A GeoPackage SHALL contain a value of 0x47504B47 ("GPKG" in ASCII) in the "application_id" field of the SQLite database header to indicate that it is a GeoPackage. ^<>^ A GeoPackage SHALL contain an appropriate value in "user_version" field of the SQLite database header to indicate its version. The value SHALL be in integer with a major version, two-digit minor version, and two-digit bug-fix. For GeoPackage Version 1.2 this value is 0x000027D8 (the hexadecimal value for 10200). ^<>^ ==== The maximum size of a GeoPackage file is about 140TB. @@ -101,13 +96,12 @@ The columns of tables in a GeoPackage SHALL only be declared using one of the da |======================================================================= ====== File Integrity -:req4_foot1: footnote:[The SQLite PRAGMA integrity_check SQL command does a full database scan that can take a long time to complete on a large GeoPackage file.] [[r6]] [caption=""] .Requirement 6 ==== -The SQLite PRAGMA integrity_check SQL command SHALL return "ok" for a GeoPackage file. {req4_foot1} +The SQLite PRAGMA integrity_check SQL command SHALL return "ok" for a GeoPackage file. ^<>^ ==== [[r7]] @@ -121,13 +115,12 @@ The SQLite PRAGMA foreign_key_check SQL with no parameter value SHALL return an [[api_sql]] ====== Structured Query Language (SQL) -:req4_foot2: footnote:[New applications should use the latest available SQLite version software <<8>>] [[r8]] [caption=""] .Requirement 8 ==== -A GeoPackage SQLite Configuration SHALL provide SQL access to GeoPackage contents via http://www.sqlite.org/download.html[SQLite version 3] <<6>> software APIs. {req4_foot2} +A GeoPackage SQLite Configuration SHALL provide SQL access to GeoPackage contents via http://www.sqlite.org/download.html[SQLite version 3] <<6>> software APIs. ^<>^ ==== ====== Every GPKG SQLite Configuration @@ -253,13 +246,11 @@ The `data_type` specifies the type of content contained in the table, for exampl The `last_change` SHOULD contain the timestamp of when the content in the referenced table was last updated, in ISO8601 format. Note that since it is not practical to ensure that this value is maintained properly in all cases, this value should be treated as informative. -:req13_foot1: footnote:[The following statement selects an ISO 8601 timestamp value using the SQLite strftime function: SELECT (strftime('%Y-%m-%dT%H:%M:%fZ','now')).] - [[r15]] [caption=""] .Requirement 15 ==== -Values of the `gpkg_contents` table `last_change` column SHALL be in http://www.iso.org/iso/catalogue_detail?csnumber=40874[ISO 8601] <<29>> format containing a complete date plus UTC hours, minutes, seconds and a decimal fraction of a second, with a 'Z' ('zulu') suffix indicating UTC. The ISO8601 format is as defined by the strftime function '%Y-%m-%dT%H:%M:%fZ' format string applied to the current time. {req13_foot1} +Values of the `gpkg_contents` table `last_change` column SHALL be in http://www.iso.org/iso/catalogue_detail?csnumber=40874[ISO 8601] <<29>> format containing a complete date plus UTC hours, minutes, seconds and a decimal fraction of a second, with a 'Z' ('zulu') suffix indicating UTC. The ISO8601 format is as defined by the strftime function '%Y-%m-%dT%H:%M:%fZ' format string applied to the current time. ^<>^ ==== The bounding box (`min_x`, `min_y`, `max_x`, `max_y`) provides an informative bounding box of the content. Applications may use this bounding box as the extents of a default view but there are no requirements that this bounding box be exact or represent the minimum bounding box of the content. The values are in the units specified by that CRS. diff --git a/spec/2a_features.adoc b/spec/2a_features.adoc index d6e7be4c..5429144c 100644 --- a/spec/2a_features.adoc +++ b/spec/2a_features.adoc @@ -34,8 +34,6 @@ For example: A stream network may be modeled as multilinestring value with the m A brief description of each geometry type is provided below. A more detailed description can be found in ISO 13249-3 <<12>>. -:core_geometry_model_foot1: footnote:[GeometryCollection is a generic term for the ST_GeomCollection type defined in [12\], which uses it for the definition of Well Known Text (WKT) and Well Known Binary (WKB) encodings. The SQL type name GEOMCOLLECTION defined in [10\] and used in Clause 1.1.2.1.1 and Annex G below refers to the SQL BLOB encoding of a GeometryCollection.] - * Geometry: the root of the geometry type hierarchy. * Point: a single location in space. @@ -52,7 +50,7 @@ A more detailed description can be found in ISO 13249-3 <<12>>. * CurvePolygon: A planar surface defined by an exterior ring and zero or more interior ring. Each ring is defined by a Curve instance. * Polygon: A restricted form of CurvePolygon where each ring is defined as a simple, closed LineString. -* GeometryCollection: A collection of zero or more Geometry instances. {core_geometry_model_foot1} +* GeometryCollection: A collection of zero or more Geometry instances. ^<>^ * MultiSurface: A restricted form of GeometryCollection where each Geometry in the collection must be of type Surface. * MultiPolygon: A restricted form of MultiSurface where each Surface in the collection must be of type Polygon. * MultiCurve: A restricted form of GeometryCollection where each Geometry in the collection must be of type Curve. @@ -87,9 +85,6 @@ The `gpkg_contents` table SHALL contain a row with a lowercase `data_type` colum A GeoPackage SHALL store feature table geometries with or without optional elevation (Z) and/or measure (M) values in SQL BLOBs using the Standard GeoPackageBinary format specified in table <> and clause <>. ==== -:geopackage_binary_foot1: footnote:[OGC WKB simple feature geometry types specified in <<9>> are a subset of the ISO WKB geometry types specified in <<12>>] -:geopackage_binary_foot2: footnote:[WKB geometry types are are restricted to 0, 1 and 2-dimensional geometric objects that exist in 2, 3 or 4-dimensional coordinate space; they are not geographic or geodesic geometry types.] -:geopackage_binary_foot3: footnote:[The axis order in WKB is always (x,y{,z}{,m}) where x is easting or longitude, y is northing or latitude, z is optional elevation and m is optional measure.] .GeoPackage SQL Geometry Binary Format [[gpb_spec]] @@ -113,7 +108,7 @@ StandardGeoPackageBinary { <3> see <> <4> see flags envelope contents indicator code below <5> The X bit in the header flags field must be set to 0. -<6> per OGC 06-103r4 <<9>> {geopackage_binary_foot1}{geopackage_binary_foot2}{geopackage_binary_foot3} +<6> per OGC 06-103r4 <<9>> ^<>^ ^<>^ ^<>^ [[flags_layout]] .bit layout of GeoPackageBinary flags byte @@ -256,12 +251,10 @@ The m value in a `gpkg_geometry_columns` table row SHALL be one of 0, 1, or 2. ====== Table Definition -:features_data_table_foot2: footnote:[A GeoPackage is not required to contain any feature data tables. Feature data tables in a GeoPackage MAY be empty.] - The third component of the SQL schema for vector features in a GeoPackage described in clause <> above are tables that contain user data representing features. Feature attributes are columns in a feature table, including geometries. Features are rows in a feature table. -{features_data_table_foot2} +^<>^ [[r29]] [caption=""] @@ -310,12 +303,11 @@ A feature geometry is stored in a geometry column specified by the `geometry_col The geometry type of a feature geometry column specified in the `gpkg_geometry_columns` table `geometry_type_name` column is a name from <>. -:geom_type_req_foot1: footnote:[GeoPackage applications MAY use SQL triggers or tests in application code to meet this requirement] [[r32]] [caption=""] .Requirement 32 ==== -Feature table geometry columns SHALL contain geometries of the type or assignable for the type specified for the column by the `gpkg_geometry_columns` table `geometry_type_name` uppercase column value {geom_type_req_foot1}. +Feature table geometry columns SHALL contain geometries of the type or assignable for the type specified for the column by the `gpkg_geometry_columns` table `geometry_type_name` uppercase column value ^<>^ ==== Geometry subtypes are assignable as defined in <> and shown in part in <>. diff --git a/spec/2b_tiles.adoc b/spec/2b_tiles.adoc index f9f88e9e..fd6c9ccb 100644 --- a/spec/2b_tiles.adoc +++ b/spec/2b_tiles.adoc @@ -3,9 +3,7 @@ ==== Tile Matrix Introduction -:tiles_intro_foot1: footnote:[Images of multiple MIME types MAY be stored in given table. For example, in a tiles table, image/png format tiles COULD be used for transparency where there is no data on the tile edges, and image/jpeg format tiles COULD be used for storage efficiency where there is image data for all pixels. Images of multiple bit depths of the same MIME type MAY also be stored in a given table, for example image/png tiles in both 8 and 24 bit depths.] - -The Tiles option specifies a mechanism for storing raster data in tile pyramids. "Tile pyramid" refers to the concept of pyramid structure of tiles of different spatial extent and resolution at different zoom levels, and the tile data itself. "Tile" refers to an individual raster image such as a PNG or JPEG that covers a specific geographic area. "Tile matrix" refers to rows and columns of tiles that all have the same spatial extent and resolution at a particular zoom level{tiles_intro_foot1}. "Tile matrix set" refers to the definition of a tile pyramid's tiling structure. This mechanism is based on the model for tile matrix sets described in Section 6 of [[[16]]]. +The Tiles option specifies a mechanism for storing raster data in tile pyramids. "Tile pyramid" refers to the concept of pyramid structure of tiles of different spatial extent and resolution at different zoom levels, and the tile data itself. "Tile" refers to an individual raster image such as a PNG or JPEG that covers a specific geographic area. "Tile matrix" refers to rows and columns of tiles that all have the same spatial extent and resolution at a particular zoom level^<>^ "Tile matrix set" refers to the definition of a tile pyramid's tiling structure. This mechanism is based on the model for tile matrix sets described in Section 6 of [[[16]]]. The GeoPackage tile store data model MAY be implemented directly as SQL tables in a SQLite database for maximum performance, or as SQL views on top of tables in an existing SQLite tile store for maximum adaptability and loose coupling to enable widespread implementation. A GeoPackage CAN store multiple raster and tile pyramid data sets in different tables or views in the same container. The tables or views that implement the GeoPackage tile store data / metadata model are described and discussed individually in the following subsections. @@ -39,12 +37,11 @@ See Web Map Tile Service (WMTS) <<16>> Annex E for additional examples of both c ====== Zoom Times Two -:zoom_times_two_foot1: footnote:[See <> for use of other zoom levels as a registered extensions.] [[r35]] [caption=""] .Requirement 35 ==== -In a GeoPackage that contains a tile pyramid user data table that contains tile data, by default {zoom_times_two_foot1}, zoom level pixel sizes for that table SHALL vary by a factor of 2 between adjacent zoom levels in the tile matrix metadata table. +In a GeoPackage that contains a tile pyramid user data table that contains tile data, by default ^<>^, zoom level pixel sizes for that table SHALL vary by a factor of 2 between adjacent zoom levels in the tile matrix metadata table. ==== [[tile_enc_png]] @@ -54,13 +51,11 @@ In a GeoPackage that contains a tile pyramid user data table that contains tile ====== MIME Type PNG -:png_req_foot1: footnote:[See <> regarding use of the WebP alternative tile MIME type as a registered extension.] - [[r36]] [caption=""] .Requirement 36 ==== -In a GeoPackage that contains a tile pyramid user data table that contains tile data that is not http://www.ietf.org/rfc/rfc2046.txt[MIME type] http://www.jpeg.org/public/jfif.pdf[image/jpeg] <<17>><<18>><<19>>, by default SHALL store that tile data in http://www.iana.org/assignments/media-types/index.html[MIME type] http://libpng.org/pub/png/[image/png] <<20>><<21>>. {png_req_foot1} +In a GeoPackage that contains a tile pyramid user data table that contains tile data that is not http://www.ietf.org/rfc/rfc2046.txt[MIME type] http://www.jpeg.org/public/jfif.pdf[image/jpeg] <<17>><<18>><<19>>, by default SHALL store that tile data in http://www.iana.org/assignments/media-types/index.html[MIME type] http://libpng.org/pub/png/[image/png] <<20>><<21>>. ^<>^ ==== [[tile_enc_jpeg]] @@ -70,12 +65,11 @@ In a GeoPackage that contains a tile pyramid user data table that contains tile ====== MIME Type JPEG -:jpg_req_foot1: footnote:[See <> regarding use of the WebP alternative tile MIME type as a registered extension.] [[r37]] [caption=""] .Requirement 37 ==== -In a GeoPackage that contains a tile pyramid user data table that contains tile data that is not http://www.iana.org/assignments/media-types/index.html[MIME type] http://libpng.org/pub/png/[image/png] <<20>><<21>>, by default SHALL store that tile data in http://www.ietf.org/rfc/rfc2046.txt[MIME type] http://www.jpeg.org/public/jfif.pdf[image/jpeg] <<17>><<18>><<19>>. {jpg_req_foot1} +In a GeoPackage that contains a tile pyramid user data table that contains tile data that is not http://www.iana.org/assignments/media-types/index.html[MIME type] http://libpng.org/pub/png/[image/png] <<20>><<21>>, by default SHALL store that tile data in http://www.ietf.org/rfc/rfc2046.txt[MIME type] http://www.jpeg.org/public/jfif.pdf[image/jpeg] <<17>><<18>><<19>>. ^<>^ ==== [NOTE] @@ -128,13 +122,11 @@ Since GeoPackages use the upper left tile origin convention defined in clause << A bounding box MAY be larger than the minimum bounding rectangle around the actual tiles in that pyramid. This allows tile matrix pyramids to be sparsely populated or even empty. -:tileref_req_foot1: footnote:[The "tiles" stipulation was removed because it prevented the use of the tile matrix mechanism by extensions for other data types.] - [[r39]] [caption=""] .Requirement 39 ==== -Values of the `gpkg_tile_matrix_set` `table_name` column SHALL reference values in the `gpkg_contents` `table_name` column [line-through]#for rows with a data type of "tiles"#{tileref_req_foot1}. +Values of the `gpkg_tile_matrix_set` `table_name` column SHALL reference values in the `gpkg_contents` `table_name` column [line-through]#for rows with a data type of "tiles"#^<>^. ==== [[r40]] @@ -194,7 +186,7 @@ See <> [caption=""] .Requirement 43 ==== -Values of the `gpkg_tile_matrix` `table_name` column SHALL reference values in the `gpkg_contents` `table_name` column [line-through]#for rows with a `data_type` of "tiles"#{tileref_req_foot1}. +Values of the `gpkg_tile_matrix` `table_name` column SHALL reference values in the `gpkg_contents` `table_name` column [line-through]#for rows with a `data_type` of "tiles"#.^<>^ ==== [[r44]] @@ -214,9 +206,7 @@ Similarly, height of a tile matrix (the difference between `min_y` and `max_y` i The `gpkg_tile_matrix` table MAY contain row records for zoom levels in a tile pyramid user data table that do not contain tiles. -:tile_matrix_meta_foot1: footnote:[GeoPackage applications MAY query the gpkg_tile_matrix table or the tile pyramid user data table to determine the minimum and maximum zoom levels for a given tile pyramid table.] - -GeoPackages follow the most frequently used conventions of a tile origin at the upper left and a zoom-out-level of 0 for the smallest map scale "whole world" zoom level view {tile_matrix_meta_foot1}, as specified by http://portal.opengeospatial.org/files/?artifact_id=35326[WMTS] <<16>>. +GeoPackages follow the most frequently used conventions of a tile origin at the upper left and a zoom-out-level of 0 for the smallest map scale "whole world" zoom level view ^<>^, as specified by http://portal.opengeospatial.org/files/?artifact_id=35326[WMTS] <<16>>. The tile coordinate (0,0) always refers to the tile in the upper left corner of the tile matrix at any zoom level, regardless of the actual availability of that tile. [[r46]] @@ -275,13 +265,9 @@ The `pixel_y_size` column value in a `gpkg_tile_matrix` table row SHALL be great When `zoom_level` column values in the `gpkg_tile_matrix` table are sorted in ascending order, the `pixel_x_size` and `pixel_y_size` column values in the `gpkg_tile_matrix` table SHALL appear sorted in descending order. ==== -:sparse_tiles_foot1: footnote:[GeoPackage applications MAY query a tile pyramid user data table to determine which tiles are available at each zoom level.] -:sparse_tiles_foot2: footnote:[GeoPackage applications that insert, update, or delete tile pyramid user data table tiles row records are responsible for maintaining the corresponding descriptive contents of the gpkg_tile_matrix_metadata table.] -:sparse_tiles_foot3: footnote:[The `gpkg_tile_matrix_set` table contains coordinates that define a bounding box as the exact stated spatial extent for all tiles in a tile (matrix set) table. If the geographic extent of the image data contained in tiles at a particular zoom level is within but not equal to this bounding box, then the non-image area of matrix edge tiles must be padded with no-data values, preferably transparent ones.] - -Tiles MAY or MAY NOT be provided for level 0 or any other particular zoom level. {sparse_tiles_foot1} +Tiles MAY or MAY NOT be provided for level 0 or any other particular zoom level. ^<>^ This means that a tile matrix set can be sparse, i.e. not contain a tile for any particular position at a certain tile zoom level. -{sparse_tiles_foot2} This does not affect the informative spatial extent stated by the min/max x/y columns values in the `gpkg_contents` record for the same `table_name`, the exact spatial extent stated by the min/max x/y columns values in the `gpkg_tile_matrix_set` record for the same table name, or the tile matrix width and height at that level. {sparse_tiles_foot3} +^<>^ This does not affect the informative spatial extent stated by the min/max x/y columns values in the `gpkg_contents` record for the same `table_name`, the exact spatial extent stated by the min/max x/y columns values in the `gpkg_tile_matrix_set` record for the same table name, or the tile matrix width and height at that level. ^<>^ [[tiles_user_tables]] ==== Tile Pyramid User Data Tables @@ -314,11 +300,7 @@ See <>. ====== Table Data Values -:tile_data_foot1: footnote:[A GeoPackage is not required to contain any tile pyramid user data tables. Tile pyramid user data tables in a GeoPackage MAY be empty.] - -:tile_data_foot1_ref: footnote:[The zoom_level / tile_column / tile_row unique key is automatically indexed, and allows tiles to be selected and accessed by "z, x, y", a common convention used by some implementations. This table / view definition MAY also allow tiles to be selected based on a spatially indexed bounding box in a separate metadata table.] - -Each tile pyramid user data table or view {tile_data_foot1} MAY contain tile matrices at zero or more zoom levels of different spatial resolution (map scale). +Each tile pyramid user data table or view ^<>^ MAY contain tile matrices at zero or more zoom levels of different spatial resolution (map scale). [[r55]] [caption=""] @@ -341,4 +323,4 @@ For each distinct `table_name` from the `gpkg_tile_matrix` (tm) table, the tile For each distinct `table_name` from the `gpkg_tile_matrix` (tm) table, the tile pyramid (tp) user data table `tile_row` column value in a GeoPackage SHALL be in the range 0 \<= tp.tile_row \<= tm.matrix_height – 1 where the tm and tp `zoom_level` column values are equal. ==== -All tiles at a particular zoom level have the same `pixel_x_size` and `pixel_y_size` values specified in the `gpkg_tile_matrix` row record for that tiles table and zoom level. {tile_data_foot1_ref} +All tiles at a particular zoom level have the same `pixel_x_size` and `pixel_y_size` values specified in the `gpkg_tile_matrix` row record for that tiles table and zoom level. ^<>^ diff --git a/spec/annexes/extension_metadata.adoc b/spec/annexes/extension_metadata.adoc index cdb9212d..7f8c8bba 100644 --- a/spec/annexes/extension_metadata.adoc +++ b/spec/annexes/extension_metadata.adoc @@ -8,7 +8,7 @@ Two tables in a GeoPackage provide a means of storing metadata in MIME <<21>> en These tables are intended to provide the support necessary to implement the hierarchical metadata models as defined in ISO 19115 <<28>> and illustrated in <> and <>. As GeoPackage data is captured and updated, the most local and specific detailed metadata changes associated with the new or modified data MAY be captured separately, and referenced to existing global and general metadata. The `gpkg_metadata` table that contains metadata is described in clause <<_metadata_table>>, and the `gpkg_metadata_reference` table that relates `gpkg_metadata` to GeoPackage data is described in clause <<_metadata_reference_table>>. -There is no GeoPackage requirement that such metadata be provided or that defined metadata be structured in a hierarchical fashion footnote:[Informative examples of hierarchical metadata are provided in <>]. This extension simply provides a mechanism for storing this information. If this extension is used, uch metadata footnote:[An informative example of raster image metadata is provided in <>] and data that relates it to GeoPackage contents should not be stored in other tables. +There is no GeoPackage requirement that such metadata be provided or that defined metadata be structured in a hierarchical fashion ^<>^. This extension simply provides a mechanism for storing this information. If this extension is used, such metadata ^<>^ and data that relates it to GeoPackage contents should not be stored in other tables. [float] ==== Extension Author @@ -55,8 +55,6 @@ A GeoPackage A GeoPackage MAY contain a table named gpkg_metadata. If present it The first component of GeoPackage metadata is the `gpkg_metadata` table that MAY contain metadata in MIME <<21>> encodings structured in accordance with any authoritative metadata specification, such as ISO 19115 <<28>>, ISO 19115-2 <>, ISO 19139 <>, Dublin Core <>, CSDGM <>, DDMS <>, NMF/NMIS <>, etc. The GeoPackage interpretation of what constitutes "metadata" is a broad one that includes UML models <> encoded in XMI <>, GML Application Schemas <<30>>, ISO 19110 feature catalogues <>, OWL <> and SKOS <> taxonomies, etc. -:metadata_table_definition_foot1: footnote:[For example, for ISO 19139 metadata the URI value should be the metadata schema namespace http://www.isotc211.org/2005/gmd] - [[gpkg_metadata_cols]] .Metadata Table Definition [cols=",,,,,",options="header",] @@ -64,7 +62,7 @@ The GeoPackage interpretation of what constitutes "metadata" is a broad one that |Column Name |Column Type |Column Description |Null |Default |Key |`id` |INTEGER |Metadata primary key |no | |PK |`md_scope` |TEXT |Case sensitive name of the data scope to which this metadata applies; see <> below |no |'dataset' | -|`md_standard_uri` |TEXT |URI <<23>> reference to the metadata structure definition authority {metadata_table_definition_foot1} |no | any | +|`md_standard_uri` |TEXT |URI <<23>> reference to the metadata structure definition authority ^<>^ |no | any | |`mime_type` |TEXT |MIME <<21>> encoding of metadata |no |'text/xml' <<24>> | |`metadata` |TEXT |metadata |no |''| |======================================================================= @@ -88,8 +86,6 @@ A GeoPackage that contains a `gpkg_metadata` table SHALL contain a `gpkg_metadat The second component of GeoPackage metadata is the `gpkg_metadata_reference` table that links metadata in the `gpkg_metadata` table to data in the feature, and tiles tables defined in clauses 2.1.6 and 2.2.7. The `gpkg_metadata_reference` table is not required to contain any rows. -:gpkg_metadata_reference_cols_foot1: footnote:[In SQLite, the rowid value is always equal to the value of a single-column primary key on an integer column [B30\] and is not changed by a database reorganization performed by the VACUUM SQL command.] - [[gpkg_metadata_reference_cols]] .Metadata Reference Table Definition (Table Name: gpkg_metadata_reference) [cols=",,,,,",options="header",] @@ -98,15 +94,13 @@ The `gpkg_metadata_reference` table is not required to contain any rows. |`reference_scope` |TEXT |Lowercase metadata reference scope; one of 'geopackage', 'table','column', 'row', 'row/col' |no | | |`table_name` |TEXT |Name of the table to which this metadata reference applies, or NULL for reference_scope of 'geopackage'. |yes | | |`column_name` |TEXT |Name of the column to which this metadata reference applies; NULL for `reference_scope` of 'geopackage','table' or 'row', or the name of a column in the `table_name` table for `reference_scope` of 'column' or 'row/col' |yes | | -|`row_id_value` {gpkg_metadata_reference_cols_foot1} |INTEGER |NULL for `reference_scope` of 'geopackage', 'table' or 'column', or the rowed of a row record in the `table_name` table for `reference_scope` of 'row' or 'row/col' |yes | | +|`row_id_value` ^<>^ |INTEGER |NULL for `reference_scope` of 'geopackage', 'table' or 'column', or the rowed of a row record in the `table_name` table for `reference_scope` of 'row' or 'row/col' |yes | | |`timestamp` |DATETIME |timestamp value in ISO 8601 format as defined by the strftime function \'%Y-%m-%dT%H:%M:%fZ' format string applied to the current time |no |strftime(\'%Y-%m-%dT%H:%M:%fZ', \'now') | |`md_file_id` |INTEGER |`gpkg_metadata` table id column value for the metadata to which this `gpkg_metadata_reference` applies |no | |FK |`md_parent_id` |INTEGER |`gpkg_metadata` table id column value for the hierarchical parent `gpkg_metadata` for the `gpkg_metadata` to which this `gpkg_metadata_reference` applies, or NULL if `md_file_id` forms the root of a metadata hierarchy |yes | |FK |======================================================================= -:gpkg_metadata_reference_null_foot1: footnote:[Such a metadata hierarchy MAY have only one level of defined metadata] - -Every row in `gpkg_metadata_reference` that has null value as `md_parent_id` forms the root of a metadata hierarchy.{gpkg_metadata_reference_null_foot1} +Every row in `gpkg_metadata_reference` that has null value as `md_parent_id` forms the root of a metadata hierarchy.^<>^ See <> clause <>. @@ -126,13 +120,7 @@ GeoPackages with a row in the `gpkg_extensions` table with an `extension_name` o ====== gpkg_metadata The `md_scope` column in the `gpkg_metadata` table is the name of the applicable scope for the contents of the metadata column for a given row. The list of valid scope names and their definitions is provided in <> below. -The initial contents of this table were obtained from the ISO 19115 <<28>>, Annex B B.5.25 MD_ScopeCode code list, which was extended footnote:[The scope codes in <> include a very wide set of descriptive information types as "metadata" to describe data.] for use in the GeoPackage specification by addition of entries with "NA" as the scope code column in <>. - - -:table_metadata_scopes_foot1: footnote:[ISO 19139 format metadata (B32) is recommended for general-purpose description of geospatial data at the series and dataset metadata scopes.] -:table_metadata_scopes_foot2: footnote:[The "catalog" md_scope MAY be used for Feature Catalog (B40) information stored as XML metadata that is linked to features stored in a GeoPackage.] -:table_metadata_scopes_foot3: footnote:[The "schema" md_scope MAY be used for Application Schema (B37)(B38)(B39)(B44) information stored as XML metadata that is linked to features stored in a GeoPackage.] -:table_metadata_scopes_foot4: footnote:[The "taxonomy" md_scope MAY be used for taxonomy or knowledge system (B41)(B42) "linked data" information stored as XML metadata that is linked to features stored in a GeoPackage.] +The initial contents of this table were obtained from the ISO 19115 <<28>>, Annex B B.5.25 MD_ScopeCode code list, which was extended ^<>^ for use in the GeoPackage specification by addition of entries with "NA" as the scope code column in <>. [[metadata_scopes]] .Metadata Scopes @@ -142,7 +130,7 @@ The initial contents of this table were obtained from the ISO 19115 <<28>>, Anne |undefined |NA |Metadata information scope is undefined |fieldSession |012 |Information applies to the field session |collectionSession |004 |Information applies to the collection session -|series |006 |Information applies to the (dataset) series {table_metadata_scopes_foot1} +|series |006 |Information applies to the (dataset) series ^<>^ |dataset |005 |Information applies to the (geographic feature) dataset |featureType |010 |Information applies to a feature type (class) |feature |009 |Information applies to a feature (instance) @@ -150,9 +138,9 @@ The initial contents of this table were obtained from the ISO 19115 <<28>>, Anne |attribute |001 |Information applies to the characteristic of a feature (instance) |tile |016 |Information applies to a tile, a spatial subset of geographic data |model |015 |Information applies to a copy or imitation of an existing or hypothetical object -|catalog |NA |Metadata applies to a feature catalog {table_metadata_scopes_foot2} -|schema |NA |Metadata applies to an application schema {table_metadata_scopes_foot3} -|taxonomy |NA |Metadata applies to a taxonomy or knowledge system {table_metadata_scopes_foot4} +|catalog |NA |Metadata applies to a feature catalog ^<>^ +|schema |NA |Metadata applies to an application schema ^<>^ +|taxonomy |NA |Metadata applies to a taxonomy or knowledge system ^<>^ |software |013 |Information applies to a computer program or routine |service |014 |Information applies to a capability which a service provider entity makes available to a service user entity through a set of interfaces that define a behavior, such as a use case |collectionHardware |003 |Information applies to the collection hardware class @@ -201,12 +189,11 @@ Every `gpkg_metadata_reference` table row with a `reference_scope` column value Every other `gpkg_metadata_reference` table row SHALL have a `row_id_value` column value that contains the ROWID of a row in the SQLite table or view identified by the `table_name` column value. ==== -:req_75_foot1: footnote:[The following statement selects an ISO 8601timestamp value using the SQLite strftime function: SELECT (strftime('%Y-%m-%dT%H:%M:%fZ','now')).] [[r100]] [caption=""] .Requirement 100 ==== -Every `gpkg_metadata_reference` table row timestamp column value SHALL be in ISO 8601 <<29>> format containing a complete date plus UTC hours, minutes, seconds and a decimal fraction of a second, with a 'Z' ('zulu') suffix indicating UTC.{req_75_foot1} +Every `gpkg_metadata_reference` table row timestamp column value SHALL be in ISO 8601 <<29>> format containing a complete date plus UTC hours, minutes, seconds and a decimal fraction of a second, with a 'Z' ('zulu') suffix indicating UTC.^<>^ ==== [[r101]] diff --git a/spec/annexes/extension_schema.adoc b/spec/annexes/extension_schema.adoc index 6695bacb..d9656f94 100644 --- a/spec/annexes/extension_schema.adoc +++ b/spec/annexes/extension_schema.adoc @@ -64,10 +64,7 @@ If present it SHALL be defined per <> and <> type {data_cols_foot2} information about columns in user vector feature and tile matrix data tables that supplements the data available from the SQLite `sqlite_master` table and pragma `table_info(table_name)` SQL function. +GeoPackage applications MAY ^<>^ use the `gpkg_data_columns` table to store minimal application schema identifying, descriptive and http://www.iana.org/assignments/media-types/index.html[MIME] <<21>> type ^<>^ information about columns in user vector feature and tile matrix data tables that supplements the data available from the SQLite `sqlite_master` table and pragma `table_info(table_name)` SQL function. The `gpkg_data_columns` data CAN be used to provide more specific column data types and value ranges and application specific structural and semantic information to enable more informative user menu displays and more effective user decisions on the suitability of GeoPackage contents for specific purposes. See <>. diff --git a/spec/annexes/extension_spatialindex.adoc b/spec/annexes/extension_spatialindex.adoc index 20cfe256..253d118a 100644 --- a/spec/annexes/extension_spatialindex.adoc +++ b/spec/annexes/extension_spatialindex.adoc @@ -8,9 +8,7 @@ This extension adds a new capability for spatially indexing columns with geometr The RTree index extension provides a means to encode an RTree index for geometry values in a GeoPackage. An RTree index provides a significant performance advantage for searches with basic envelope spatial criteria that return subsets of the rows in a feature table with a non-trivial number (thousands or more) of rows. -:spatial_indexes_impl_foot1: footnote:[If an application process will make many updates, it is often faster to drop the indexes, do the updates, and then recreate the indexes.] - -Spatial indexes provide a significant performance advantage for searches with basic envelope spatial criteria that return subsets of the rows in a feature table with a non-trivial number (thousands or more) of rows.{spatial_indexes_impl_foot1} +Spatial indexes provide a significant performance advantage for searches with basic envelope spatial criteria that return subsets of the rows in a feature table with a non-trivial number (thousands or more) of rows.^<>^ [float] ==== Extension Author diff --git a/spec/annexes/tilesexample.adoc b/spec/annexes/tilesexample.adoc index c49f8bf9..9aa7d1a8 100644 --- a/spec/annexes/tilesexample.adoc +++ b/spec/annexes/tilesexample.adoc @@ -1,4 +1,4 @@ -[[tiles_factor2_example_appendix]] +[[tiles_example_appendix]] [appendix] == Tiles Zoom Times Two Example (Informative) @@ -15,4 +15,4 @@ |MyTiles |6 |512 |512 |512 |512 |1081.83 |1068.93 |MyTiles |7 |1024 |1024 |512 |512 |540.915 |543.469 |MyTiles |8 |2048 |2048 |512 |512 |270.457 |267.234 -|======================================================================= \ No newline at end of file +|======================================================================= diff --git a/spec/index.adoc b/spec/index.adoc index f25a9f39..f9240524 100644 --- a/spec/index.adoc +++ b/spec/index.adoc @@ -115,3 +115,5 @@ include::annexes/tilesexample.adoc[] include::annexes/normref.adoc[] include::annexes/biblio.adoc[] + +include::annexes/endnotes.adoc[]