[postgis-tickets] [SCM] PostGIS branch master updated. fa7aaf09a40b18e9ac508206e5fa2cb3ebf8fd2e

[git at osgeo.org]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "PostGIS".

The branch, master has been updated
       via  fa7aaf09a40b18e9ac508206e5fa2cb3ebf8fd2e (commit)
      from  651add11bdb70ccb3b94cc640c99457bdc80f0dd (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit fa7aaf09a40b18e9ac508206e5fa2cb3ebf8fd2e
Author: Mitchell Henke <mitchell at mitchellhenke.com>
Date:   Mon Nov 25 10:02:35 2019 -0600

    Fix a couple doc typos and reword for clarity

diff --git a/doc/using_postgis_dataman.xml b/doc/using_postgis_dataman.xml
index b7de2df..3e56367 100644
--- a/doc/using_postgis_dataman.xml
+++ b/doc/using_postgis_dataman.xml
@@ -2165,19 +2165,19 @@ WHERE
       size, and the penalty in write workload. Otherwise, BRIN index can be
       considered as an alternative. </para>
 
-      <para>The idea of a BRIN index is to store only the bouding box englobing
+      <para>The idea of a BRIN index is to store only the bounding box enclosing
       all the geometries contained in all the rows in a set of table blocks,
       called a range.  Obviously, this indexing method will only be efficient
-      if the data is physically ordered in a way where the resulting bouding
+      if the data is physically ordered in a way where the resulting bounding
       boxes for block ranges will be mutually exclusive. The resulting index
       will be really small, but will be less efficient than a GiST index in
       many cases.</para>
 
 	  <para>Building a BRIN index is way less intensive than building a GiST
-	  index. It's quite common to build a BRIN index in more than ten time less
-	  than a GiST index would have required. As a BRIN index only store one
-	  bouding box for one to many table blocks, it's pretty common to consume
-	  up to a thousand time less disk space for this kind of indexes.</para>
+	  index. It's quite common to build a BRIN index ten times faster
+	  than a GiST index would have required. As a BRIN index only stores one
+	  bounding box for one to many table blocks, it's pretty common to consume
+	  up to a thousand times less disk space for this kind of index.</para>
 
       <para>You can choose the number of blocks to summarize in a range. If you
       decrease this number, the index will be bigger but will probably help to

-----------------------------------------------------------------------

Summary of changes:
 doc/using_postgis_dataman.xml | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)


hooks/post-receive
-- 
PostGIS