Hämta källarkivet för PostGIS från nedladdningswebbplatsen https://download.osgeo.org/postgis/source/postgis-3.6.3.tar.gz

wget https://download.osgeo.org/postgis/source/postgis-3.6.3.tar.gz
tar -xvzf postgis-3.6.3.tar.gz
cd postgis-3.6.3

Detta kommer att skapa en katalog som heter postgis-&last_release_version; i den aktuella arbetskatalogen.

Alternativt kan du hämta källkoden från git-förrådet https://git.osgeo.org/gitea/postgis/postgis/ .

git clone https://git.osgeo.org/gitea/postgis/postgis.git postgis
cd postgis
sh autogen.sh
    

Byt till den nyskapade postgis-katalogen för att fortsätta installationen.

./configure

PostGIS har följande krav för uppbyggnad och användning:

Obligatorisk

Valfritt

Som med de flesta Linux-installationer är det första steget att generera den Makefile som ska användas för att bygga källkoden. Detta görs genom att köra skalskriptet

./configure

Utan ytterligare parametrar försöker detta kommando att automatiskt hitta de komponenter och bibliotek som behövs för att bygga PostGIS-källkoden på ditt system. Även om detta är den vanligaste användningen av ./configure, accepterar skriptet flera parametrar för dem som har de nödvändiga biblioteken och programmen på icke-standardiserade platser.

I följande lista visas endast de vanligaste parametrarna. För en fullständig lista, använd parametrarna --help eller --help=short.

	Om du har hämtat PostGIS från kodförvaret är det första steget verkligen att köra skriptet ./autogen.sh Detta skript kommer att generera configure-skriptet som i sin tur används för att anpassa installationen av PostGIS. Om du istället fick PostGIS som en tarball är det inte nödvändigt att köra ./autogen.sh eftersom configure redan har genererats.

När Makefile har genererats är det enkelt att bygga PostGIS genom att köra

make

Den sista raden i utskriften ska vara"PostGIS byggdes framgångsrikt. Redo att installeras."

Från och med PostGIS v1.4.0 har alla funktioner kommentarer som genererats från dokumentationen. Om du vill installera dessa kommentarer i dina spatiala databaser senare, kör kommandot som kräver docbook. Filerna postgis_comments.sql och andra paketkommentarer raster_comments.sql, topology_comments.sql finns också i tar.gz-distributionen i doc-mappen, så du behöver inte skapa kommentarer om du installerar från tar-bollen. Kommentarer ingår också som en del av CREATE EXTENSION-installationen.

make comments

Introducerades i PostGIS 2.0. Detta genererar html-fuskblad som är lämpliga för snabb referens eller för studentutdelningar. Detta kräver xsltproc för att bygga och kommer att generera 4 filer i doc-mappen topology_cheatsheet.html, tiger_geocoder_cheatsheet.html, raster_cheatsheet.html, postgis_cheatsheet.html

Du kan ladda ner några förbyggda tillgängliga i html och pdf från PostGIS / PostgreSQL Study Guides

make cheatsheets

PostGIS-tilläggen byggs och installeras automatiskt om du använder PostgreSQL 9.1+.

Om du bygger från källkatalogen måste du först bygga funktionsbeskrivningarna. Dessa byggs om du har docbook installerat. Du kan också bygga manuellt med uttalandet:

make comments

Det är inte nödvändigt att bygga kommentarerna om du bygger från en release-tarball eftersom dessa redan är färdigbyggda med tarballen.

Tilläggen bör automatiskt byggas som en del av make-installationsprocessen. Du kan vid behov bygga från tilläggsmapparna eller kopiera filer om du behöver dem på en annan server.

cd extensions
cd postgis
make clean
make
export PGUSER=postgres #overwrite psql variables
make check #to test before install
make install
# to test extensions
make check RUNTESTFLAGS=--extension

	make check använder psql för att köra tester och kan därför använda psql-miljövariabler. Vanliga variabler som är användbara att åsidosätta är PGUSER,PGPORT och PGHOST. Hänvisa till psql-miljövariabler

Tilläggsfilerna kommer alltid att vara desamma för samma version av PostGIS och PostgreSQL oavsett operativsystem, så det går bra att kopiera över tilläggsfilerna från ett operativsystem till ett annat så länge du har PostGIS-binärerna redan installerade på dina servrar.

Om du vill installera tillägg manuellt på en separat server som skiljer sig från din utveckling måste du kopiera följande filer från tilläggsmappen till mappen PostgreSQL / share / extension i din PostgreSQL-installation samt de nödvändiga binärerna för vanlig PostGIS om du inte redan har dem på servern.

När du har gjort det bör du se postgis, postgis_topology som tillgängliga tillägg i PgAdmin -> tillägg.

Om du använder psql kan du kontrollera att tilläggen är installerade genom att köra den här frågan:

SELECT name, default_version,installed_version
FROM pg_available_extensions WHERE name LIKE 'postgis%' or name LIKE 'address%';

             name             | default_version | installed_version
------------------------------+-----------------+-------------------
 address_standardizer         | 3.6.3         | 3.6.3
 address_standardizer_data_us | 3.6.3         | 3.6.3
 postgis                      | 3.6.3         | 3.6.3
 postgis_raster               | 3.6.3         | 3.6.3
 postgis_sfcgal               | 3.6.3         |
 postgis_tiger_geocoder       | 3.6.3         | 3.6.3
 postgis_topology             | 3.6.3         |
(6 rows)

Om du har tillägget installerat i den databas du frågar kommer du att se ett omnämnande i kolumnen installed_version. Om du inte får några poster tillbaka betyder det att du inte har några postgis-tillägg installerade på servern alls. PgAdmin III 1.14+ kommer också att tillhandahålla denna information i tilläggsavsnittet i databasbläddrarträdet och kommer till och med att tillåta uppgradering eller avinstallation genom att högerklicka.

Om du har tilläggen tillgängliga kan du installera postgis-tillägget i din valfria databas genom att antingen använda pgAdmin-tilläggsgränssnittet eller köra dessa sql-kommandon:

CREATE EXTENSION postgis;
CREATE EXTENSION postgis_raster;
CREATE EXTENSION postgis_sfcgal;
CREATE EXTENSION fuzzystrmatch; --needed for postgis_tiger_geocoder
--optional used by postgis_tiger_geocoder, or can be used standalone
CREATE EXTENSION address_standardizer;
CREATE EXTENSION address_standardizer_data_us;
CREATE EXTENSION postgis_tiger_geocoder;
CREATE EXTENSION postgis_topology;

I psql kan du använda för att se vilka versioner du har installerat och även vilket schema de är installerade.

\connect mygisdb
\x
\dx postgis*

List of installed extensions
-[ RECORD 1 ]-------------------------------------------------
Name        | postgis
Version     | 3.6.3
Schema      | public
Description | PostGIS geometry, geography, and raster spat..
-[ RECORD 2 ]-------------------------------------------------
Name        | postgis_raster
Version     | 3.0.0dev
Schema      | public
Description | PostGIS raster types and functions
-[ RECORD 3 ]-------------------------------------------------
Name        | postgis_tiger_geocoder
Version     | 3.6.3
Schema      | tiger
Description | PostGIS tiger geocoder and reverse geocoder
-[ RECORD 4 ]-------------------------------------------------
Name        | postgis_topology
Version     | 3.6.3
Schema      | topology
Description | PostGIS topology spatial types and functions

Tilläggstabellerna spatial_ref_sys, layer, topology kan inte uttryckligen säkerhetskopieras. De kan bara säkerhetskopieras när respektive postgis- eller postgis_topology-utökningen säkerhetskopieras, vilket bara verkar hända när du säkerhetskopierar hela databasen. Från och med PostGIS 2.0.1 säkerhetskopieras endast srid-poster som inte är paketerade med PostGIS när databasen säkerhetskopieras, så gå inte runt och ändra srids som vi paketerar och förvänta dig att dina ändringar ska finnas där. Lägg in ett ärende om du hittar ett problem. Strukturerna i tilläggstabellerna säkerhetskopieras aldrig eftersom de skapas med CREATE EXTENSION och antas vara desamma för en given version av ett tillägg. Dessa beteenden är inbyggda i den nuvarande PostgreSQL-utökningsmodellen, så ingenting vi kan göra åt det.

Om du installerade 3.6.3, utan att använda vårt underbara utökningssystem, kan du ändra det till att vara utökningsbaserat genom att köra kommandona nedan för att paketera funktionerna i deras respektive utökning. Installation med `unpackaged` togs bort i PostgreSQL 13, så du rekommenderas att byta till en utökningsbyggnad innan du uppgraderar till PostgreSQL 13.

CREATE EXTENSION postgis FROM unpackaged;
CREATE EXTENSION postgis_raster FROM unpackaged;
CREATE EXTENSION postgis_topology FROM unpackaged;
CREATE EXTENSION postgis_tiger_geocoder FROM unpackaged;

Om du vill testa PostGIS-bygget kör du

make check

Ovanstående kommando kommer att köra igenom olika kontroller och regressionstester med hjälp av det genererade biblioteket mot en faktisk PostgreSQL-databas.

	Om du konfigurerade PostGIS med icke-standardiserade PostgreSQL-, GEOS- eller Proj-platser kan du behöva lägga till deras biblioteksplatser i miljövariabeln LD_LIBRARY_PATH.

	För närvarande förlitar sig make-kontrollen på PATH- och PGPORT-miljövariablerna när de utför kontrollerna - den använder inte PostgreSQL-versionen som kan ha angetts med hjälp av konfigurationsparametern --with-pgconfig. Så se till att ändra din PATH så att den matchar den upptäckta PostgreSQL-installationen under konfigurationen eller var beredd att hantera de överhängande huvudvärkarna.

Om make check lyckas kommer resultatet av nästan 500 tester att visas. Resultaten kommer att se ut ungefär som följande (många rader utelämnade nedan):

CUnit - A unit testing framework for C - Version 2.1-3
     http://cunit.sourceforge.net/

        .
        .
        .

Run Summary:    Type  Total    Ran Passed Failed Inactive
              suites     44     44    n/a      0        0
               tests    300    300    300      0        0
             asserts   4215   4215   4215      0      n/a
Elapsed time =    0.229 seconds

        .
        .
        .

Running tests

        .
        .
        .

Run tests: 134
Failed: 0


-- if you build with SFCGAL

        .
        .
        .

Running tests

        .
        .
        .

