2. Introduktion¶
2.1. Vad är en spatial databas?¶
PostGIS är en spatial databas. Oracle Spatial och SQL Server (2008 och senare) är också spatiala databaser. Men vad innebär det, vad är det som gör en vanlig databas till en spatial databas?
Det korta svaret är…
Spatiala databaser lagrar och manipulerar spatiala objekt som vilket annat objekt som helst i databasen.
I det följande beskrivs kortfattat utvecklingen av spatiala databaser och sedan granskas tre aspekter som associerar spatiala data med en databas - datatyper, index och funktioner.
Spatiala datatyper hänvisar till former som punkt, linje och polygon;
Flerdimensionell spatial indexering används för effektiv bearbetning av spatiala operationer;
Spatial functions, som ingår i SQL, är till för att ställa frågor om spatiala egenskaper och relationer.
Kombinationen av spatiala datatyper, index och funktioner ger en flexibel struktur för optimerad prestanda och analys.
2.1.1. I början¶
I äldre första generationens GIS-implementeringar lagras alla spatiala data i platta filer och det krävs speciell GIS-programvara för att tolka och manipulera data. Dessa första generationens ledningssystem är utformade för att tillgodose användarnas behov där alla nödvändiga data finns inom användarens organisatoriska domän. De är proprietära, fristående system som är speciellt byggda för att hantera spatiala data.
Andra generationens spatiala system lagrar vissa data i relationsdatabaser (vanligtvis ”attribut” eller icke-spatiala delar) men saknar fortfarande den flexibilitet som direkt integration ger.
Äkta spatiala databaser föddes när man började behandla spatiala egenskaper som förstklassiga databasobjekt.
Spatiala databaser integrerar helt spatiala data med en relationsdatabas. Systemets orientering ändras från GIS-centrerat till databascentrerat.
Observera
Ett system för hantering av spatiala databaser kan användas i andra tillämpningar än den geografiska världen. Spatiala databaser används bland annat för att hantera data som rör människokroppens anatomi, storskaliga integrerade kretsar, molekylära strukturer och elektromagnetiska fält.
2.1.2. Typer av spatiala data¶
En vanlig databas har strängar, siffror och datum. En spatial databas lägger till ytterligare (spatiala) typer för att representera geografiska egenskaper. Dessa spatiala datatyper abstraherar och kapslar in spatiala strukturer som gränser och dimensioner. I många avseenden kan spatiala datatyper helt enkelt förstås som former.
Spatiala datatyper är organiserade i en typhierarki. Varje subtyp ärver strukturen (attributen) och beteendet (metoderna eller funktionerna) hos sin supertyp.
2.1.3. Spatiala index och avgränsande boxar¶
En vanlig databas tillhandahåller index för att möjliggöra snabb och slumpmässig åtkomst till delmängder av data. Indexering för standardtyper (tal, strängar, datum) görs vanligtvis med index av typen B-tree.
Ett B-träd delar upp data med hjälp av den naturliga sorteringsordningen för att placera data i ett hierarkiskt träd. Den naturliga sorteringsordningen för tal, strängar och datum är enkel att fastställa - varje värde är mindre än, större än eller lika med alla andra värden.
Men eftersom polygoner kan överlappa varandra, kan vara inneslutna i varandra och är placerade i ett tvådimensionellt (eller mer) utrymme kan ett B-träd inte användas för att effektivt indexera dem. Riktiga spatiala databaser tillhandahåller ett ”spatialt index” som i stället svarar på frågan ”vilka objekt finns inom den här avgränsande rutan?”.
En bounding box är den minsta rektangel - parallell med koordinataxlarna - som kan innehålla en given funktion.
Bounding boxes används eftersom svaret på frågan ”är A inuti B?” är mycket beräkningsintensivt för polygoner men mycket snabbt när det gäller rektanglar. Även de mest komplexa polygonerna och linjestringarna kan representeras av en enkel bounding box.
Index måste fungera snabbt för att vara användbara. Så i stället för att ge exakta resultat, som B-träd gör, ger spatiala index ungefärliga resultat. Frågan ”vilka linjer finns inuti den här polygonen?” tolkas istället av ett spatialt index som ”vilka linjer har begränsningsboxar som finns inuti den här polygonens begränsningsbox?”
De faktiska spatiala index som implementeras av olika databaser varierar mycket. De vanligaste implementationerna är R-Tree och Quadtree (används i PostGIS), men det finns också gridbaserade index och GeoHash-index som implementerats i andra spatiala databaser.
2.1.4. Spatiala funktioner¶
För att manipulera data under en sökning tillhandahåller en vanlig databas funktioner som att sammanfoga strängar, utföra hashoperationer på strängar, göra matematik på siffror och extrahera information från datum.
En spatial databas innehåller en komplett uppsättning funktioner för att analysera geometriska komponenter, fastställa spatiala relationer och manipulera geometrier. Dessa spatiala funktioner fungerar som byggstenar för alla spatiala projekt.
Majoriteten av alla spatiala funktioner kan grupperas i någon av följande fem kategorier:
Konvertering: Funktioner som konverterar mellan geometrier och externa dataformat.
Hantering: Funktioner som hanterar information om spatiala tabeller och PostGIS-administration.
Hämtning: Funktioner som hämtar egenskaper och mått för en Geometri.
Jämförelse: Funktioner som jämför två geometrier med avseende på deras spatiala relation.
Generering: Funktioner som genererar nya geometrier från andra.
Listan över möjliga funktioner är mycket lång, men en gemensam uppsättning funktioner definieras av OGC SFSQL och implementeras (tillsammans med ytterligare användbara funktioner) av PostGIS.
2.2. Vad är PostGIS?¶
PostGIS förvandlar PostgreSQL Database Management System till en spatial databas genom att lägga till stöd för de tre funktionerna: spatiala typer, spatiala index och spatiala funktioner. Eftersom det är byggt på PostgreSQL ärver PostGIS automatiskt viktiga ”företagsfunktioner” såväl som öppna standarder för implementering.
2.2.1. Men vad är PostgreSQL?¶
PostgreSQL är ett kraftfullt system för hantering av relationsdatabaser (RDBMS). Den släpps under en BSD-stillicens och är därmed gratis och öppen källkodsprogramvara. Som med många andra program med öppen källkod kontrolleras PostgreSQL inte av något enda företag, utan har en ”global gemenskap av utvecklare <https://www.postgresql.org/community/contributors/>`_ och företag för att utveckla den.
PostgreSQL designades från början med typförlängning i åtanke - möjligheten att lägga till nya datatyper, funktioner och index vid körning. På grund av detta kan PostGIS-tillägget utvecklas av ett separat utvecklingsteam, men ändå integreras mycket tätt i kärnan i PostgreSQL-databasen.
2.2.1.1. Varför välja PostgreSQL?¶
En vanlig fråga från personer som känner till databaser med öppen källkod är: ”Varför byggdes inte PostGIS på MySQL?”.
PostgreSQL har det:
Beprövad tillförlitlighet och transaktionsintegritet som standard (ACID)
Noggrannt stöd för SQL-standarder (full SQL92)
Pluggbar typförlängning och funktionsförlängning
Modell för samhällsorienterad utveckling
Ingen begränsning av kolumnstorlekar (”TOAST”-duples) för att stödja stora GIS-objekt
Generisk indexstruktur (GiST) för att möjliggöra R-Tree-index
Enkelt att lägga till anpassade funktioner
Kombinerat ger PostgreSQL en mycket enkel utvecklingsväg för att lägga till nya spatiala typer. I den proprietära världen tillät endast Illustra (nu Informix Universal Server) så enkel förlängning. Detta är ingen slump; Illustra är en proprietär omarbetning av den ursprungliga PostgreSQL-kodbasen från 1980-talet.
Eftersom utvecklingsvägen för att lägga till typer till PostgreSQL var så enkel var det vettigt att börja där. När MySQL släppte grundläggande spatiala typer i version 4.1 tog PostGIS-teamet en titt på sin kod, och övningen förstärkte det ursprungliga beslutet att använda PostgreSQL.
Eftersom MySQL:s spatiala objekt måste hackas ovanpå strängtypen som ett specialfall, spreds MySQL-koden över hela kodbasen. Utvecklingen av PostGIS 0.1 tog mindre än en månad. Att göra en ”MyGIS” 0.1 skulle ha tagit mycket längre tid, och som sådan kanske den aldrig hade sett dagens ljus.
2.2.2. Varför inte filer?¶
Shapefile <http://en.wikipedia.org/wiki/Shapefile>`_ (och andra format som Esri File Geodatabase och GeoPackage) har varit ett standardiserat sätt att lagra och interagera med spatiala data sedan GIS-programvaran först skrevs. Dessa ”platta” filer har dock följande nackdelar:
Filerna kräver särskild programvara för att kunna läsas och skrivas. SQL är en abstraktion för slumpmässig dataåtkomst och analys. Utan denna abstraktion måste du själv skriva all kod för åtkomst och analys.
Samtidiga användare kan orsaka skadat data och fördröjningar. Det är visserligen möjligt att skriva extra kod för att säkerställa att flera skrivningar till samma fil inte skadar data, men när du har löst problemet och även löst det därmed sammanhängande prestandaproblemet har du skrivit större delen av ett databassystem. Varför inte bara använda en standarddatabas?
Komplicerade frågor kräver komplicerad programvara för att besvaras. Komplicerade och intressanta frågor (spatial joins, aggregeringar etc) som kan uttryckas i en SQL-rad i databasen kräver hundratals rader specialiserad kod för att besvaras när man programmerar mot filer.
De flesta användare av PostGIS sätter upp system där flera applikationer förväntas komma åt data, så att ha en standard SQL-åtkomstmetod förenklar driftsättning och utveckling. Vissa användare arbetar med stora datamängder; med filer kan de segmenteras i flera filer, men i en databas kan de lagras som en enda stor tabell.
Sammanfattningsvis är det kombinationen av stöd för flera användare, komplexa ad hoc-frågor och prestanda för stora datamängder som gör att spatiala databaser skiljer sig från filbaserade system.
2.2.3. En kort historik över PostGIS¶
I maj 2001 släppte Refractions Research den första versionen av PostGIS. PostGIS 0.1 hade objekt, index och en handfull funktioner. Resultatet var en databas som lämpade sig för lagring och hämtning, men inte för analys.
I takt med att antalet funktioner ökade blev behovet av en organiserande princip tydligt. Specifikationen ”Simple Features for SQL” (SFSQL) från Open Geospatial Consortium gav en sådan struktur med riktlinjer för namngivning av funktioner och krav.
Med PostGIS-stöd för enkel analys och spatiala sammankopplingar blev Mapserver den första externa applikationen som gav visualisering av data i databasen.
Under de följande åren ökade antalet PostGIS-funktioner, men dess kraft var fortfarande begränsad. Många av de mest intressanta funktionerna (t.ex. ST_Intersects(), ST_Buffer(), ST_Union()) var mycket svåra att koda. Att skriva dem från grunden lovade åratal av arbete.
Lyckligtvis kom ett andra projekt, ”Geometry Engine, Open Source” eller GEOS, till. GEOS-biblioteket tillhandahåller de nödvändiga algoritmerna för att implementera SFSQL-specifikationen. Genom att länka in GEOS gav PostGIS fullständigt stöd för SFSQL i version 0.8.
När PostGIS datakapacitet växte dök ett annat problem upp: den representation som användes för att lagra geometri visade sig vara relativt ineffektiv. För små objekt som punkter och korta linjer hade metadata i representationen så mycket som 300% overhead. Av prestandaskäl var det nödvändigt att sätta representationen på diet. Genom att krympa metadatahuvudet och de nödvändiga dimensionerna minskade overhead kraftigt. I PostGIS 1.0 blev denna nya, snabbare, lättviktiga representation standard.
Nya utgåvor av PostGIS fortsätter att lägga till funktioner och prestandaförbättringar, samt stöd för nya funktioner i PostgreSQL-kärnsystemet.
2.2.4. Vem använder PostGIS?¶
För en fullständig lista över fallstudier, se sidan PostGIS fallstudier.
2.2.4.1. Institut Geographique National, Frankrike¶
IGN är Frankrikes nationella kartmyndighet och använder PostGIS för att lagra den högupplösta topografiska kartan över landet, ”BDUni”. BDUni har mer än 100 miljoner objekt och underhålls av över 100 anställda på fältet som dagligen verifierar observationer och lägger till nya kartor i databasen. IGN-installationen använder databasens transaktionssystem för att säkerställa konsekvens under uppdateringsprocesser, och ett ”varmt standbysystem” <https://www.postgresql.org/docs/devel/warm-standby.html>`_ för att upprätthålla drifttiden i händelse av ett systemfel.
2.2.4.2. RedFin¶
RedFin är en fastighetsbyrå med en webbaserad tjänst för att utforska fastigheter och uppskatta värden. Deras system byggdes ursprungligen på MySQL, men de fann att flyttningen till PostgreSQL och PostGIS gav ”stora fördelar i prestanda och tillförlitlighet <https://www.redfin.com/news/elephant_versus_dolphin_which_is_faster_which_is_smarter/>`_.
2.2.5. Vilka applikationer stöder PostGIS?¶
PostGIS har blivit en allmänt använd spatial databas och antalet tredjepartsprogram som stöder lagring och hämtning av data med hjälp av den har också ökat. Programmen som stöder PostGIS <http://trac.osgeo.org/postgis/wiki/UsersWikiToolsSupportPostgis>`_ inkluderar både öppen källkod och egenutvecklad programvara på både server- och skrivbordssystem.
Följande tabell visar en lista över några av de programvaror som utnyttjar PostGIS:
Öppen/fri |
Stängt/Proprietära/betalda tjänster |
|---|---|
|
|
