Merge pull request #161 from jyutzler/creed

Administrative edits

Author: jyutzler

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/.

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:
    - [email protected] -- [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.
 

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,16 +69,16 @@ 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 
 changes](http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository) and 
 [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.
 
 

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 <<geopackage_tables_figure>> 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 <<background_and_context>>, 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 <<background_and_context>>, which MAY be addressed in a subsequent version of this standard or by other specifications.
 
 [[geopackage_tables_figure]]
 .GeoPackage Tables Overview

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 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 <<table_column_data_types>>.

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 <<spatial_ref_sys>> above.
 Other components are defined below.
 

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 <<tiles_factor2_example_appendix>>.
 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
 

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 <<extension_template>>. 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 <<extension_template>>. 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 <author>_<extension name> where <author> 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.
 
 

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.
+The GeoPackage standard does not place any constraints on application, platform, operating system level or network security.