Run tests: 13
Failed: 0

-- if you built with raster support

        .
        .
        .

Run Summary:    Type  Total    Ran Passed Failed Inactive
              suites     12     12    n/a      0        0
               tests     65     65     65      0        0
             asserts  45896  45896  45896      0      n/a


        .
        .
        .

Running tests

        .
        .
        .

Run tests: 101
Failed: 0

-- topology regress

.
.
.

Running tests

        .
        .
        .

Run tests: 51
Failed: 0

-- if you built --with-gui, you should see this too

     CUnit - A unit testing framework for C - Version 2.1-2
     http://cunit.sourceforge.net/

        .
        .
        .

Run Summary:    Type  Total    Ran Passed Failed Inactive
              suites      2      2    n/a      0        0
               tests      4      4      4      0        0
             asserts      4      4      4      0      n/a

Postgis_tiger_geocoder och address_standardizer-tillägg stöder för närvarande endast standard PostgreSQL-installationskontrollen. För att testa dessa använder du nedan. Obs: make install är inte nödvändigt om du redan har gjort make install vid roten till PostGIS-kodmappen.

För address_standardizer:

cd extensions/address_standardizer
make install
make installcheck
          

Utdata bör se ut som:

============== dropping database "contrib_regression" ==============
DROP DATABASE
============== creating database "contrib_regression" ==============
CREATE DATABASE
ALTER DATABASE
============== running regression test queries        ==============
test test-init-extensions     ... ok
test test-parseaddress        ... ok
test test-standardize_address_1 ... ok
test test-standardize_address_2 ... ok

=====================
 All 4 tests passed.
=====================

För tigergeokoder, se till att du har postgis och fuzzystrmatch-tillägg tillgängliga i din PostgreSQL-instans. Adress_standardizer-testerna kommer också att starta om du byggde postgis med adress_standardizer-stöd:

cd extensions/postgis_tiger_geocoder
make install
make installcheck
          

utdata bör se ut som:

============== dropping database "contrib_regression" ==============
DROP DATABASE
============== creating database "contrib_regression" ==============
CREATE DATABASE
ALTER DATABASE
============== installing fuzzystrmatch               ==============
CREATE EXTENSION
============== installing postgis                     ==============
CREATE EXTENSION
============== installing postgis_tiger_geocoder      ==============
CREATE EXTENSION
============== installing address_standardizer        ==============
CREATE EXTENSION
============== running regression test queries        ==============
test test-normalize_address   ... ok
test test-pagc_normalize_address ... ok

=====================
All 2 tests passed.
=====================

För att installera PostGIS skriver du

make install

Detta kommer att kopiera PostGIS-installationsfilerna till lämplig underkatalog som anges av konfigurationsparametern --prefix. I synnerhet:

Om du tidigare körde kommandot make comments för att generera filen postgis_comments.sql, raster_comments.sq l, installerar du sql-filen genom att köra

make comments-install

	postgis_comments.sql, raster_comments.sql, topology_comments.sql separerades från de typiska bygg- och installationsmålen eftersom det medför det extra beroendet av xsltproc.

Ett av de många klagomålen från folk är adressnormaliseringsfunktionen Normalize_Address funktion som normaliserar en adress för prepping före geokodning. Normaliseraren är långt ifrån perfekt och att försöka lappa dess ofullkomlighet tar en enorm mängd resurser. Därför har vi integrerat med ett annat projekt som har en mycket bättre adresstandardiseringsmotor. För att använda denna nya address_standardizer kompilerar du tillägget enligt beskrivningen i Section 2.3, “Installera och använda adresstandardiseraren” och installerar det som ett tillägg i din databas.

När du installerar det här tillägget i samma databas som du har installerat postgis_tiger_geocoder, kan Pagc_Normalize_Address användas istället för Normalize_Address. Det här tillägget är tigeragnostiskt, så det kan användas med andra datakällor, t.ex. internationella adresser. Tillägget tiger geocoder levereras förpackat med sina egna anpassade versioner av rules table ( tiger .pagc_rules) , gaz table (tiger.pagc_gaz) och lex table (tiger.pagc_lex). Dessa kan du lägga till och uppdatera för att förbättra din standardiseringsupplevelse för dina egna behov.

Laddningsprocessen hämtar data från folkräkningswebbplatsen för respektive nationsfiler, begärda stater, extraherar filerna och laddar sedan varje stat till sin egen separata uppsättning statstabeller. Varje statstabell ärver från de tabeller som definieras i tiger-schemat så att det räcker att bara fråga dessa tabeller för att få tillgång till alla data och släppa en uppsättning statstabeller när som helst med hjälp av Drop_State_Tables_Generate_Script om du behöver ladda om en stat eller bara inte behöver en stat längre.

För att kunna läsa in data behöver du följande verktyg:

Om du uppgraderar från tiger_2010 måste du först generera och köra Drop_Nation_Tables_Generate_Script. Innan du laddar någon delstatsdata måste du ladda den nationella datan, vilket du gör med Loader_Generate_Nation_Script. Vilket kommer att generera ett laddningsskript åt dig. Loader_Generate_Nation_Script är ett engångssteg som bör göras för uppgradering (från ett tidigare års tiger-folkräkningsdata) och för nya installationer.

För att ladda in delstatsdata, se Loader_Generate_Script för att generera ett dataladdningsskript för din plattform för de delstater du önskar. Observera att du kan installera dessa stegvis. Du behöver inte ladda alla de stater du vill ha på en gång. Du kan ladda dem när du behöver dem.

När de tillstånd du vill ha har laddats, se till att köra :

SELECT install_missing_indexes();

enligt beskrivningen i Install_Missing_Indexes.

För att testa att saker och ting fungerar som de ska kan du försöka köra en geokod på en adress i din delstat med hjälp av Geocode

Uppgradera först ditt postgis_tiger_geocoder-tillägg enligt följande:

ALTER EXTENSION postgis_tiger_geocoder UPDATE;

Därefter släpper du alla nationstabeller och laddar upp de nya. Generera ett drop script med denna SQL-sats enligt beskrivningen i Drop_Nation_Tables_Generate_Script

SELECT drop_nation_tables_generate_script();

Kör de genererade SQL-satserna för drop.

Generera ett script för att läsa in en nation med denna SELECT-sats enligt beskrivningen i Loader_Generate_Nation_Script

För Windows

SELECT loader_generate_nation_script('windows'); 

För unix/linux

SELECT loader_generate_nation_script('sh');

Se Section 2.4.1, “Tiger Geocoder Aktivering av din PostGIS-databas” för instruktioner om hur du kör genereringsskriptet. Detta behöver bara göras en gång.

	Du kan ha en blandning av olika års statstabeller och kan uppgradera varje stat separat. Innan du uppgraderar en stat måste du först ta bort tidigare års statstabeller för den staten med hjälp av Drop_State_Tables_Generate_Script.

Dessa inställningar konfigureras i postgresql.conf::

constraint_exclusion

shared_buffers

max_worker_processes Denna inställning är endast tillgänglig för PostgreSQL 9.4+. För PostgreSQL 9.6+ har denna inställning ytterligare betydelse genom att den styr det maximala antalet processer du kan ha för parallella frågor.

work_mem - anger storleken på det minne som används för sorteringsoperationer och komplexa frågor

maintenance_work_mem - den minnesstorlek som används för VACUUM, CREATE INDEX etc.

max_parallel_workers_per_gather

Denna inställning är endast tillgänglig för PostgreSQL 9.6+ och påverkar endast PostGIS 2.3+, eftersom endast PostGIS 2.3+ stöder parallella frågor. Om den är inställd på högre än 0 kan vissa frågor, till exempel de som involverar relationsfunktioner som ST_Intersects, använda flera processer och kan köra mer än dubbelt så snabbt när de gör det. Om du har många processorer över bör du ändra värdet för detta till så många processorer som du har. Se också till att öka max_worker_processes till minst lika högt som det här värdet.

Om du använder PostgreSQL 9.1+ och har kompilerat och installerat extensions / postgis-modulerna kan du förvandla en databas till en spatial med hjälp av EXTENSION-mekanismen.

Core postgis-tillägget inkluderar geometri, geografi, spatial_ref_sys och alla funktioner och kommentarer. Raster och topologi är paketerade som ett separat tillägg.

Kör följande SQL-snutt i den databas som du vill aktivera spatialt:

CREATE EXTENSION IF NOT EXISTS plpgsql;
      CREATE EXTENSION postgis;
      CREATE EXTENSION postgis_raster; -- OPTIONAL
      CREATE EXTENSION postgis_topology; -- OPTIONAL

	Detta behövs i allmänhet bara om du inte kan eller inte vill få PostGIS installerat i PostgreSQL-tilläggskatalogen (till exempel under testning, utveckling eller i en begränsad miljö).

Att lägga till PostGIS-objekt och funktionsdefinitioner i din databas görs genom att läsa in de olika sql-filerna som finns i [prefix]/share/contrib enligt specifikationerna under byggfasen.

De centrala PostGIS-objekten (geometri- och geograftyper och deras stödfunktioner) finns i skriptet postgis .sql. Rasterobjekt finns i skriptet rtpostgis.sql. Topologiobjekt finns i skriptet topology .sql.

För en fullständig uppsättning EPSG-koordinatsystemdefinitionsidentifierare kan du också läsa in definitionsfilen spatial_ref_sys.sql och fylla i tabellen spatial_ref_sys. Detta gör att du kan utföra ST_Transform()-operationer på geometrier.

Om du vill lägga till kommentarer till PostGIS-funktionerna kan du hitta dem i skriptet postgis_comments.sql. Kommentarer kan visas genom att helt enkelt skriva \dd [function_name] från ett psql-terminalfönster.

Kör följande Shell-kommandon i din terminal:

DB=[yourdatabase]
    SCRIPTSDIR=`pg_config --sharedir`/contrib/postgis-3.5/

    # Core objects
    psql -d ${DB} -f ${SCRIPTSDIR}/postgis.sql
    psql -d ${DB} -f ${SCRIPTSDIR}/spatial_ref_sys.sql
    psql -d ${DB} -f ${SCRIPTSDIR}/postgis_comments.sql # OPTIONAL

    # Raster support (OPTIONAL)
    psql -d ${DB} -f ${SCRIPTSDIR}/rtpostgis.sql
    psql -d ${DB} -f ${SCRIPTSDIR}/raster_comments.sql # OPTIONAL

    # Topology support (OPTIONAL)
    psql -d ${DB} -f ${SCRIPTSDIR}/topology.sql
    psql -d ${DB} -f ${SCRIPTSDIR}/topology_comments.sql # OPTIONAL

