[postgis-tickets] [SCM] postgis.net branch website updated. clarity-final-3-g01ccbd9
git at osgeo.org
git at osgeo.org
Fri May 12 17:08:45 PDT 2023
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.net".
The branch, website has been updated
via 01ccbd9532fa05c0b13f4c3f4a9051d851c3a365 (commit)
from 99928f24ea6726a1fbe101457dd5efd80d153e2b (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 01ccbd9532fa05c0b13f4c3f4a9051d851c3a365
Author: Regina Obe <lr at pcorp.us>
Date: Fri May 12 20:08:39 2023 -0400
Add tags to faqs
diff --git a/content/documentation/faq/big-objects-performance.md b/content/documentation/faq/big-objects-performance.md
index d9fc824..8e62f75 100644
--- a/content/documentation/faq/big-objects-performance.md
+++ b/content/documentation/faq/big-objects-performance.md
@@ -4,6 +4,7 @@ date: 2022-02-01
draft: false
geekdocHidden: true
geekdocHiddenTocTree: false
+tags: [performance]
---
Because they are big! All things being equal, it is going to take more time to do calculations against a 100,000 vertex polygon of Canada than against a 5 vertex polygon of Colorado.
@@ -13,7 +14,7 @@ What drives that extra time?
* Just **getting the object into memory** to work with. An object that is larger than 4kb (which is any object with more than about 200 vertices) will end up chopped into smaller pieces by the [PostgreSQL TOAST system](https://www.postgresql.org/docs/current/storage-toast.html), and stored in a side table. Getting the object into memory involves retrieving all the parts and then concatenating them together. Usually they have also been compressed on storage, so there's a decompression step too.
* Having to pull out the **whole object** in order to test a very **local question**. You might only care about whether a fishing boat in the Pacific is 100 km from the Canadian coastline, but you'll be pulling all the Atlantic provinces into memory in order to answer that question.
* Running **calculations on a large number of vertices** can take a very long time. PostGIS does its best to temporarily index and cache index information about geometries, to keep processing differences down, but bigger objects are still bigger.
-* Spatially **large objects have large bounding boxes**, which means inefficient index scans. Even for objects with relatively few vertices, a bad bounding box can result in a lot of computational churn. The bounding box for France, for example, includes not only continental France, but also the territories of San Pierre and Michelon in the Gulf of Saint Lawrence, on the other side of the Atlantic. As a result a query around Iceland could return France as part of the index scan, and then France would have to be excluded via a more expensive calculation.
+* Spatially **large objects have large bounding boxes**, which means inefficient index scans. Even for objects with relatively few vertices, a bad bounding box can result in a lot of computational churn. The bounding box for France, for example, includes not only continental France, but also the territories of San Pierre and Michelon in the Gulf of Saint Lawrence, on the other side of the Atlantic. As a result a query around Iceland could return France as part of the index scan, and then France would have to be excluded via a more expensive calculation.
What can be done?
diff --git a/content/documentation/faq/geography-inside.md b/content/documentation/faq/geography-inside.md
index 14a82bf..c36145b 100644
--- a/content/documentation/faq/geography-inside.md
+++ b/content/documentation/faq/geography-inside.md
@@ -4,6 +4,7 @@ date: 2022-02-01
draft: false
geekdocHidden: true
geekdocHiddenTocTree: false
+tags: [geography]
---
Firstly, it's **not**! But a frequent question we get is of the form, "the geography intersects test is saying this point is side this box, when clearly it is not, why?"
@@ -12,11 +13,11 @@ Here's the example:
```postgres
WITH wkt AS (
- SELECT
+ SELECT
'POLYGON((0 0, 80 0, 80 10, 0 10, 0 0))' AS box,
'POINT(40 10.1)' AS pt
)
-SELECT
+SELECT
ST_Intersects(wkt.box::geography, wkt.pt::geography) AS intersects_geog,
ST_Intersects(wkt.box::geometry, wkt.pt::geometry) AS intersects_geom
FROM wkt;
@@ -25,7 +26,7 @@ FROM wkt;
Same box, same point, but different answers depending on if you evaluate as geometry, or geography. Why?
```
- intersects_geog | intersects_geom
+ intersects_geog | intersects_geom
-----------------+-----------------
t | f
```
diff --git a/content/documentation/faq/geography-spheroid.md b/content/documentation/faq/geography-spheroid.md
index 616a5b9..4844927 100644
--- a/content/documentation/faq/geography-spheroid.md
+++ b/content/documentation/faq/geography-spheroid.md
@@ -3,16 +3,17 @@ title: "Are geography calculations done on the spheroid?"
date: 2022-02-01
draft: false
geekdocHidden: true
-geekdocHiddenTocTree: false
+geekdocHiddenTocTree:
+tags: [geography]
---
To a first approximation, **yes**. If you calculate the distance between two geography points, that calculation will be based on the spheroid defined by the SRID attached to the points, which if you do not specify it will be [WGS84](https://en.wikipedia.org/wiki/World_Geodetic_System#WGS_84).
-However, in general PostGIS uses a combination of spherical and spheroidal calculations for geography.
+However, in general PostGIS uses a combination of spherical and spheroidal calculations for geography.
For example, if you are calculating the distance between more complex objects, like the distance between two polygons, the algorithm has a couple steps:
-* First it has to cycle through the edges of the polygons, to find out which edges are the nearest edges.
+* First it has to cycle through the edges of the polygons, to find out which edges are the nearest edges.
* Then it takes the two points on those edges that are closest and calculates the distance between them.
For the first step, finding the closest edges, PostGIS uses distances on the **sphere**. If we used calculations on the spheroid, we would be doing a large number of very expensive calculations to ultimately just discard edges, edges that a simple spherical calculation would also discard.
diff --git a/content/documentation/faq/geometry-or-geography.md b/content/documentation/faq/geometry-or-geography.md
index 2ed002f..0facb31 100644
--- a/content/documentation/faq/geometry-or-geography.md
+++ b/content/documentation/faq/geometry-or-geography.md
@@ -4,22 +4,23 @@ date: 2022-02-01
draft: false
geekdocHidden: true
geekdocHiddenTocTree: false
+tags: [geometry,geography]
---
The **geography** type is very convenient for people whose data is **of global extent** and for people who do not want to learn about projected coordinate systems. However, calculations on the spheroid are very expensive, so many queries will be slower in geography than geometry.
Also, because calculations on the sphere are tricky, only a [subset of functions](https://postgis.net/docs/PostGIS_Special_Functions_Index.html#PostGIS_GeographyFunctions) are directly implemented for geography. In particular, the following spatial functions do calculations on the sphere/spheroid, and using spatial indexes where possible.
-* ST_Area
+* ST_Area
* ST_Azimuth
* ST_CoveredBy
-* ST_Covers
+* ST_Covers
* ST_DWithin
-* ST_Distance
-* ST_Intersects
-* ST_Length
+* ST_Distance
+* ST_Intersects
+* ST_Length
* ST_Perimeter
-* ST_Project
+* ST_Project
* ST_Segmentize
The **geometry** type is easy to understand, and represents data on a cartesian plane. All the vector functions in PostGIS work against geometry. You will have to choose a planar "spatial reference system" for your data if it does not already have one, but then all your calculations will be very simple, and will run much faster than on geography.
diff --git a/content/documentation/faq/gpl-license.md b/content/documentation/faq/gpl-license.md
index 3f88f39..066c939 100644
--- a/content/documentation/faq/gpl-license.md
+++ b/content/documentation/faq/gpl-license.md
@@ -4,6 +4,7 @@ date: 2022-02-01
draft: false
geekdocHidden: true
geekdocHiddenTocTree: false
+tags: [licensing]
---
PostGIS is open source software available under the [GNU GPLv2](https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html). While the GPL does have some expansive "share and share alike" clauses in it, they **do not apply** to the ordinary uses people make of a spatial database, such as loading data into it and running queries against it.
@@ -12,4 +13,4 @@ If you are releasing software that uses PostGIS, does that mean your software ha
Almost certainly **not**. As an example, consider an Oracle database running on Linux. Linux is GPL, Oracle is not: does Oracle running on Linux have to be distributed using the GPL? No. Similarly your software can use a PostgreSQL/PostGIS database as much as it wants and be under any license you like.
-The **only exception** would be if you made changes to the PostGIS source code, and distributed your changed version of PostGIS. In that case you would have to share the code of your changed PostGIS (but not the code of applications running on top of it). Even in this limited case, you would still only have to distribute source code to people you distributed binaries to. The GPL does not require that you publish your source code, only that you share it with people you give binaries to.
\ No newline at end of file
+The **only exception** would be if you made changes to the PostGIS source code, and distributed your changed version of PostGIS. In that case you would have to share the code of your changed PostGIS (but not the code of applications running on top of it). Even in this limited case, you would still only have to distribute source code to people you distributed binaries to. The GPL does not require that you publish your source code, only that you share it with people you give binaries to.
diff --git a/content/documentation/faq/intersection-intersect.md b/content/documentation/faq/intersection-intersect.md
index 2a91b21..2955deb 100644
--- a/content/documentation/faq/intersection-intersect.md
+++ b/content/documentation/faq/intersection-intersect.md
@@ -4,6 +4,7 @@ date: 2022-02-01
draft: false
geekdocHidden: true
geekdocHiddenTocTree: false
+tags: [geometry,ST_Intersects, ST_Intersection]
---
The intersection of two lines, **A** and **B**, is a point **P**. In math class, you learn that **P** falls on both **A** and **B**. It's just math!
@@ -12,11 +13,11 @@ So, why are there easily constructable cases in PostGIS where the intersection o
```postgres
WITH parts AS (
- SELECT
+ SELECT
'LINESTRING(0 0, 10 11)'::geometry AS a,
'LINESTRING(11 0, 0 19)'::geometry AS b
)
-SELECT
+SELECT
ST_AsText(ST_Intersection(a, b)) AS intersection,
ST_Intersects(ST_Intersection(a, b), a) AS intersects_a,
ST_Intersects(ST_Intersection(a, b), b) AS intersects_b
@@ -30,7 +31,7 @@ intersects_b | f
Coordinates in PostGIS are represented as pairs of "[floating point](https://en.wikipedia.org/wiki/Double-precision_floating-point_format)" numbers, which are capable of representing a very large numner of values. But not an **infinite** number of values.
-The rule that "where A intersects B at P, P will be on both A and B" is a mathematical rule for the "real numbers" of which there are an infinite number. The finite quantity of numbers that a computer's floating point can represent end up looking like a piece of graph paper.
+The rule that "where A intersects B at P, P will be on both A and B" is a mathematical rule for the "real numbers" of which there are an infinite number. The finite quantity of numbers that a computer's floating point can represent end up looking like a piece of graph paper.
If you draw a straight line on a piece of graph paper, mostly the line won't hit many graph crossing points. The same is true of lines in the world of the "floating point grid". The result is that the calculated intersection of two lines, frequently does not land on either of the lines, but instead lands on a (very very close) nearby point that is representable as a floating point number.
diff --git a/content/documentation/faq/pgadmin-blank-geometry.md b/content/documentation/faq/pgadmin-blank-geometry.md
index 63d9173..4925ab5 100644
--- a/content/documentation/faq/pgadmin-blank-geometry.md
+++ b/content/documentation/faq/pgadmin-blank-geometry.md
@@ -4,11 +4,12 @@ date: 2022-02-01
draft: false
geekdocHidden: true
geekdocHiddenTocTree: false
+tags: [geometry,geography, pgadmin]
---
Compared to most data types, geometries are quite large. For some versions of PgAdmin, there is a maximum amount of data that can be show in a cell, and if the record is larger than that, the cell simply appears blank.
-* You can use [ST_AsText()](/docs/ST_AsText.html) to get a human readable form of the geometry, but that might still be too large.
+* You can use [ST_AsText()](/docs/ST_AsText.html) to get a human readable form of the geometry, but that might still be too large.
* You can use a simplifying function, like [ST_Centroid()](/docs/ST_Centroid.html) to get a geometry that is small enough to visualize.
* You can use a summary function, like [ST_NPoints()](/docs/ST_NPoints.html) to replace the geometry with a count of the number of vertices in the geometry.
* In more recent versions of PgAdmin, you can click the "eye" icon in the cell to get a map visualization of the geometry.
diff --git a/content/documentation/faq/radius-search.md b/content/documentation/faq/radius-search.md
index e8ba7f4..c94167e 100644
--- a/content/documentation/faq/radius-search.md
+++ b/content/documentation/faq/radius-search.md
@@ -3,7 +3,8 @@ title: "How can I find all objects within a radius of another object?"
date: 2022-02-01
draft: false
geekdocHidden: true
-geekdocHiddenTocTree: false
+geekdocHiddenTocTree:
+tags: [geometry,geography, ST_DWithin]
---
There are a few ways to do a radius search, but the key here is to do an **efficient** search.
@@ -11,7 +12,7 @@ There are a few ways to do a radius search, but the key here is to do an **effic
There is a function purpose-built for this query, [ST_DWithin()](/docs/ST_DWithin.html).
```postgres
-SELECT *
+SELECT *
FROM mytable
WHERE ST_DWithin(geom, 'POINT(1000 1000)', 100.0)
```
@@ -21,7 +22,7 @@ The "DWithin" stands for "within distance". You could form the same query using
Another approach is to use the [ST_Intersects()](docs/ST_Intersects.html) and [ST_Buffer()](docs/ST_Buffer.html) functions together like this.
```postgres
-SELECT *
+SELECT *
FROM mytable
WHERE ST_Intersects(ST_Buffer(geom, 100.0), 'POINT(1000 1000)')
```
diff --git a/content/documentation/faq/spatial-indexes.md b/content/documentation/faq/spatial-indexes.md
index 407cdf6..a0ae1b2 100644
--- a/content/documentation/faq/spatial-indexes.md
+++ b/content/documentation/faq/spatial-indexes.md
@@ -4,6 +4,7 @@ date: 2022-02-01
draft: false
geekdocHidden: true
geekdocHiddenTocTree: false
+tags: [geometry,geography, performance]
---
Spatial indexes are hugely important for getting good performance on spatial SQL queries! You need to do two things to use a spatial index:
@@ -44,7 +45,7 @@ So a spatial join query can make use of a spatial relationship between tables an
```postgres
SELECT a.name, b.id
FROM a
-JOIN b
+JOIN b
ON ST_Contains(a.geom, b.geom)
WHERE a.name = 'Pleasantown'
```
diff --git a/content/documentation/faq/transform.md b/content/documentation/faq/transform.md
index a0dc5b4..eec3023 100644
--- a/content/documentation/faq/transform.md
+++ b/content/documentation/faq/transform.md
@@ -4,11 +4,12 @@ date: 2022-02-01
draft: false
geekdocHidden: true
geekdocHiddenTocTree: false
+tags: [geometry,ST_Transform, projection]
---
-To perform a reprojection, both the source and destination coordinate systems must be defined in the `spatial_ref_sys` table, and the geometries being reprojected must already have an SRID set on them.
+To perform a reprojection, both the source and destination coordinate systems must be defined in the `spatial_ref_sys` table, and the geometries being reprojected must already have an SRID set on them.
-Once that is done, a reprojection is as simple as referring to the desired destination SRID. The below projects a geometry to WGS84 longitude/latitude coordinates.
+Once that is done, a reprojection is as simple as referring to the desired destination SRID. The below projects a geometry to WGS84 longitude/latitude coordinates.
```postgres
SELECT ST_Transform(geom, 4326) FROM mytable;
@@ -17,15 +18,15 @@ SELECT ST_Transform(geom, 4326) FROM mytable;
Make sure that your geometry column has an SRID, or reprojection won't work! You can check if the SRID is enforced at the column level:
```postgres
-SELECT srid
- FROM geometry_columns
+SELECT srid
+ FROM geometry_columns
WHERE f_table_name = 'mytable'
```
And you can check if it is set at the geometry level:
```postgres
-SELECT ST_SRID(geom) AS srid, Count(*)
- FROM mytable
+SELECT ST_SRID(geom) AS srid, Count(*)
+ FROM mytable
GROUP BY srid;
-```
\ No newline at end of file
+```
-----------------------------------------------------------------------
Summary of changes:
content/documentation/faq/big-objects-performance.md | 3 ++-
content/documentation/faq/geography-inside.md | 7 ++++---
content/documentation/faq/geography-spheroid.md | 7 ++++---
content/documentation/faq/geometry-or-geography.md | 13 +++++++------
content/documentation/faq/gpl-license.md | 3 ++-
content/documentation/faq/intersection-intersect.md | 7 ++++---
content/documentation/faq/pgadmin-blank-geometry.md | 3 ++-
content/documentation/faq/radius-search.md | 7 ++++---
content/documentation/faq/spatial-indexes.md | 3 ++-
content/documentation/faq/transform.md | 15 ++++++++-------
10 files changed, 39 insertions(+), 29 deletions(-)
hooks/post-receive
--
postgis.net
More information about the postgis-tickets
mailing list