From f2ed34e18ee6b511059958b6ce99027ebc0c7b89 Mon Sep 17 00:00:00 2001 From: Jeff Yutzler Date: Thu, 19 Nov 2015 08:41:40 -0500 Subject: [PATCH 1/5] removing Inc. (1) --- LICENSE.md | 2 +- spec/annexes/background.adoc | 2 +- spec/index.adoc | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/LICENSE.md b/LICENSE.md index 26ba6325..8e1ff67f 100644 --- a/LICENSE.md +++ b/LICENSE.md @@ -12,7 +12,7 @@ Copyright © 2012 U.S. Army Geospatial Center. Copyright © 2012 U.S. National Geospatial Intelligence Agency. -The companies listed above have granted the Open Geospatial Consortium, Inc. (OGC) a nonexclusive, +The companies listed above have granted the Open Geospatial Consortium (OGC) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version. To obtain additional rights of use, visit http://www.opengeospatial.org/legal/. diff --git a/spec/annexes/background.adoc b/spec/annexes/background.adoc index 0ade78ce..ecca74d0 100644 --- a/spec/annexes/background.adoc +++ b/spec/annexes/background.adoc @@ -116,7 +116,7 @@ XML:: === Submitting Organizations (Informative) -The following organizations submitted this Encoding Standard to the Open Geospatial Consortium Inc. as a +The following organizations submitted this Encoding Standard to the Open Geospatial Consortium as a Request For Comment (RFC). * Envitia diff --git a/spec/index.adoc b/spec/index.adoc index c78dd4cf..90e227e3 100644 --- a/spec/index.adoc +++ b/spec/index.adoc @@ -63,7 +63,7 @@ This Agreement is governed by the laws of the Commonwealth of Massachusetts. The == Patent Call == -_Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium Inc. shall not be held responsible for identifying any or all such patent rights._ +_Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights._ _Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation._ From 60ebe2bf2c77402e2491b5fe5d8844a7410382fe Mon Sep 17 00:00:00 2001 From: Jeff Yutzler Date: Thu, 19 Nov 2015 08:56:27 -0500 Subject: [PATCH 2/5] specification -> standard (4) --- README.md | 22 +++++++++--------- process.md | 14 ++++++------ spec/0_introduction.adoc | 4 ++-- spec/1_base.adoc | 6 ++--- spec/2e_extensions-mechanism.adoc | 4 ++-- spec/4_security.adoc | 2 +- spec/annexes/background.adoc | 37 +++++++++++++++++-------------- 7 files changed, 47 insertions(+), 42 deletions(-) diff --git a/README.md b/README.md index bc324b6e..7687402d 100644 --- a/README.md +++ b/README.md @@ -1,10 +1,10 @@ ![OGC Logo](http://portal.opengeospatial.org/files/?artifact_id=11976&format=gif "OGC Logo") -GeoPackage Specification +GeoPackage Standard ========== GeoPackage is an open, standards-based, platform-independent, portable, self-describing, -compact format for transferring geospatial information. The GeoPackage specification +compact format for transferring geospatial information. The GeoPackage standard describes a set of conventions for storing the following within an SQLite database: * [vector features](spec/2_features.md) * [tile matrix sets of imagery and raster maps at various scales](spec/3_tiles.md) @@ -18,12 +18,12 @@ described to provide implementors a way to include additional functionality in t This OGC® Encoding Standard defines the schema for a GeoPackage, including table definitions, integrity assertions, format limitations, and content constraints. -The allowable content of a GeoPackage is entirely defined in this specification. +The allowable content of a GeoPackage is entirely defined in this standard. For more information about GeoPackage, including implementations and sample data, go to the public page at http://www.geopackage.org. -An HTML version of the specification is available at http://www.geopackage.org/spec/. -The asciidoc source for the specification is in the [spec/](spec/) folder. +An HTML version of the standard is available at http://www.geopackage.org/spec/. +The asciidoc source for the standard is in the [spec/](spec/) folder. About ----- @@ -34,12 +34,14 @@ released for [public comment](http://www.opengeospatial.org/standards/requests/1 With this repository the OGC invites collaboration and comments directed at the development and enhancement of this candidate standard. -The repo tracks the latest version of the specification as it evolves. Pull requests for fixes are +The repo tracks the latest version of the standard as it evolves. Pull requests for fixes are appreciated, and new functionality will still be considered even though version 1.0 has been adopted. The spec is done in [asciidoc](http://www.methods.co.nz/asciidoc/) a format supported by GitHub, similar to markdown but with some features that make it better for specifications, like automatic section numbering. -**Editor: Paul Daisey** +**Editor: Jeff Yutzler** + +**Editor Emeritus: Paul Daisey** Contributing ------------ @@ -48,7 +50,7 @@ be incorporated into the formal OGC GeoPackage standards document and that all c intellectual property shall be vested to the OGC. The GeoPackage Standards Working Group (SWG) is the group at OGC responsible for the stewardship -of the specification, but is working to do as much GeoPackage work in public as possible. +of the standard, but is working to do as much GeoPackage work in public as possible. The Geopackage SWG currently has the following email lists: - geopackage@lists.opengeospatial.org -- [sign up here](https://lists.opengeospatial.org/mailman/listinfo/geopackage) @@ -67,9 +69,9 @@ The Geopackage SWG currently has the following email lists: Editing and commenting ---------------------- -The GeoPackage SWG is accepting public comments and suggested revisions to the specification +The GeoPackage SWG is accepting public comments and suggested revisions to the standard via GitHub. This is the first time OGC has supported this mechanism for public comment and review. -To suggest changes to the specification please fork the repository and submit a pull request with +To suggest changes to the standard please fork the repository and submit a pull request with the desired changes. Please make one pull request per logical requested change and be sure to include a comment in the PR with any justification or reasoning on why the change is needed. diff --git a/process.md b/process.md index d0b03f20..a7aee3a9 100644 --- a/process.md +++ b/process.md @@ -2,14 +2,14 @@ ## Overview The GeoPackage Standards Working Group (SWG) intends to experiment with the use of GitHub as a collaboration platform, -and the document formats suppored by GitHub as a way to evolve the specification +and the document formats suppored by GitHub as a way to evolve the standard editing and public comment process. The versions of draft specifications in GitHub, in whole or in part, should not be considered official positions of the OGC as an organization. In this experimental stage, they are informal, non-normative, communications of the GeoPackage SWG. ## Comments -Comments on the specification can be made in one of two ways: +Comments on the standard can be made in one of two ways: 1. Pull Requests (PRs) that contain the proposed changes to the document, with a comment from the author. These should have a label for the priority. (preferred) * Pull Requests be made for each logical set of changes to the spec, against a user's branch, not their master. Pull Requests that do too many things at once will be rejected and the submitter will be asked to break it up in to multiple pull requests. @@ -32,9 +32,9 @@ For those who are new to GitHub the following information may help get you up to Most everything needed to edit the GeoPackage repository can be done completely through the web with GitHub, no need to learn git. -You can just hit 'edit' on any of the specification pages. This will automatically +You can just hit 'edit' on any of the repository pages. This will automatically 'fork' the repository in to your own copy. You can also create a fork before editing by hitting the 'Fork' button -at the top right of this page. This creates a personal copy of the geopackage specification repository (a fork). +at the top right of this page. This creates a personal copy of the geopackage standard repository (a fork). You can find more detailed instructions on forking a repo on the [Fork A Repo](https://help.github.com/articles/fork-a-repo) page. @@ -69,8 +69,8 @@ your github username. Cloning the repository can be done using the git command-l (git clone https://github.com/username/geopackage.git) or using a git GUI like the GitHub [Windows](http://windows.github.com/) or [Mac](http://mac.github.com/) or [SourceTree](http://sourcetreeapp.com/). -Once the repository has been cloned to your computer you can make the changes to the specification that -you would like to suggest. Many text editors have plugins for formatting and previewing Markdown. +Once the repository has been cloned to your computer you can make the changes that +you would like to suggest. Many text editors have plugins for formatting and previewing Markdown and Asciidoc. Once you're done making your changes, commit them and push them to the github servers. The free [Pro Git](http://git-scm.com/book) book provides detailed instructions on [committing @@ -78,7 +78,7 @@ changes](http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Reposito [pushing changes to a server](http://git-scm.com/book/en/Git-Basics-Working-with-Remotes#Pushing-to-Your-Remotes). Now that your change has been pushed to github you should initiate a pull request to request that your -change be integrated in the master copy of the specification. The GitHub [pull request help page](https://help.github.com/articles/using-pull-requests) +change be integrated in the master copy of the repository. The GitHub [pull request help page](https://help.github.com/articles/using-pull-requests) provides detailed instructions on how to do this. diff --git a/spec/0_introduction.adoc b/spec/0_introduction.adoc index dc40ed18..ca5934a9 100644 --- a/spec/0_introduction.adoc +++ b/spec/0_introduction.adoc @@ -13,7 +13,7 @@ This OGC® Encoding Standard defines GeoPackages for exchange and GeoPackage SQL Direct use means the ability to access and update data in a “native” format without intermediate format translations in an environment (e.g. through an API) that guarantees data model and data set integrity and identical access and update results in response to identical requests from different client applications. A *GeoPackage* is a platform-independent SQLite <<5>> database file that contains GeoPackage data and metadata tables shown in <> below, with specified definitions, integrity assertions, format limitations and content constraints. -The allowable content of a GeoPackage is entirely defined in this specification. +The allowable content of a GeoPackage is entirely defined in this standard. An *Extended GeoPackage* is a *GeoPackage* that contains any additional data elements (tables or columns) or SQL constructs (data types, functions, indexes, constraints or triggers) that are not specified in this encoding standard. @@ -23,7 +23,7 @@ A GeoPackage MAY contain spatial indexes on feature geometries and SQL triggers A *GeoPackage SQLite Configuration* consists of the SQLite 3 software library and a set of compile- and runtime configurations options. -A *GeoPackage SQLite Extension* is a SQLite loadable extension that MAY provide SQL functions <<12>> to support spatial indexes and SQL triggers linked to a SQLite library with specified configuration requirements to provide SQL API <<1>> <<2>> <<3>> <<4>> access to a GeoPackage file. This standard does not address the issues listed in the <<_potential_future_work>> clause in <>, which MAY be addressed in a subsequent version of this specification or by other specifications. +A *GeoPackage SQLite Extension* is a SQLite loadable extension that MAY provide SQL functions <<12>> to support spatial indexes and SQL triggers linked to a SQLite library with specified configuration requirements to provide SQL API <<1>> <<2>> <<3>> <<4>> access to a GeoPackage file. This standard does not address the issues listed in the <<_potential_future_work>> clause in <>, which MAY be addressed in a subsequent version of this standard or by other specifications. [[geopackage_tables_figure]] .GeoPackage Tables Overview diff --git a/spec/1_base.adoc b/spec/1_base.adoc index 8aef1124..eb73d367 100644 --- a/spec/1_base.adoc +++ b/spec/1_base.adoc @@ -11,7 +11,7 @@ The mandatory core capabilities defined in sub clauses and requirement statement ==== SQLite Container The SQLite software library provides a self-contained, single-file, cross-platform, serverless, transactional, open source RDBMS container. -The GeoPackage specification defines a SQL database schema designed for use with the SQLite software library. +The GeoPackage standard defines a SQL database schema designed for use with the SQLite software library. Using SQLite as the basis for GeoPackage simplifies production, distribution and use of GeoPackages and assists in guaranteeing the integrity of the data they contain. “Self-contained” means that container software requires very minimal support from external libraries or from the operating system. @@ -24,7 +24,7 @@ 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 specification was written. See Future Work clause in Annex B.] +: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=1196437808;" SQL statement, where 1196437808 is the 32-bit integer value of 0x47503130. With earlier versions of SQLite the application id can be set by writing the byte sequence 0x47, 0x50, 0x31, 0x30 at offset 68 in the SQLite database file (see http://www.sqlite.org/fileformat2.html#database_header for details).] @@ -52,7 +52,7 @@ It is RECOMMENDED that Extended GeoPackages use the file extension “.gpkx”, A GeoPackage SHALL only contain data elements, SQL constructs and GeoPackage extensions with the “gpkg” author name specified in this encoding standard. In order to guarantee maximum interoperability between applications, GeoPackages SHALL NOT contain data elements (tables or columns), SQL constructs (data types, indexes, constraints or triggers) or extensions that are not specified in this encoding standard. -SQLite databases that use constructs from the GeoPackage specification but extend that to contain any of these elements are referred to as Extended GeoPackages throughout this specification. +SQLite databases that use constructs from the GeoPackage standard but extend that to contain any of these elements are referred to as Extended GeoPackages throughout this standard. [requirement] The columns of tables in a GeoPackage SHALL only be declared using one of the data types specified in table <>. diff --git a/spec/2e_extensions-mechanism.adoc b/spec/2e_extensions-mechanism.adoc index b7718bcd..5820f753 100644 --- a/spec/2e_extensions-mechanism.adoc +++ b/spec/2e_extensions-mechanism.adoc @@ -4,10 +4,10 @@ :extension_mechanism_foot1: footnote:[See Requirement 82.] -A GeoPackage extension is a set of one or more requirements clauses that are documented by filling out the GeoPackage Extension Template in <>. A GeoPackage Extension either profiles / extends existing requirements clauses in the geopackage specification or adds new requirements clauses. Existing requirement clause extension examples include additional geometry types, additional SQL geometry functions, and additional tile image formats. New requirement clause extension examples include spatial indexes, triggers, additional tables, other BLOB column encodings, and other SQL functions. +A GeoPackage extension is a set of one or more requirements clauses that are documented by filling out the GeoPackage Extension Template in <>. A GeoPackage Extension either profiles / extends existing requirements clauses in the GeoPackage standard or adds new requirements clauses. Existing requirement clause extension examples include additional geometry types, additional SQL geometry functions, and additional tile image formats. New requirement clause extension examples include spatial indexes, triggers, additional tables, other BLOB column encodings, and other SQL functions. GeoPackage extensions are identified by a name of the form _ where indicates the person or organization that developed and maintains the extension. -The author value “gpkg” is reserved for GeoPackage extensions that are developed and maintained by OGC and used in Geopackages. +The author value “gpkg” is reserved for GeoPackage extensions that are developed and maintained by OGC and used in GeoPackages. Implementers use their own author names to register other extensions{extension_mechanism_foot1} used in Extended GeoPackages. diff --git a/spec/4_security.adoc b/spec/4_security.adoc index 1443ea7d..418e6061 100644 --- a/spec/4_security.adoc +++ b/spec/4_security.adoc @@ -1,4 +1,4 @@ == Security Considerations Security considerations for implementations utilizing GeoPackages are in the domain of the implementing application, deployment platform, operating system and networking environment. -The GeoPackage specification does not place any constraints on application, platform, operating system level or network security. \ No newline at end of file +The GeoPackage standard does not place any constraints on application, platform, operating system level or network security. \ No newline at end of file diff --git a/spec/annexes/background.adoc b/spec/annexes/background.adoc index ecca74d0..4d9f67e9 100644 --- a/spec/annexes/background.adoc +++ b/spec/annexes/background.adoc @@ -10,13 +10,13 @@ This OGC® GeoPackage Encoding Standard defines a GeoPackage as a self-contained cross-platform, serverless, transactional, open source SQLite data container with table definitions, relational integrity constraints, an SQL API exposed via a "C" CLI and JDBC, and manifest tables that together act as an exchange and direct-use format for multiple types of geospatial data including vector features, features with raster attributes and tile matrix pyramids, especially on mobile / hand held devices in disconnected or limited network connectivity environments. -Table formats, definitions of geometry types and metadata tables, relational integrity constraints, and SQL API are interdependent specification facets of the SF-SQL <<9>><<10>><<11>> and SQL-MM (Spatial) <<12>> standards that serve as normative references for the vector feature portion of this specification. +Table formats, definitions of geometry types and metadata tables, relational integrity constraints, and SQL API are interdependent specification facets of the SF-SQL <<9>><<10>><<11>> and SQL-MM (Spatial) <<12>> standards that serve as normative references for the vector feature portion of this standard. -This specification attempts to support and use relevant raster types, storage table definitions, and metadata from widely adopted implementations and existing standards such as WMTS <<16>> and ISO metadata <<28>>, to integrate use of rasters as attributes of geospatial features, and to define relational integrity constraints and an SQL API thereon to provide a raster analogy to the SF-SQL and SF-MM data access and data quality assurance capabilities. +This standard attempts to support and use relevant raster types, storage table definitions, and metadata from widely adopted implementations and existing standards such as WMTS <<16>> and ISO metadata <<28>>, to integrate use of rasters as attributes of geospatial features, and to define relational integrity constraints and an SQL API thereon to provide a raster analogy to the SF-SQL and SF-MM data access and data quality assurance capabilities. -Conformance classes for this specification are classified as core (mandatory) and extension (optional). The simple core of an Empty GeoPackage contains two SQL tables. +Conformance classes for this standard are classified as core (mandatory) and extension (optional). The simple core of an Empty GeoPackage contains two SQL tables. -Future versions of this specification willmay include requirements for elevation data and routes. Future enhancements to this specification, a future GeoPackage Web Service specification, and modifications to existing OGC Web Service (OWS) specifications to use GeoPackages as exchange formats willmay allow OWS to support provisioning of GeoPackages throughout an enterprise or information community. +Future versions of this standard may include requirements for elevation data and routes. Future enhancements to this standard, a future GeoPackage Web Service specification, and modifications to existing OGC Web Service (OWS) specifications to use GeoPackages as exchange formats may allow OWS to support provisioning of GeoPackages throughout an enterprise or information community. === Document terms and definitions @@ -228,19 +228,22 @@ None at present. === Potential Future Work (Informative) -* MAY investigate GeoPackage implementation on SQLite version 4 <>. -* Future versions of this specification MAY include requirements for elevation data and routes. -* Future enhancements to this specification, a future GeoPackage Web Service specification and modifications to existing OGC Web Service (OWS) specifications to use GeoPackages as exchange formats MAY allow OWS to support provisioning of GeoPackages throughout an enterprise. -* Future versions of this specification MAY include additional raster / image formats, including fewer restrictions on the image/tiff format. -* Future versions of this specification MAY include additional SQL API routines for interrogation and conversion of raster / image BLOBs. -* Future versions of this specification and/or one for a GeoPackage Web Service MAY address utilities for importing and exporting vector, raster and tile data in various formats. -* Future versions of this specification and/or one for a GeoPackage Web Service MAY address encryption of GeoPackages and/or individual tables or column values. -* Future versions of this specification MAY add infrastructure to the metadata tables such as a `temporal_columns` table that refers to the time properties of data records. -* MAY specify a streaming synchronization protocol for GeoPackage as part of a future GeoPackage Web Service specification, and/or a future version of the GeoPackage and/or Web Synchronization Service specification(s). -* Future versions of this specification MAY address symbology and styling information. -* Future version of this specification MAY include geographic / geodesic geometry types. -* MAY create a GeoPackage Abstract Object Model to support data encodings other than SQL in a future version of this specification. -* MAY add https://github.com/mapbox/utfgrid-spec[UTFGrid] support in a future version of this specification +Future versions of this standard MAY do the following: +* investigate GeoPackage implementation on SQLite version 4 <>. +* include requirements for elevation data and routes. +* Future enhancements to this standard, a future GeoPackage Web Service specification and modifications to existing OGC Web Service (OWS) specifications to use GeoPackages as exchange formats MAY allow OWS to support provisioning of GeoPackages throughout an enterprise. +* include additional raster / image formats, including fewer restrictions on the image/tiff format. +* include additional SQL API routines for interrogation and conversion of raster / image BLOBs. +* add infrastructure to the metadata tables such as a `temporal_columns` table that refers to the time properties of data records. +* specify a streaming synchronization protocol for GeoPackage as part of a future GeoPackage Web Service specification, and/or a future version of the GeoPackage and/or Web Synchronization Service specification(s). +* address symbology and styling information. +* include geographic / geodesic geometry types. +* create a GeoPackage Abstract Object Model to support data encodings other than SQL. +* add https://github.com/mapbox/utfgrid-spec[UTFGrid] support. + +Future versions of this standard and/or one for a GeoPackage Web Service MAY do the following: +* address utilities for importing and exporting vector, raster and tile data in various formats. +* address encryption of GeoPackages and/or individual tables or column values. === UML Notation From 34b4c66639ccf2daee2773ae6d5dca19a7059bdf Mon Sep 17 00:00:00 2001 From: Jeff Yutzler Date: Thu, 19 Nov 2015 08:59:48 -0500 Subject: [PATCH 3/5] rewriting sentence regarding extended GeoPackages (6) --- spec/1_base.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec/1_base.adoc b/spec/1_base.adoc index eb73d367..f6eaf6e6 100644 --- a/spec/1_base.adoc +++ b/spec/1_base.adoc @@ -52,7 +52,7 @@ It is RECOMMENDED that Extended GeoPackages use the file extension “.gpkx”, A GeoPackage SHALL only contain data elements, SQL constructs and GeoPackage extensions with the “gpkg” author name specified in this encoding standard. In order to guarantee maximum interoperability between applications, GeoPackages SHALL NOT contain data elements (tables or columns), SQL constructs (data types, indexes, constraints or triggers) or extensions that are not specified in this encoding standard. -SQLite databases that use constructs from the GeoPackage standard but extend that to contain any of these elements are referred to as Extended GeoPackages throughout this standard. +SQLite databases that use constructs from the GeoPackage standard but extend those constructs to contain elements not specified in the core GeoPackage standard are referred to as Extended GeoPackages throughout this standard. [requirement] The columns of tables in a GeoPackage SHALL only be declared using one of the data types specified in table <>. From f6b8d252774d82ae86711f61aa84061f3f98402c Mon Sep 17 00:00:00 2001 From: Jeff Yutzler Date: Thu, 19 Nov 2015 09:02:44 -0500 Subject: [PATCH 4/5] specification -> standard (9) --- spec/2a_features.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec/2a_features.adoc b/spec/2a_features.adoc index 59fe772a..bdbf11ff 100644 --- a/spec/2a_features.adoc +++ b/spec/2a_features.adoc @@ -5,7 +5,7 @@ ==== Simple Features SQL Introduction Vector feature data represents geolocated entities including conceptual ones such as districts, real world objects such as roads and rivers, and observations thereof. -International specifications <<9>><<10>><<11>><<12>> have standardized practices for the storage, access and use of vector geospatial features and geometries via SQL in relational databases. +International standards <<9>><<10>><<11>><<12>> have standardized practices for the storage, access and use of vector geospatial features and geometries via SQL in relational databases. The first component of the SQL schema for vector features in a GeoPackage is the `gpkg_spatial_ref_sys` table defined in clause <> above. Other components are defined below. From e36303b0ca340ea747a01f32d68461ff90afb78a Mon Sep 17 00:00:00 2001 From: Jeff Yutzler Date: Thu, 19 Nov 2015 09:05:46 -0500 Subject: [PATCH 5/5] expand WMTS (12) --- spec/2b_tiles.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec/2b_tiles.adoc b/spec/2b_tiles.adoc index 02b075fe..eedf19c4 100644 --- a/spec/2b_tiles.adoc +++ b/spec/2b_tiles.adoc @@ -36,7 +36,7 @@ Pixel sizes are real numbers in the terrain units of the spatial reference syste Pixel size MAY vary by a constant factor or by different factors or intervals between some or all adjacent zoom levels in a tile matrix set. In the commonly used "zoom times two" convention, pixel sizes vary by a factor of 2 between all adjacent zoom levels, as shown in the example in <>. Other "zoom other intervals" conventions use different factors or irregular intervals with pixel sizes chosen for intuitive cartographic representation of raster data, or to coincide with the original pixel size of commonly used global image products. -See WMTS <<16>> Annex E for additional examples of both conventions. +See Web Map Tile Service (WMTS) <<16>> Annex E for additional examples of both conventions. ===== Data