Om du installerade din databas med hjälp av tillägg måste du också uppgradera med hjälp av tilläggsmodellen. Om du installerade med den gamla sql-skriptmetoden rekommenderas du att byta din installation till tillägg eftersom skriptmetoden inte längre stöds.

3.4.1.1. Soft Upgrade 9.1+ med hjälp av tillägg

Om du ursprungligen installerade PostGIS med tillägg måste du också uppgradera med hjälp av tillägg. Att göra en mindre uppgradering med tillägg är ganska smärtfritt.

Om du kör PostGIS 3 eller senare bör du använda funktionen PostGIS_Extensions_Upgrade för att uppgradera till den senaste versionen som du har installerat.

SELECT postgis_extensions_upgrade();

Om du kör PostGIS 2.5 eller lägre ska du göra följande:

ALTER EXTENSION postgis UPDATE;
SELECT postgis_extensions_upgrade();
-- This second call is needed to rebundle postgis_raster extension
SELECT postgis_extensions_upgrade();

Om du har flera versioner av PostGIS installerade och inte vill uppgradera till den senaste, kan du uttryckligen ange versionen på följande sätt:

ALTER EXTENSION postgis UPDATE TO "3.6.3";
ALTER EXTENSION postgis_topology UPDATE TO "3.6.3";

Om du får ett felmeddelande något i stil med:

No migration path defined for … to 3.6.3

Sedan måste du säkerhetskopiera din databas, skapa en ny enligt beskrivningen i Section 3.3.1, “Spatial aktivering av databas med hjälp av EXTENSION” och sedan återställa din säkerhetskopia ovanpå den nya databasen.

Om du får ett meddelande som:

Version "3.6.3" of extension "postgis" is already installed

Då är allt redan uppdaterat och du kan tryggt ignorera det. OM du inte försöker uppgradera från en utvecklingsversion till nästa (som inte får ett nytt versionsnummer); i så fall kan du lägga till "next" till versionssträngen, och nästa gång måste du släppa "next"-suffixet igen:

ALTER EXTENSION postgis UPDATE TO "3.6.3next";
ALTER EXTENSION postgis_topology UPDATE TO "3.6.3next";

	Om du installerade PostGIS ursprungligen utan en angiven version kan du ofta hoppa över ominstallationen av postgis-tillägget innan du återställer eftersom säkerhetskopian bara har CREATE EXTENSION postgis och därmed plockar upp den senaste versionen under återställningen.

	Om du uppgraderar PostGIS-tillägget från en version före 3.0.0 kommer du att ha ett nytt tillägg postgis_raster som du säkert kan ta bort om du inte behöver rasterstöd. Du kan släppa enligt följande: DROP EXTENSION postgis_raster;

3.4.1.2. Soft Upgrade Pre 9.1+ eller utan tillägg

Detta avsnitt gäller endast för de som installerat PostGIS utan att använda tillägg. Om du har tillägg och försöker uppgradera med detta tillvägagångssätt får du meddelanden som:

can't drop … because postgis extension depends on it

OBS: om du flyttar från PostGIS 1.* till PostGIS 2.* eller från PostGIS 2.* före r7409, kan du inte använda denna procedur utan måste göra en HÅRD UPPDATERING.

När du har kompilerat och installerat (make install) bör du hitta en uppsättning *_upgrade.sql-filer i installationsmapparna. Du kan lista dem alla med:

ls `pg_config --sharedir`/contrib/postgis-3.6.3/*_upgrade.sql

Läs in dem alla i tur och ordning, med början från postgis_upgrade.sql.

psql -f postgis_upgrade.sql -d your_spatial_database

Samma procedur gäller för raster-, topologi- och sfcgal-tillägg, med uppgraderingsfiler som heter rtpostgis_upgrade.sql, topology_upgrade.sql respektive sfcgal_upgrade.sql. Om du behöver dem:

psql -f rtpostgis_upgrade.sql -d your_spatial_database

psql -f topology_upgrade.sql -d your_spatial_database

psql -f sfcgal_upgrade.sql -d your_spatial_database

Vi rekommenderar att du byter till en tilläggsbaserad installation genom att köra

psql -c "SELECT postgis_extensions_upgrade();"

	Om du inte kan hitta postgis_upgrade.sql som är specifik för uppgradering av din version använder du en version som är för tidig för en mjuk uppgradering och måste göra en HÅRD UPPGRADERING.

Funktionen PostGIS_Full_Version bör informera dig om behovet av att köra den här typen av uppgradering med hjälp av meddelandet "procs need upgrade".

Med HÅRD UPPGRADERING menar vi fullständig dumpning/omladdning av PostGIS-aktiverade databaser. Du behöver en HÅRD UPPGRADERING när PostGIS-objektens interna lagring ändras eller när MJUK UPPGRADERING inte är möjlig. Bilagan Release Notes rapporterar för varje version om du behöver en dumpning/omladdning (HARD UPGRADE) för att uppgradera.

Dump/reload-processen stöds av skriptet postgis_restore som tar hand om att hoppa över alla definitioner som tillhör PostGIS (inklusive gamla) från dumpningen, vilket gör att du kan återställa dina scheman och data till en databas med PostGIS installerat utan att få duplicerade symbolfel eller föra fram föråldrade objekt.

Kompletterande instruktioner för Windows-användare finns på Windows Hard upgrade.

Förfarandet är som följer:

Fel kan uppstå i följande fall:

Open Geospatial Consortium (OGC) har utvecklat Enkel åtkomst till funktioner (SFA) för att tillhandahålla en modell för geospatiala data. Den definierar den grundläggande spatiala typen av geometri, tillsammans med operationer som manipulerar och transformerar geometrivärden för att utföra spatiala analysuppgifter. PostGIS implementerar OGC Geometry-modellen som PostgreSQL-datatyperna geometri och geografi.

Geometry är en abstrakt typ. Geometry-värden tillhör en av dess konkreta subtyper som representerar olika typer och dimensioner av geometriska former. Dessa inkluderar atomtyperna Point, LineString, LinearRing och Polygon, samt samlingstyperna MultiPoint, MultiLineString, MultiPolygon och GeometryCollection. De Access till enkla funktioner - Del 1: Gemensam arkitektur v1.2.1 lägger till subtyper för strukturerna PolyhedralSurface, Triangle och TIN.

Geometry modellerar former i det 2-dimensionella kartesiska planet. Typerna PolyhedralSurface, Triangle och TIN kan också representera former i ett 3-dimensionellt rum. Formernas storlek och placering anges av deras koordinater. Varje koordinat har ett X- och Y-ordinatvärde som bestämmer dess läge i planet. Former konstrueras av punkter eller linjesegment, där punkter specificeras av en enda koordinat och linjesegment av två koordinater.

Koordinaterna kan innehålla valfria Z- och M-ordinatvärden. Z-ordinaten används ofta för att representera höjd. M-ordinaten innehåller ett mätvärde, som kan representera tid eller avstånd. Om Z- eller M-värden finns i ett geometrivärde måste de definieras för varje punkt i geometrin. Om en geometri har Z- eller M-ordinater är koordinatdimensionen 3D; om den har både Z- och M-ordinater är koordinatdimensionen 4D.

Geometrivärden associeras med ett spatialt referenssystem som anger det koordinatsystem i vilket det är inbäddat. Det spatiala referenssystemet identifieras av geometrins SRID-nummer. Enheterna för X- och Y-axlarna bestäms av det spatiala referenssystemet. I plana referenssystem representerar X- och Y-koordinaterna vanligtvis ost- och nordlig riktning, medan de i geodetiska system representerar longitud och latitud. SRID 0 representerar ett oändligt kartesiskt plan utan några enheter tilldelade dess axlar. Se Section 4.5, “Spatiala referenssystem”.

Geometridimensionen är en egenskap hos geometrityper. Punkttyper har dimension 0, linjära typer har dimension 1 och polygonala typer har dimension 2. Samlingar har dimensionen för den maximala elementdimensionen.

Ett geometrivärde kan vara tomt. Tomma värden innehåller inga toppar (för atomära geometrityper) eller inga element (för samlingar).

En viktig egenskap hos geometrivärden är deras spatiala extent eller bounding box, som i OGC-modellen kallas envelope. Detta är den 2- eller 3-dimensionella box som omsluter koordinaterna för en geometri. Det är ett effektivt sätt att representera en geometris utbredning i koordinatrymden och att kontrollera om två geometrier interagerar.

Geometrimodellen gör det möjligt att utvärdera topologiska spatiala relationer enligt beskrivningen i Section 5.1.1, “Dimensionsutvidgad 9-intersektionell modell”. För att stödja detta definieras begreppen interior, boundary och exterior för varje geometrityp. Geometrier är topologiskt slutna, vilket innebär att de alltid innehåller sin gräns. Gränsen är en geometri med en dimension som är en mindre än geometrins egen dimension.

OGC:s geometrimodell definierar giltighetsregler för varje geometrityp. Dessa regler säkerställer att geometrivärdena representerar realistiska situationer (det är t.ex. möjligt att ange en polygon med ett hål som ligger utanför skalet, men detta är geometriskt ologiskt och därmed ogiltigt). PostGIS tillåter också lagring och manipulering av ogiltiga geometrivärden. Detta gör det möjligt att upptäcka och åtgärda dem vid behov. Se även Section 4.4, “Validering av geometri”

POINT (1 2)
POINT Z (1 2 3)
POINT ZM (1 2 3 4)

LINESTRING (1 2, 3 4, 5 6)

LINEARRING (0 0 0, 4 0 0, 4 4 0, 0 4 0, 0 0 0)

POLYGON ((0 0 0,4 0 0,4 4 0,0 4 0,0 0 0),(1 1 0,2 1 0,2 2 0,1 2 0,1 1 0))

MULTIPOINT ( (0 0), (1 2) )

MULTILINESTRING ( (0 0,1 1,1 2), (2 3,3 2,5 4) )

MULTIPOLYGON (((1 5, 5 5, 5 1, 1 1, 1 5)), ((6 5, 9 1, 6 1, 6 5)))

GEOMETRYCOLLECTION ( POINT(2 3), LINESTRING(2 3, 3 4))

POLYHEDRALSURFACE Z (
  ((0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0)),
  ((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)),
  ((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)),
  ((1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0)),
  ((0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0)),
  ((0 0 1, 1 0 1, 1 1 1, 0 1 1, 0 0 1)) )

TRIANGLE ((0 0, 0 9, 9 0, 0 0))

TIN Z ( ((0 0 0, 0 0 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 0 0 0)) )

ISO/IEC 13249-3 ISO/IEC 13249-3 SQL Multimedia - Spatial (SQL/MM) utökar OGC SFA för att definiera Geometry-subtyper som innehåller kurvor med cirkelbågar. SQL/MM-typerna stöder 3DM-, 3DZ- och 4D-koordinater.

	Alla jämförelser med flyttal i SQL-MM-implementationen utförs med en angiven tolerans, för närvarande 1E-8.

CIRCULARSTRING(0 0, 1 1, 1 0)

CIRCULARSTRING(0 0, 4 0, 4 4, 0 4, 0 0)

COMPOUNDCURVE( CIRCULARSTRING(0 0, 1 1, 1 0),(1 0, 0 1))

CURVEPOLYGON(
  CIRCULARSTRING(0 0, 4 0, 4 4, 0 4, 0 0),
  (1 1, 3 3, 3 1, 1 1) )

CURVEPOLYGON(
  COMPOUNDCURVE( CIRCULARSTRING(0 0,2 0, 2 1, 2 3, 4 3),
                 (4 3, 4 5, 1 4, 0 0)),
  CIRCULARSTRING(1.7 1, 1.4 0.4, 1.6 0.4, 1.6 0.5, 1.7 1) )

MULTICURVE( (0 0, 5 5), CIRCULARSTRING(4 0, 4 4, 8 4))

MULTISURFACE(
  CURVEPOLYGON(
    CIRCULARSTRING( 0 0, 4 0, 4 4, 0 4, 0 0),
    (1 1, 3 3, 3 1, 1 1)),
  ((10 10, 14 12, 11 10, 10 10), (11 11, 11.5 11, 11 11.5, 11 11)))

OGC SFA-specifikationen definierar två format för att representera geometriska värden för extern användning: Well-Known Text (WKT) och Well-Known Binary (WKB). Både WKT och WKB innehåller information om typen av objekt och de koordinater som definierar det.

Well-Known Text (WKT) tillhandahåller en standardiserad textuell representation av spatiala data. Exempel på WKT-representationer av spatiala objekt är:

In- och utdata för WKT tillhandahålls av funktionerna ST_AsText och ST_GeomFromText:

text WKT = ST_AsText(geometry);
geometry = ST_GeomFromText(text WKT, SRID);

Ett exempel på en instruktion för att skapa och infoga ett spatialt objekt från WKT och en SRID är:

INSERT INTO geotable ( geom, name )
  VALUES ( ST_GeomFromText('POINT(-126.4 45.32)', 312), 'A Place');

Well-Known Binary (WKB) tillhandahåller en portabel representation med full precision av spatiala data som binära data (matriser av bytes). Exempel på WKB-representationer av spatiala objekt är:

In- och utdata för WKB tillhandahålls av funktionerna ST_AsBinary och ST_GeomFromWKB:

bytea WKB = ST_AsBinary(geometry);
geometry = ST_GeomFromWKB(bytea WKB, SRID);

Ett villkor för att skapa och infoga ett spatialt objekt från WKB är t.ex:

INSERT INTO geotable ( geom, name )
  VALUES ( ST_GeomFromWKB('\x0101000000000000000000f03f000000000000f03f', 312), 'A Place');

OGC SFA-specifikationerna stödde ursprungligen endast 2D-geometrier, och geometrins SRID ingår inte i inmatnings-/utdatarepresentationerna. OGC SFA-specifikationen 1.2.1 (som överensstämmer med ISO 19125-standarden) lägger till stöd för 3D (ZYZ) och uppmätta (XYM och XYZM) koordinater, men inkluderar fortfarande inte SRID-värdet.

På grund av dessa begränsningar har PostGIS definierat utökade EWKB- och EWKT-format. De ger stöd för koordinater i 3D (XYZ och XYM) och 4D (XYZM) och inkluderar SRID-information. Genom att inkludera all geometriinformation kan PostGIS använda EWKB som format för registrering (t.ex. i DUMP-filer).

EWKB och EWKT används för de "kanoniska formerna" för PostGIS dataobjekt. För indata är den kanoniska formen för binära data EWKB, och för textdata accepteras antingen EWKB eller EWKT. Detta gör det möjligt att skapa geometrivärden genom att kasta ett textvärde i antingen HEXEWKB eller EWKT till ett geometrivärde med hjälp av ::geometry. För utdata är den kanoniska formen för binära data EWKB och för text är den HEXEWKB (hex-kodad EWKB).

Till exempel skapar denna sats en geometri genom casting från ett EWKT-textvärde och matar ut den med den kanoniska formen av HEXEWKB:

SELECT 'SRID=4;POINT(0 0)'::geometry;
  geometry
  ----------------------------------------------------
  01010000200400000000000000000000000000000000000000

PostGIS EWKT-utdata har några skillnader jämfört med OGC WKT:

EWKT undviker överspecificering av dimensionalitet och de inkonsekvenser som kan uppstå med OGC/ISO-formatet, t.ex:

	PostGIS utökade format är för närvarande en superset av OGC:s format, så att varje giltig OGC WKB/WKT också är giltig EWKB/EWKT. Detta kan dock variera i framtiden, om OGC utökar ett format på ett sätt som strider mot PosGIS-definitionen. Därför SKA du INTE förlita dig på denna kompatibilitet!

Exempel på EWKT-textrepresentation av spatiala objekt är:

Inmatning och utdata med dessa format kan göras med hjälp av följande funktioner:

bytea EWKB = ST_AsEWKB(geometry);
text EWKT = ST_AsEWKT(geometry);
geometry = ST_GeomFromEWKB(bytea EWKB);
geometry = ST_GeomFromEWKT(text EWKT);

Ett villkor för att skapa och infoga ett spatialt PostGIS-objekt med EWKT är t.ex:

INSERT INTO geotable ( geom, name )
  VALUES ( ST_GeomFromEWKT('SRID=312;POINTM(-126.4 45.32 15)'), 'A Place' )

Du kan skapa en tabell för att lagra geografiska data genom att använda SQL-satsen CREATE TABLE med en kolumn av typen geography. I följande exempel skapas en tabell med en geografikolumn som lagrar 2D LineStrings i det geodetiska koordinatsystemet WGS84 (SRID 4326):

CREATE TABLE global_points (
    id SERIAL PRIMARY KEY,
    name VARCHAR(64),
    location geography(POINT,4326)
  );

Geografitypen har stöd för två valfria typmodifierare:

Exempel på hur man skapar tabeller med geografikolumner:

Geografiska fält registreras i systemvyn geography_columns. Du kan ställa en fråga till vyn geography_columns och se att tabellen finns med i listan:

SELECT * FROM geography_columns;

Att skapa ett spatialt index fungerar på samma sätt som för geometrikolumner. PostGIS kommer att notera att kolumntypen är GEOGRAPHY och skapa ett lämpligt sfärbaserat index istället för det vanliga plana indexet som används för GEOMETRY.

-- Index the test table with a spherical index
CREATE INDEX global_points_gix ON global_points USING GIST ( location );

Du kan infoga data i geograftabeller på samma sätt som i geometritabeller. Geometridata kommer att autokastas till geograftypen om den har SRID 4326. EWKT- och EWKB-formaten kan också användas för att ange geografiska värden.

-- Add some data into the test table
INSERT INTO global_points (name, location) VALUES ('Town', 'SRID=4326;POINT(-110 30)');
INSERT INTO global_points (name, location) VALUES ('Forest', 'SRID=4326;POINT(-109 29)');
INSERT INTO global_points (name, location) VALUES ('London', 'SRID=4326;POINT(0 49)');

Alla geodetiska (lång/lat) spatiala referenssystem som förtecknas i tabellen spatial_ref_sys kan anges som ett geografiskt SRID. Icke-geodetiska koordinatsystem ger upphov till ett fel om de används.

-- NAD 83 lon/lat
SELECT 'SRID=4269;POINT(-123 34)'::geography;
                    geography
----------------------------------------------------
 0101000020AD1000000000000000C05EC00000000000004140

-- NAD27 lon/lat
SELECT 'SRID=4267;POINT(-123 34)'::geography;
                    geography
----------------------------------------------------
 0101000020AB1000000000000000C05EC00000000000004140

-- NAD83 UTM zone meters - gives an error since it is a meter-based planar projection
SELECT 'SRID=26910;POINT(-123 34)'::geography;

ERROR:  Only lon/lat coordinate systems are supported in geography.

Fråge- och mätfunktioner använder enheter i meter. Avståndsparametrar bör därför uttryckas i meter och returvärden bör förväntas i meter (eller kvadratmeter för områden).

-- A distance query using a 1000km tolerance
SELECT name FROM global_points WHERE ST_DWithin(location, 'SRID=4326;POINT(-110 29)'::geography, 1000000);

Du kan se geografins kraft i aktion genom att beräkna hur nära ett plan som flyger en cirkelrutt från Seattle till London (LINESTRING(-122,33 47,606, 0,0 51,5)) kommer Reykjavik (POINT(-21,96 64,15))(kartlägg rutten).

Geografitypen beräknar det kortaste verkliga avståndet på 122,235 km över sfären mellan Reykjavik och storcirkelflygvägen mellan Seattle och London.

-- Distance calculation using GEOGRAPHY
SELECT ST_Distance('LINESTRING(-122.33 47.606, 0.0 51.5)'::geography, 'POINT(-21.96 64.15)'::geography);
   st_distance
-----------------
 122235.23815667

Geometritypen beräknar ett meningslöst kartesiskt avstånd mellan Reykjavik och den raka vägen från Seattle till London utritad på en platt världskarta. Den nominella enheten för resultatet är "grader", men resultatet motsvarar inte någon verklig vinkelskillnad mellan punkterna, så att kalla dem "grader" är felaktigt.

-- Distance calculation using GEOMETRY
SELECT ST_Distance('LINESTRING(-122.33 47.606, 0.0 51.5)'::geometry, 'POINT(-21.96 64.15)'::geometry);
      st_distance
--------------------
 13.342271221453624

Med datatypen Geography kan du lagra data i koordinater för longitud/latitud, men till en kostnad: det finns färre funktioner definierade för GEOGRAPHY än för GEOMETRY; de funktioner som är definierade tar mer CPU-tid att utföra.

Den datatyp du väljer bör bestämmas av det förväntade arbetsområdet för den applikation du bygger. Kommer dina data att omfatta hela jordklotet eller ett stort kontinentalt område, eller är de lokala för en stat, ett län eller en kommun?

Se Section 13.11, “PostGIS matris för funktionsstöd” för en jämförelse mellan vad som stöds för Geography respektive Geometry. För en kort lista och beskrivning av Geography-funktioner, se Section 13.4, “Stödfunktioner för geografi i PostGIS”

En enkel geometri är en geometri som inte har några avvikande geometriska punkter, t.ex. självskärning eller självtangentiering.

En POINT är i sig själv enkel som ett 0-dimensionellt geometriobjekt.

MULTIPOINTsär enkla om inte två koordinater(POINTs)är lika (har identiska koordinatvärden).

En LINESTRING är enkel om den inte passerar genom samma punkt två gånger, med undantag för ändpunkterna. Om ändpunkterna på en enkel LineString är identiska kallas den sluten och kallas för en Linear Ring.

(a) och (c) är enkla LINESTRINGs. (b) och (d) är inte enkla. (c) är en sluten Linear Ring.

(a)	(b)
(c)	(d)

En MULTILINESTRING är enkel endast om alla dess element är enkla och den enda skärningen mellan två element sker i punkter som ligger på båda elementens gränser.

(e) och (f) är enkla MULTILINESTRINGar. (g) är inte enkel.

(e)

(f)

(g)

POLYGONERbildas av linjära ringar, så giltig polygonal geometri är alltid enkel.

För att testa om en geometri är enkel kan du använda funktionen ST_IsSimple:

SELECT
   ST_IsSimple('LINESTRING(0 0, 100 100)') AS straight,
   ST_IsSimple('LINESTRING(0 0, 100 100, 100 0, 0 100)') AS crossing;

 straight | crossing
----------+----------
 t        | f

Generellt kräver inte PostGIS-funktioner att geometriska argument ska vara enkla. Enkelhet används främst som en grund för att definiera geometrisk validitet. Det är också ett krav för vissa typer av spatiala datamodeller (t.ex. tillåter linjära nätverk ofta inte linjer som korsar varandra). Multipunkts- och linjärgeometri kan göras enkel med hjälp av ST_UnaryUnion.

Geometrisk validitet gäller främst för 2-dimensionella geometrier(POLYGONERoch MULTIPOLYGONER). Validiteten definieras av regler som gör att polygonal geometri kan modellera plana områden på ett otvetydigt sätt.

En POLYGON är giltig om:

(h) och (i) är giltiga POLYGONER. (j-m) är ogiltiga. (j) kan representeras som en giltig MULTIPOLYGON.

(h)	(i)	(j)
(k)	(l)	(m)

En MULTIPOLYGON är giltig om:

(n) är en giltig MULTIPOLYGON. (o) och (p) är ogiltiga.

(n)

(o)

(p)

Dessa regler innebär att giltig polygonal geometri också är enkel..

För linjär geometri är den enda giltighetsregeln att LINESTRINGsmåste ha minst två punkter och ha en längd som inte är noll (eller motsvarande, ha minst två distinkta punkter.) Observera att icke-enkla (självskärande) linjer är giltiga.

SELECT
   ST_IsValid('LINESTRING(0 0, 1 1)') AS len_nonzero,
   ST_IsValid('LINESTRING(0 0, 0 0, 0 0)') AS len_zero,
   ST_IsValid('LINESTRING(10 10, 150 150, 180 50, 20 130)') AS self_int;

 len_nonzero | len_zero | self_int
-------------+----------+----------
 t           | f        | t

POINT- och MULTIPOINT-geometrierna har inga giltighetsregler.

PostGIS tillåter skapande och lagring av både giltig och ogiltig geometri. Detta gör att ogiltig geometri kan upptäckas och flaggas eller fixas. Det finns också situationer där OGC:s giltighetsregler är strängare än önskat (exempel på detta är linestrings med noll längd och polygoner med inverterade hål)

Många av de funktioner som PostGIS tillhandahåller förutsätter att geometriargumenten är giltiga. Det är till exempel inte meningsfullt att beräkna arean av en polygon som har ett hål definierat utanför polygonen, eller att konstruera en polygon från en icke-enkel begränsningslinje. Genom att anta giltiga geometriska indata kan funktioner arbeta mer effektivt, eftersom de inte behöver kontrollera att de är topologiskt korrekta. (Noterbara undantag är att nollängdslinjer och polygoner med inversioner i allmänhet hanteras korrekt) Dessutom producerar de flesta PostGIS-funktioner giltiga geometriska utdata om indata är giltiga. Detta gör att PostGIS-funktioner kan kedjas ihop på ett säkert sätt.

Om du stöter på oväntade felmeddelanden när du anropar PostGIS-funktioner (t.ex. "GEOS Intersection() kastade ett fel!") bör du först bekräfta att funktionsargumenten är giltiga. Om de inte är det bör du överväga att använda någon av nedanstående tekniker för att säkerställa att de data du bearbetar är giltiga.

	Om en funktion rapporterar ett fel med giltiga indata kan du ha hittat ett fel i antingen PostGIS eller ett av de bibliotek som används, och du bör rapportera detta till PostGIS-projektet. Detsamma gäller om en PostGIS-funktion returnerar en ogiltig geometri för giltig indata.

För att testa om en geometri är giltig kan du använda funktionen ST_IsValid:

SELECT ST_IsValid('POLYGON ((20 180, 180 180, 180 20, 20 20, 20 180))');
-----------------
 t

Information om arten av och platsen för en geometrisk invaliditet tillhandahålls av funktionen ST_IsValidDetail:

SELECT valid, reason, ST_AsText(location) AS location
    FROM ST_IsValidDetail('POLYGON ((20 20, 120 190, 50 190, 170 50, 20 20))') AS t;

 valid |      reason       |                  location
-------+-------------------+---------------------------------------------
 f     | Self-intersection | POINT(91.51162790697674 141.56976744186045)

I vissa situationer är det önskvärt att korrigera ogiltig geometri automatiskt. Använd funktionen ST_MakeValid för att göra detta.(ST_MakeValid är ett exempel på en spatial funktion som tillåter ogiltiga indata!)

Som standard kontrollerar PostGIS inte giltigheten vid laddning av geometri, eftersom giltighetstestning kan ta mycket CPU-tid för komplexa geometrier. Om du inte litar på dina datakällor kan du tvinga fram en giltighetskontroll på dina tabeller genom att lägga till en check constraint:

ALTER TABLE mytable
  ADD CONSTRAINT geometry_valid_check
        CHECK (ST_IsValid(geom));

Tabellen SPATIAL_REF_SYS som används av PostGIS är en OGC-kompatibel databastabell som definierar de tillgängliga spatiala referenssystemen. Den innehåller de numeriska SRID:erna och textbeskrivningarna av koordinatsystemen.

Definitionen av tabellen spatial_ref_sys är:

CREATE TABLE spatial_ref_sys (
  srid       INTEGER NOT NULL PRIMARY KEY,
  auth_name  VARCHAR(256),
  auth_srid  INTEGER,
  srtext     VARCHAR(2048),
  proj4text  VARCHAR(2048)
)

Kolumnerna är..:

Vid hämtning av definitioner av spatiala referenssystem för användning i transformationer använder PostGIS följande strategi:

Tabellen PostGIS spatial_ref_sys innehåller över 3000 av de vanligaste definitionerna av spatiala referenssystem som hanteras av PROJ-projektionsbiblioteket. Men det finns många koordinatsystem som den inte innehåller. Du kan lägga till SRS-definitioner i tabellen om du har den information som krävs om det spatiala referenssystemet. Eller så kan du definiera ditt eget spatiala referenssystem om du är bekant med PROJ constructs. Tänk på att de flesta spatiala referenssystem är regionala och inte har någon betydelse när de används utanför de gränser som de är avsedda för.

En resurs för att hitta spatiala referenssystem som inte definieras i kärnuppsättningen är http://spatialreference.org/

Några vanligt förekommande spatiala referenssystem är: 4326 - WGS 84 Long Lat, 4269 - NAD 83 Long Lat, 3395 - WGS 84 World Mercator, 2163 - US National Atlas Equal Area och de 60 WGS84 UTM-zonerna. UTM-zoner är en av de mest idealiska för mätning, men täcker endast 6-gradersregioner. (För att avgöra vilken UTM-zon som ska användas för ditt intresseområde, se hjälpfunktionen utmzone PostGIS plpgsql)

Amerikanska delstater använder spatiala referenssystem i State Plane (meter- eller fotbaserade) - vanligtvis finns ett eller två per delstat. De flesta av de meterbaserade finns i kärnuppsättningen, men många av de fotbaserade eller ESRI-skapade måste kopieras från spatialreference.org.

Du kan även definiera koordinatsystem som inte är jordbaserade, t.ex. Mars 2000 Mars koordinatsystem är inte planar (det är i grader sfäroidalt), men du kan använda det med geograftypen för att få längd- och avståndsmätningar i meter i stället för grader.

Här är ett exempel på laddning av ett anpassat koordinatsystem med hjälp av en icke tilldelad SRID och PROJ-definitionen för en US-centrisk Lambert Conformal-projektion:

INSERT INTO spatial_ref_sys (srid, proj4text)
VALUES ( 990000,
  '+proj=lcc  +lon_0=-95 +lat_0=25 +lat_1=25 +lat_2=25 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs'
);

Du kan skapa en tabell för att lagra geometridata genom att använda SQL-satsen CREATE TABLE med en kolumn av typen geometry. I följande exempel skapas en tabell med en geometrikolumn som lagrar 2D (XY) LineStrings i BC-Albers koordinatsystem (SRID 3005):

CREATE TABLE roads (
    id SERIAL PRIMARY KEY,
    name VARCHAR(64),
    geom geometry(LINESTRING,3005)
  );

Geometritypen har stöd för två valfria typmodifierare:

Exempel på hur man skapar tabeller med geometrikolumner:

Det är möjligt att ha mer än en geometrikolumn i en tabell. Detta kan anges när tabellen skapas, eller så kan en kolumn läggas till med SQL-satsen ALTER TABLE. I detta exempel läggs en kolumn till som kan innehålla 3D LineStrings:

ALTER TABLE roads ADD COLUMN geom2 geometry(LINESTRINGZ,4326);

OGC:s Simple Features Specification for SQL definierar metadatatabellen GEOMETRY_COLUMNS för att beskriva geometritabellens struktur. I PostGIS är geometry_columns en vy som läser från databassystemets katalogtabeller. Detta säkerställer att den spatiala metadatainformationen alltid överensstämmer med de tabeller och vyer som för närvarande definieras. Vyn har följande struktur:

\d geometry_columns

View "public.geometry_columns"
      Column       |          Type          | Modifiers
-------------------+------------------------+-----------
 f_table_catalog   | character varying(256) |
 f_table_schema    | character varying(256) |
 f_table_name      | character varying(256) |
 f_geometry_column | character varying(256) |
 coord_dimension   | integer                |
 srid              | integer                |
 type              | character varying(30)  |

Kolumnerna är..:

Två av de fall där du kan behöva detta är vid SQL Views och bulkinsättningar. För bulkinsättningar kan du korrigera registreringen i geometry_columns-tabellen genom att begränsa kolumnen eller göra en alter table. För vyer kan du exponera med hjälp av en CAST-operation. Observera att om din kolumn är typmodbaserad kommer skapandeprocessen att registrera den korrekt, så du behöver inte göra någonting. Även vyer som inte har någon spatial funktion applicerad på geometrin kommer att registreras på samma sätt som den underliggande tabellgeometrikolumnen.

-- Lets say you have a view created like this
CREATE VIEW public.vwmytablemercator AS
        SELECT gid, ST_Transform(geom, 3395) As geom, f_name
        FROM public.mytable;

-- For it to register correctly
-- You need to cast the geometry
--
DROP VIEW public.vwmytablemercator;
CREATE VIEW  public.vwmytablemercator AS
        SELECT gid, ST_Transform(geom, 3395)::geometry(Geometry, 3395) As geom, f_name
        FROM public.mytable;

-- If you know the geometry type for sure is a 2D POLYGON then you could do
DROP VIEW public.vwmytablemercator;
CREATE VIEW  public.vwmytablemercator AS
        SELECT gid, ST_Transform(geom,3395)::geometry(Polygon, 3395) As geom, f_name
        FROM public.mytable;

--Lets say you created a derivative table by doing a bulk insert
SELECT poi.gid, poi.geom, citybounds.city_name
INTO myschema.my_special_pois
FROM poi INNER JOIN citybounds ON ST_Intersects(citybounds.geom, poi.geom);

-- Create 2D index on new table
CREATE INDEX idx_myschema_myspecialpois_geom_gist
  ON myschema.my_special_pois USING gist(geom);

-- If your points are 3D points or 3M points,
-- then you might want to create an nd index instead of a 2D index
CREATE INDEX my_special_pois_geom_gist_nd
        ON my_special_pois USING gist(geom gist_geometry_ops_nd);

-- To manually register this new table's geometry column in geometry_columns.
-- Note it will also change the underlying structure of the table to
-- to make the column typmod based.
SELECT populate_geometry_columns('myschema.my_special_pois'::regclass);

-- If you are using PostGIS 2.0 and for whatever reason, you
-- you need the constraint based definition behavior
-- (such as case of inherited tables where all children do not have the same type and srid)
-- set optional use_typmod argument to false
SELECT populate_geometry_columns('myschema.my_special_pois'::regclass, false); 

Även om den gamla metoden med begränsningar fortfarande stöds, kommer en geometrikolumn som baseras på begränsningar och som används direkt i en vy inte att registreras korrekt i geometry_columns, vilket en typmod-kolumn gör. I det här exemplet definierar vi en kolumn med hjälp av typmod och en annan med hjälp av constraints.

CREATE TABLE pois_ny(gid SERIAL PRIMARY KEY, poi_name text, cat text, geom geometry(POINT,4326));
SELECT AddGeometryColumn('pois_ny', 'geom_2160', 2160, 'POINT', 2, false);

Om vi kör i psql

\d pois_ny;

Vi ser att de definieras på olika sätt - en är typmod, en är begränsning

Table "public.pois_ny"
  Column   |         Type          |                       Modifiers

-----------+-----------------------+------------------------------------------------------
 gid       | integer               | not null default nextval('pois_ny_gid_seq'::regclass)
 poi_name  | text                  |
 cat       | character varying(20) |
 geom      | geometry(Point,4326)  |
 geom_2160 | geometry              |
Indexes:
    "pois_ny_pkey" PRIMARY KEY, btree (gid)
Check constraints:
    "enforce_dims_geom_2160" CHECK (st_ndims(geom_2160) = 2)
    "enforce_geotype_geom_2160" CHECK (geometrytype(geom_2160) = 'POINT'::text
        OR geom_2160 IS NULL)
    "enforce_srid_geom_2160" CHECK (st_srid(geom_2160) = 2160)

I geometry_columns registreras de båda korrekt

SELECT f_table_name, f_geometry_column, srid, type
        FROM geometry_columns
        WHERE f_table_name = 'pois_ny';

f_table_name | f_geometry_column | srid | type
-------------+-------------------+------+-------
pois_ny      | geom              | 4326 | POINT
pois_ny      | geom_2160         | 2160 | POINT

Men - om vi skulle skapa en vy så här

CREATE VIEW vw_pois_ny_parks AS
SELECT *
  FROM pois_ny
  WHERE cat='park';

SELECT f_table_name, f_geometry_column, srid, type
        FROM geometry_columns
        WHERE f_table_name = 'vw_pois_ny_parks';

Den typmodbaserade geom view-kolumnen registreras korrekt, men den constraintbaserade gör det inte.

f_table_name   | f_geometry_column | srid |   type
------------------+-------------------+------+----------
 vw_pois_ny_parks | geom              | 4326 | POINT
 vw_pois_ny_parks | geom_2160         |    0 | GEOMETRY

Detta kan komma att ändras i framtida versioner av PostGIS, men för närvarande måste du göra så här för att tvinga den begränsningsbaserade vykolumnen att registreras korrekt:

DROP VIEW vw_pois_ny_parks;
CREATE VIEW vw_pois_ny_parks AS
SELECT gid, poi_name, cat,
  geom,
  geom_2160::geometry(POINT,2160) As geom_2160
  FROM pois_ny
  WHERE cat = 'park';
SELECT f_table_name, f_geometry_column, srid, type
        FROM geometry_columns
        WHERE f_table_name = 'vw_pois_ny_parks';

f_table_name   | f_geometry_column | srid | type
------------------+-------------------+------+-------
 vw_pois_ny_parks | geom              | 4326 | POINT
 vw_pois_ny_parks | geom_2160         | 2160 | POINT

Om spatiala data kan konverteras till en textrepresentation (som antingen WKT eller WKB) kan SQL vara det enklaste sättet att få in data i PostGIS. Data kan bulk-laddas in i PostGIS/PostgreSQL genom att ladda en textfil med SQL INSERT-satser med hjälp av SQL-verktyget psql.

En SQL-laddningsfil (till exempelroads.sql) kan se ut så här:

BEGIN;
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (1,'LINESTRING(191232 243118,191108 243242)','Jeff Rd');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (2,'LINESTRING(189141 244158,189265 244817)','Geordie Rd');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (3,'LINESTRING(192783 228138,192612 229814)','Paul St');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (4,'LINESTRING(189412 252431,189631 259122)','Graeme Ave');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (5,'LINESTRING(190131 224148,190871 228134)','Phil Tce');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (6,'LINESTRING(198231 263418,198213 268322)','Dave Cres');
COMMIT;

SQL-filen kan laddas in i PostgreSQL med psql:

psql -d [database] -f roads.sql

Shp2pgsql-dataladdaren konverterar Shapefiles till SQL som är lämplig för införande i en PostGIS / PostgreSQL-databas antingen i geometri- eller geografiformat. Laddaren har flera driftlägen som väljs med kommandoradsflaggor.

Det finns också ett grafiskt gränssnitt shp2pgsql-gui med de flesta av alternativen som kommandoradsladdaren. Detta kan vara lättare att använda för engångsladdning utan skript eller om du är nybörjare på PostGIS. Det kan också konfigureras som ett plugin till PgAdminIII.

Ett exempel på en session där laddaren används för att skapa en inmatningsfil och ladda den kan se ut så här:

# shp2pgsql -c -D -s 4269 -i -I shaperoads.shp myschema.roadstable 
> roads.sql
# psql -d roadsdb -f roads.sql

En konvertering och laddning kan göras i ett steg med hjälp av UNIX pipes:

# shp2pgsql shaperoads.shp myschema.roadstable | psql -d roadsdb

Det enklaste sättet att extrahera spatiala data ur databasen är att använda en SQL SELECT-fråga för att definiera den datauppsättning som ska extraheras och dumpa de resulterande kolumnerna i en textfil som kan analyseras:

db=# SELECT road_id, ST_AsText(road_geom) AS geom, road_name FROM roads;

road_id | geom                                    | road_name
--------+-----------------------------------------+-----------
          1 | LINESTRING(191232 243118,191108 243242) | Jeff Rd
          2 | LINESTRING(189141 244158,189265 244817) | Geordie Rd
          3 | LINESTRING(192783 228138,192612 229814) | Paul St
          4 | LINESTRING(189412 252431,189631 259122) | Graeme Ave
          5 | LINESTRING(190131 224148,190871 228134) | Phil Tce
          6 | LINESTRING(198231 263418,198213 268322) | Dave Cres
          7 | LINESTRING(218421 284121,224123 241231) | Chris Way
(6 rows)

Det kommer att finnas tillfällen då någon form av begränsning är nödvändig för att minska antalet poster som returneras. När det gäller attributbaserade begränsningar använder du samma SQL-syntax som för en icke spatial tabell. När det gäller spatiala begränsningar är följande funktioner användbara:

Därefter kan du använda dessa operatorer i frågor. Observera att när du anger geometrier och boxar på SQL-kommandoraden måste du uttryckligen omvandla strängrepresentationerna till geometrier-funktionen. 312 är ett fiktivt spatialt referenssystem som matchar våra data. Så till exempel:

SELECT road_id, road_name
  FROM roads
  WHERE roads_geom='SRID=312;LINESTRING(191232 243118,191108 243242)'::geometry;

Ovanstående fråga skulle returnera den enda post från tabellen "ROADS_GEOM" där geometrin var lika med det värdet.

För att kontrollera om någon av vägarna passerar inom det område som definieras av en polygon:

SELECT road_id, road_name
FROM roads
WHERE ST_Intersects(roads_geom, 'SRID=312;POLYGON((...))');

Den vanligaste spatiala frågan kommer förmodligen att vara en "rambaserad" fråga som används av klientprogramvara, t.ex. webbläsare och webbmappare, för att hämta en "kartram" med data för visning.

När du använder operatorn "&&" kan du ange antingen en BOX3D som jämförelsefunktion eller en GEOMETRY. När du anger en GEOMETRY kommer dock dess bounding box att användas för jämförelsen.

Om du använder ett "BOX3D"-objekt som ram ser en sådan fråga ut så här:

SELECT ST_AsText(roads_geom) AS geom
FROM roads
WHERE
  roads_geom && ST_MakeEnvelope(191232, 243117,191232, 243119,312);

Notera användningen av SRID 312 för att specificera kuvertets projektion.

Tabelldumpern pgsql2shp ansluter till databasen och konverterar en tabell (eventuellt definierad av en fråga) till en shape-fil. Den grundläggande syntaxen är:

pgsql2shp [<options
>] <database
> [<schema
>.]<table>

pgsql2shp [<options
>] <database
> <query>

Alternativen för kommandoraden är:

GiST står för "Generalized Search Tree" och är en generisk form av indexering för flerdimensionella data. PostGIS använder ett R-Tree-index som implementerats ovanpå GiST för att indexera spatiala data. GiST är den vanligaste och mest mångsidiga metoden för spatial indexering och erbjuder mycket bra sökprestanda. Andra implementeringar av GiST används för att påskynda sökningar på alla typer av oregelbundna datastrukturer (heltalsarrayer, spektraldata etc.) som inte är mottagliga för normal B-Tree-indexering. För mer information se PostgreSQL-manualen.

När en spatial datatabell överstiger några tusen rader vill du bygga ett index för att påskynda spatiala sökningar av data (såvida inte alla dina sökningar baseras på attribut, i vilket fall du vill bygga ett normalt index på attributfälten).

Syntaxen för att bygga ett GiST-index på en "geometri"-kolumn är följande:

CREATE INDEX [indexname] ON [tablename] USING GIST ( [geometryfield] ); 

Syntaxen ovan skapar alltid ett 2D-index. Om du vill få ett n-dimensionellt index för geometritypen kan du skapa ett sådant med denna syntax:

CREATE INDEX [indexname] ON [tablename] USING GIST ([geometryfield] gist_geometry_ops_nd);

Att bygga ett spatialt index är en beräkningsintensiv övning. Det blockerar också skrivåtkomst till din tabell under den tid det skapas, så på ett produktionssystem kanske du vill göra det på ett långsammare CONCURRENTLY-medvetet sätt:

CREATE INDEX CONCURRENTLY [indexname] ON [tablename] USING GIST ( [geometryfield] ); 

Efter att ha byggt ett index är det ibland bra att tvinga PostgreSQL att samla in tabellstatistik, som används för att optimera frågeplaner:

VACUUM ANALYZE [table_name] [(column_name)];

BRIN står för "Block Range Index". Det är en indexmetod för allmänt ändamål som introducerades i PostgreSQL 9.5. BRIN är en förlustindexmetod, vilket innebär att en sekundär kontroll krävs för att bekräfta att en post matchar ett visst sökvillkor (vilket är fallet för alla tillhandahållna spatiala index). Det ger mycket snabbare indexskapande och mycket mindre indexstorlek, med rimlig läsprestanda. Dess primära syfte är att stödja indexering av mycket stora tabeller på kolumner som har en korrelation med sin fysiska plats i tabellen. Förutom spatial indexering kan BRIN påskynda sökningar på olika typer av attributdatastrukturer (heltal, matriser etc.). För mer information se PostgreSQL-manualen.

När en spatial tabell överstiger några tusen rader vill du bygga ett index för att påskynda spatiala sökningar av data. GiST-index är mycket effektiva så länge deras storlek inte överstiger mängden RAM-minne som är tillgängligt för databasen och så länge du har råd med indexets lagringsstorlek och kostnaden för indexuppdatering vid skrivning. I annat fall kan BRIN-index betraktas som ett alternativ för mycket stora tabeller.

Ett BRIN-index lagrar den avgränsande box som omsluter alla geometrier som finns i raderna i en sammanhängande uppsättning tabellblock, ett så kallat blockintervall. När en fråga körs med hjälp av indexet skannas blockområdena för att hitta dem som skär frågans utsträckning. Detta är effektivt endast om data är fysiskt ordnade så att blockintervallens avgränsande rutor har minimal överlappning (och helst är ömsesidigt uteslutande). Det resulterande indexet är mycket litet i storlek, men har vanligtvis sämre läsprestanda än ett GiST-index över samma data.

Att bygga ett BRIN-index är mycket mindre CPU-intensivt än att bygga ett GiST-index. Det är vanligt att ett BRIN-index är tio gånger snabbare att bygga än ett GiST-index över samma data. Och eftersom ett BRIN-index bara lagrar en bounding box för varje intervall av tabellblock, är det vanligt att det använder upp till tusen gånger mindre diskutrymme än ett GiST-index.

Du kan välja hur många block som ska sammanfattas i ett intervall. Om du minskar detta antal blir indexet större, men ger förmodligen bättre prestanda.

För att BRIN ska vara effektivt bör tabelldata lagras i en fysisk ordning som minimerar mängden överlappning av blockutbredningen. Det kan hända att data redan är sorterade på lämpligt sätt (t.ex. om de har laddats från en annan dataset som redan är sorterad i spatial ordning). Annars kan detta åstadkommas genom att sortera data efter en endimensionell spatial nyckel. Ett sätt att göra detta är att skapa en ny tabell sorterad efter geometrivärdena (som i de senaste PostGIS-versionerna använder en effektiv Hilbertkurvor-ordning):

CREATE TABLE table_sorted AS
   SELECT * FROM table  ORDER BY geom;

Alternativt kan data sorteras på plats genom att använda en GeoHash som ett (tillfälligt) index och klustra på det indexet:

CREATE INDEX idx_temp_geohash ON table
    USING btree (ST_GeoHash( ST_Transform( geom, 4326 ), 20));
CLUSTER table USING idx_temp_geohash;

Syntaxen för att bygga ett BRIN-index på en geometrikolumn är:

CREATE INDEX [indexname] ON [tablename] USING BRIN ( [geome_col] ); 

Syntaxen ovan skapar ett 2D-index. Om du vill bygga ett 3D-dimensionellt index använder du den här syntaxen:

CREATE INDEX [indexname] ON [tablename]
    USING BRIN ([geome_col] brin_geometry_inclusion_ops_3d);

Du kan också få ett 4D-dimensionellt index med hjälp av operatorsklassen 4D:

CREATE INDEX [indexname] ON [tablename]
    USING BRIN ([geome_col] brin_geometry_inclusion_ops_4d);

Ovanstående kommandon använder standardantalet block i ett intervall, vilket är 128. Om du vill ange antalet block som ska sammanfattas i ett intervall använder du följande syntax

CREATE INDEX [indexname] ON [tablename]
    USING BRIN ( [geome_col] ) WITH (pages_per_range = [number]); 

Tänk på att ett BRIN-index bara lagrar en indexpost för ett stort antal rader. Om din tabell lagrar geometrier med ett blandat antal dimensioner är det troligt att det resulterande indexet kommer att ha dålig prestanda. Du kan undvika denna prestandaförlust genom att välja den operatorsklass som har minst antal dimensioner för de lagrade geometrierna

Datatypen geography stöds för BRIN-indexering. Syntaxen för att bygga ett BRIN-index på en geografikolumn är:

CREATE INDEX [indexname] ON [tablename] USING BRIN ( [geog_col] ); 

Syntaxen ovan bygger upp ett 2D-index för geospatiala objekt på sfäroiden.

För närvarande finns endast "inclusion support", vilket innebär att endast operatorerna &&, ~ och @ kan användas för 2D-fall (för både geometri och geografi), och endast operatorn &&& för 3D-geometrier. Det finns för närvarande inget stöd för kNN-sökningar.

En viktig skillnad mellan BRIN och andra indextyper är att databasen inte underhåller indexet dynamiskt. Ändringar av spatiala data i tabellen läggs helt enkelt till i slutet av indexet. Detta leder till att indexets sökprestanda försämras med tiden. Indexet kan uppdateras genom att utföra en VACUUM eller genom att använda en specialfunktion brin_summarize_new_values(regclass). Av denna anledning kan BRIN vara lämpligast att använda med data som är skrivskyddade eller endast sällan ändras. För mer information se manualen.

Sammanfattningsvis använder vi BRIN för spatiala data:

SP-GiST står för "Space-Partitioned Generalized Search Tree" och är en generisk form av indexering för flerdimensionella datatyper som stöder partitionerade sökträd, t.ex. quad-trees, k-d trees och radix trees (tries). Gemensamt för dessa datastrukturer är att de upprepade gånger delar upp sökrymden i partitioner som inte behöver vara lika stora. Förutom spatial indexering används SP-GiST för att påskynda sökningar på många typer av data, till exempel telefonrouting, ip-routing, substringsökning etc. För mer information se PostgreSQL-manualen.

Liksom GiST-index är SP-GiST-index förlustbringande, i den meningen att de lagrar den avgränsande box som omger spatiala objekt. SP-GiST-index kan betraktas som ett alternativ till GiST-index.

När en GIS-datatabell överstiger några tusen rader kan ett SP-GiST-index användas för att påskynda spatiala sökningar av data. Syntaxen för att bygga ett SP-GiST-index på en "geometri"-kolumn är följande:

CREATE INDEX [indexname] ON [tablename] USING SPGIST ( [geometryfield] ); 

Syntaxen ovan bygger upp ett 2-dimensionellt index. Ett 3-dimensionellt index för geometritypen kan skapas med hjälp av operatorsklassen 3D:

CREATE INDEX [indexname] ON [tablename] USING SPGIST ([geometryfield] spgist_geometry_ops_3d);

Att bygga ett spatialt index är en beräkningsintensiv operation. Det blockerar också skrivåtkomst till din tabell under den tid det skapas, så på ett produktionssystem kanske du vill göra det på ett långsammare CONCURRENTLY-medvetet sätt:

CREATE INDEX CONCURRENTLY [indexname] ON [tablename] USING SPGIST ( [geometryfield] ); 

Efter att ha byggt ett index är det ibland bra att tvinga PostgreSQL att samla in tabellstatistik, som används för att optimera frågeplaner:

VACUUM ANALYZE [table_name] [(column_name)];

Ett SP-GiST-index kan påskynda frågor som involverar följande operatorer:

Det finns för närvarande inget stöd för kNN-sökningar.

Vanligtvis påskyndar index osynligt dataåtkomst: när ett index har byggts bestämmer PostgreSQL-frågeplaneraren automatiskt när den ska användas för att förbättra frågeprestanda. Men det finns vissa situationer där planeraren inte väljer att använda befintliga index, så frågor slutar använda långsamma sekventiella skanningar istället för ett spatialt index.

Om du upptäcker att dina spatiala index inte används finns det några saker du kan göra:

Mer information finns i Postgres-manualens avsnitt om Query Planning.

Enligt OpenGIS Simple Features Implementation Specification for SQL är "det grundläggande tillvägagångssättet för att jämföra två geometrier att göra parvisa tester av skärningarna mellan de två geometriernas inre, yttre och yttre delar och att klassificera förhållandet mellan de två geometrierna baserat på posterna i den resulterande 'skärningsmatrisen'"

I teorin om punktuppsättningstopologi kategoriseras punkterna i en geometri som är inbäddad i ett 2-dimensionellt rum i tre uppsättningar:

DE-9IM ( Dimensionally Extended 9-Intersection Model ) beskriver det spatiala förhållandet mellan två geometrier genom att ange dimensionerna för de 9 skärningspunkterna mellan ovanstående uppsättningar för varje geometri. Dimensionerna på skärningspunkterna kan formellt representeras i en 3x3 skärningsmatris.

För en geometri g betecknas det inre, det yttre och det yttre med beteckningarna I(g), B(g) och E(g). Dim(s) betecknar också dimensionen hos en mängd s med domänen {0,1,2,F}:

Med hjälp av denna notation är intersektionsmatrisen för två geometrier a och b: är:

Visuellt, för två överlappande polygonala geometrier, ser detta ut så här:

	Inredning Begränsning Exteriör Inredning dim( I(a) ∩ I(b) ) = 2 dim( I(a) ∩ B(b) = 1 dim( I(a) ∩ E(b) ) = 2 Begränsning dim( B(a) ∩ I(b) ) = 1 dim( B(a) ∩ B(b) ) = 0 dim( B(a) ∩ E(b) ) = 1 Exteriör dim( E(a) ∩ I(b) ) = 2 dim( E(a) ∩ B(b) ) = 1 dim( E(a) ∩ E(b) = 2

När man läser från vänster till höger och uppifrån och ner representeras skärningsmatrisen av textsträngen '"212101212".'.

För mer information, se:

För att göra det enkelt att fastställa vanliga spatiala relationer definierar OGC SFS en uppsättning namngivna predikat för spatiala relationer. PostGIS tillhandahåller dessa som funktionerna ST_Contains, ST_Crosses, ST_Disjoint, ST_Equals, ST_Intersects, ST_Overlaps, ST_Touches, ST_Within. Det definierar också de icke-standardiserade relationspredikaten ST_Covers, ST_CoveredBy, och ST_ContainsProperly.

Spatiala predikat används vanligtvis som villkor i SQL WHERE- eller JOIN-klausuler. De namngivna spatiala predikaten använder automatiskt ett spatialt index om ett sådant finns tillgängligt, så det finns inget behov av att använda bounding box-operatorn && också. Till exempel:

SELECT city.name, state.name, city.geom
FROM city JOIN state ON ST_Intersects(city.geom, state.geom);

För mer information och illustrationer, se PostGIS Workshop.

I vissa fall är de angivna spatiala relationerna otillräckliga för att ge ett önskat spatialt filtertillstånd.

Tänk till exempel på en linjär dataset som representerar ett vägnät. Det kan vara nödvändigt att identifiera alla vägsegment som korsar varandra, inte vid en punkt utan i en linje (kanske för att validera någon affärsregel). I det här fallet tillhandahåller ST_Crosses inte det nödvändiga spatiala filtret, eftersom det för linjära funktioner endast returnerar sant där de korsas vid en punkt. En tvåstegslösning skulle vara att först beräkna den faktiska skärningspunkten (ST_Intersection) för par av väglinjer som spatialt skär varandra (ST_Intersects), och sedan kontrollera om skärningspunktens ST_GeometryType är"LINESTRING" (för att på ett korrekt sätt hantera fall som ger GEOMETRYCOLLECTIONsav [MULTI]POINTs, [ MULTI]LINESTRINGs, etc.). Det är uppenbart att en enklare och snabbare lösning är önskvärd.

Ett annat exempel är lokalisering av kajer som skär en sjös gräns på en linje och där ena änden av kajen är uppe på stranden. Med andra ord, där en kaj ligger inom men inte helt innesluten av en sjö, skär sjöns gräns på en linje och där exakt en av kajens ändpunkter ligger inom eller på sjöns gräns. Det är möjligt att använda en kombination av spatiala predikat för att hitta de funktioner som krävs: ST_Contains(sjö, kaj) = TRUE ST_ContainsProperly(sjö, kaj) = FALSE ST_GeometryType(ST_Intersection(kaj, sjö)) = "LINESTRING ST_NumGeometries(ST_Multi(ST_Intersection(ST_Boundary(kaj), ST_Boundary(sjö)))) = 1 ... men det behöver inte sägas att detta är ganska komplicerat.

Dessa krav kan uppfyllas genom att beräkna den fullständiga DE-9IM-intersektionsmatrisen. PostGIS tillhandahåller funktionen ST_Relate för att göra detta:

SELECT ST_Relate( 'LINESTRING (1 1, 5 5)',
                  'POLYGON ((3 3, 3 7, 7 7, 7 3, 3 3))' );
st_relate
-----------
1010F0212

För att testa ett visst spatialt förhållande används ett intersektionsmatrismönster. Detta är matrisrepresentationen utökad med tilläggssymbolerna {T,*}:

Med hjälp av intersektionsmatrismönster kan specifika spatiala relationer utvärderas på ett mer kortfattat sätt. Funktionerna ST_Relate och ST_RelateMatch kan användas för att testa intersektionsmatrismönster. I det första exemplet ovan är det matrismönster som anger att två linjer korsar varandra i en linje"1*1***1**":

-- Find road segments that intersect in a line
SELECT a.id
FROM roads a, roads b
WHERE a.id != b.id
      AND a.geom && b.geom
      AND ST_Relate(a.geom, b.geom, '1*1***1**');

I det andra exemplet är mönstret för skärningsmatrisen som anger en linje som delvis ligger innanför och delvis utanför en polygon"102101FF2":

-- Find wharves partly on a lake's shoreline
SELECT a.lake_id, b.wharf_id
FROM lakes a, wharfs b
WHERE a.geom && b.geom
      AND ST_Relate(a.geom, b.geom, '102101FF2');

Nuvarande PostgreSQL-versioner (inklusive 9.6) lider av en svaghet i frågeoptimeraren angående TOAST-tabeller. TOAST-tabeller är ett slags "utökningsrum" som används för att lagra stora (i betydelsen datastorlek) värden som inte passar in på normala datasidor (som långa texter, bilder eller komplexa geometrier med många hörn), se PostgreSQL-dokumentationen för TOAST för mer information).

Problemet uppstår om du råkar ha en tabell med ganska stora geometrier, men inte alltför många rader av dem (som en tabell som innehåller gränserna för alla europeiska länder i hög upplösning). Då är själva tabellen liten, men den använder massor av TOAST-utrymme. I vårt exempel hade tabellen i sig cirka 80 rader och använde bara 3 datasidor, men TOAST-tabellen använde 8225 sidor.

Ställ nu en fråga där du använder geometrioperatorn & & för att söka efter en avgränsningsbox som bara matchar mycket få av dessa rader. Nu ser frågeoptimeraren att tabellen bara har 3 sidor och 80 rader. Den uppskattar att en sekventiell skanning på en så liten tabell är mycket snabbare än att använda ett index. Och så beslutar den att ignorera GIST-indexet. Vanligtvis är denna uppskattning korrekt. Men i vårt fall måste operatorn hämta varje geometri från disken för att jämföra begränsningsrutorna, vilket innebär att alla TOAST-sidor också måste läsas.

För att se om du lider av den här frågan, använd kommandot "EXPLAIN ANALYZE" postgresql. För mer information och de tekniska detaljerna kan du läsa tråden på PostgreSQL-prestandans e-postlista: http://archives.postgresql.org/pgsql-performance/2005-02/msg00030.php

och nyare tråd om PostGIS https://lists.osgeo.org/pipermail/postgis-devel/2017-June/026209.html

PostgreSQL-folket försöker lösa detta problem genom att göra frågeuppskattningen TOAST-medveten. För närvarande är här två lösningar:

Den första lösningen är att tvinga frågeplaneraren att använda indexet. Skicka "SET enable_seqscan TO off;" till servern innan du skickar frågan. Detta tvingar i princip frågeplaneraren att undvika sekventiella skanningar när det är möjligt. Så den använder GIST-indexet som vanligt. Men den här flaggan måste ställas in för varje anslutning, och det gör att frågeplaneraren gör felbedömningar i andra fall, så du bör "SET enable_seqscan TO on;" efter frågan.

Den andra lösningen är att göra den sekventiella skanningen så snabb som frågeplaneraren tror. Detta kan uppnås genom att skapa en extra kolumn som "cachelagrar" bboxen och matchar mot denna. I vårt exempel ser kommandona ut så här:

SELECT AddGeometryColumn('myschema','mytable','bbox','4326','GEOMETRY','2');
UPDATE mytable SET bbox = ST_Envelope(ST_Force2D(geom));

Ändra nu din fråga för att använda operatorn & & mot bbox istället för geom_column, som:

SELECT geom_column
FROM mytable
WHERE bbox && ST_SetSRID('BOX3D(0 0,1 1)'::box3d,4326);

Om du ändrar eller lägger till rader i min tabell måste du naturligtvis hålla bbox "synkroniserad". Det mest transparenta sättet att göra detta skulle vara triggers, men du kan också ändra din applikation för att hålla bbox-kolumnen aktuell eller köra UPDATE-frågan ovan efter varje ändring.