Viktigt

Översättning är en gemenskapsinsats du kan gå med i. Den här sidan är för närvarande översatt till 99.35%.

12.4. Koppla samman och redigera data i olika lager

En av uppgifterna i ett GIS-program är att kunna koppla samman data från olika lager. En sådan koppling kan baseras på det spatiala förhållandet mellan objekten eller på deras gemensamma attribut. QGIS tillhandahåller verktyg för att hantera alla dessa associationer, t.ex:

• Bearbetningsalgoritmer som kan skapa ett nytt lager som ett resultat av anslutningen, nämligen Anslut attribut efter plats, Sammanfoga attribut efter närmaste, Sammanfoga attribut efter fältvärde, …

• SQL-frågor för att skapa ett nytt lager från DB Manager eller som ett virtuellt lager

• Joins-egenskaper eller relationsinställningar som tillfälligt utökar attributen för objekt i ett visst lager med attributen för objekt i ett annat lager baserat på något eller några matchande attribut.

  Joins och relationer är tekniska begrepp som lånats från databaser för att få ut mesta möjliga av data som lagras i tabeller genom att kombinera deras innehåll. Tanken är att funktioner (rader) i olika lager (tabeller) kan associeras med varandra. Antalet rader som matchar varandra kan ha vilket värde som helst (noll, en, många).

12.4.1. Sammanfogning av funktioner mellan två lager

med *Joins* i QGIS kan du associera funktioner i det aktuella lagret med funktioner från ett annat laddat vektorlager. Det spelar ingen roll om de är spatialt aktiverade eller vilken typ av geometri det rör sig om. Sammankopplingen baseras på ett attribut som delas av lagren, i ett ett-till-ett-förhållande.

För att skapa en join på ett lager (identifieras nedan som mållager):

1. Gå till lagret Egenskaper ► Joins fliken

2. Klicka på knappen ^{Lägg till ny länk}. Dialogrutan Add vector join visas.

3. Välj det Join-lager som du vill ansluta till målvektorlagret

4. Ange Join field (från join layer) och Target field (från target layer). Det är dessa fält som används för att hitta matchande objekt i båda lagren och de bör därför ha gemensamma värden.

5. Tryck på OK och en sammanfattning av de valda parametrarna läggs till i Join-panelen.

Fig. 12.105 Anslut en attributtabell till ett befintligt vektorlager

Stegen ovan skapar en join, där ALLA attributen för den första matchande funktionen i join-lagret läggs till i mållagrets funktion. Följande logik används för att para ihop funktioner under en join-process:

• Alla funktioner i mållagret returneras, oavsett om de har en matchning

• Om målfältet innehåller duplicerade värden tilldelas dessa funktioner samma funktion från det gemensamma lagret.

• Om join-fältet innehåller dubbla matchande värden väljs endast den först hämtade funktionen.

Observera

Sammanfogningar i QGIS baseras på matchning av ett enda fält, så för det mesta vill du se till att värdena i de matchande fälten är unika.

QGIS ger några fler alternativ för att justera sammanfogningen:

• Cache join layer in virtual memory: gör att du kan cacha värden i minnet (utan geometrier) från det sammanfogade lagret för att snabba upp sökningar.

• Skapa attributindex på join-fältet för att snabba upp sökningar

• Dynamic form: hjälper till att synkronisera join-fält i farten, enligt Target field. På så sätt uppdateras även begränsningarna för join-fält korrekt. Observera att den är avaktiverad som standard eftersom den kan vara mycket tidskrävande om du har många funktioner eller en mängd olika kopplingar.

• Om mållagret är redigerbart kommer vissa ikoner att visas i attributtabellen bredvid fälten för att informera om deras status:

  • : länklagret är inte konfigurerat för att kunna redigeras. Om du vill kunna redigera join-funktioner från målattributtabellen måste du markera alternativet Editable join layer.

  • : det gemensamma lagret är väl konfigurerat för att vara redigerbart, men dess aktuella status är skrivskyddad.

  • : det sammanfogade lagret är redigerbart, men synkroniseringsmekanismerna är inte aktiverade. Om du automatiskt vill lägga till en funktion i det anslutande lagret när en funktion skapas i mållagret måste du markera alternativet Upsert on edit. Symmetriskt kan alternativet Delete cascade aktiveras om du automatiskt vill ta bort join-funktioner.

• Joined fields: istället för att lägga till alla fält från det sammanfogade lagret kan du ange en delmängd.

• Prefix för anpassat fältnamn för sammanfogade fält, för att undvika namnkollision

12.4.2. Inställning av relationer mellan flera lager

Till skillnad från joins som definierar en en-till-en-länk mellan funktioner i två lager, hjälper relationer dig att skapa sammankopplingar mellan flera funktioner i två eller flera lager. Relationer är alltså inställningar på projektnivå och anges i fliken Projekt ► Egenskaper ► Relationer. Därifrån kan du:

• Lägg till relation vars typ kan vara:

  • en till många-relation

  • många till många-relation

  • polymorfisk relation som du kan lägga till eller redigera med de dedikerade verktygen i rullgardinsmenyn för åtgärder.

  Observera

  Det finns ännu inget enkelt sätt att redigera en icke-polymorf relation när den väl har skapats. Endast namnet kan redigeras med ett dubbelklick. För alla andra parametrar i en sådan relation måste du ta bort den och skapa den på nytt.

• Upptäck relationer: QGIS kan upptäcka befintliga relationer från databasformat som stöds (PostgreSQL, GeoPackage, ESRI File Geodatabase, …). Detta kan vara ett bra sätt att underlätta relationsdefinitionen.

• Ta bort relation

Fig. 12.106 Fliken Relationer

12.4.2.1. En till många (1-N) relationer

Som ett exempel har du ett lager med alla regioner i Alaska (polygon) som ger några attribut om dess namn och regiontyp och ett unikt id (som fungerar som primärnyckel).

Sedan får du ett annat punktlager eller en tabell med information om flygplatser som ligger i regionerna och du vill också hålla reda på dessa. Om du vill lägga till dem i regionlagret måste du skapa en en till många-relation med hjälp av främmande nycklar, eftersom det finns flera flygplatser i de flesta regioner.

Fig. 12.107 Alaska regionen med flygplatser

Lager och nycklar

QGIS gör ingen skillnad mellan en tabell och ett vektorlager. I grund och botten är ett vektorlager en tabell med en geometri. Så du kan lägga till din tabell som ett vektorlager. För att demonstrera 1-n-relationen kan du ladda lagren regions och airports i exempeldatasetet. I praktiken hör varje flygplats till exakt en region medan varje region kan ha ett valfritt antal flygplatser (en typisk en till många-relation).

som har ett främmande nyckelfält (fk_region) till lagerregionerna.

Förutom de attribut som beskriver flygplatserna har aiports-lagret ytterligare ett fält, fk_region, som fungerar som en främmande nyckel (om du har en databas vill du förmodligen definiera en begränsning för det). Fältet fk_region kommer alltid att innehålla ett id för en region. Det kan ses som en pekare till den region som det tillhör.

Allt du behöver göra är att tala om för QGIS relationen mellan lagren så att du kan utforma ett anpassat redigeringsformulär för redigering och QGIS tar hand om installationen. Det fungerar med olika leverantörer (så du kan också använda det med shape- och csv-filer).

Definiera 1-N-relationer

Det första vi ska göra är att berätta för QGIS om relationerna mellan lagren. Detta görs i Projekt ► Egenskaper…. Öppna fliken Relationer och klicka på Lägg till relation.

• Namn kommer att användas som en titel. Det ska vara en mänskligt läsbar sträng som beskriver vad relationen används till. I det här fallet säger vi bara airport_relation.

• Referenced Layer (Parent) betraktas också som överordnat lager, är det med primärnyckeln, pekade på, så här är det regioner-lagret. Du måste definiera den primära nyckeln för det refererade lagret, så det är ID.

• Referencing Layer (Child) betraktas också som barnlager, det är det som har det främmande nyckelfältet på sig. I vårt fall är detta flygplatser-lagret. För detta lager måste du lägga till ett referensfält som pekar på det andra lagret, så det här är fk_region.

  Observera

  Ibland behöver du mer än ett enda fält för att unikt identifiera funktioner i ett lager. För att skapa en relation med ett sådant lager krävs en kompositnyckel, dvs. mer än ett enda par matchande fält. Använd knappen ^{Lägg till nytt fältpar som en del av en sammansatt främmande nyckel} för att lägga till så många par som behövs.

• Id kommer att användas för interna ändamål och måste vara unikt. Du kan behöva det för att bygga custom forms. Om du lämnar det tomt kommer ett att genereras åt dig, men du kan tilldela ett själv för att få ett som är lättare att hantera

• Relationship strength anger styrkan i relationen mellan det överordnade och det underordnade lagret. Standardtypen Association innebär att det överordnade lagret är enkelt länkat till det underordnade medan typen Composition gör att du kan duplicera även de underordnade funktionerna när du duplicerar de överordnade och när du tar bort en funktion tas även de underordnade bort, vilket resulterar i en kaskad över alla nivåer (vilket innebär att barn till barn till… också tas bort).

Fig. 12.108 Lägga till en relation mellan region- och flygplatslager

Från fliken Relations kan du också trycka på knappen Discover Relation för att hämta de relationer som är tillgängliga från leverantörerna av de laddade lagren. Detta är möjligt för lager som lagras i dataleverantörer som PostgreSQL eller SpatiaLite.

Formulär för 1-N-relationer

Nu när QGIS känner till relationen kommer den att användas för att förbättra de formulär som genereras. Eftersom vi inte har ändrat standardmetoden för formuläret (autogenererat) kommer det bara att lägga till en ny widget i vårt formulär. Så låt oss välja lagerregionen i förklaringen och använda identifieringsverktyget. Beroende på dina inställningar kan formuläret öppnas direkt eller så måste du välja att öppna det i identifieringsdialogen under åtgärder.

Fig. 12.109 Identifiering av dialogregioner i förhållande till flygplatser

Som du kan se visas alla flygplatser som tilldelats den här regionen i en tabell. Och det finns också några knappar tillgängliga. Låt oss granska dem kort:

• Knappen är till för att växla redigeringsläge. Tänk på att den växlar redigeringsläget för flygplatslagret, även om vi befinner oss i funktionsformatet för en funktion från regionlagret. Men tabellen representerar funktioner i flygplatslagret.

• Knappen används för att spara alla redigeringar i underordnat lager (flygplats).

• Med knappen kan du digitalisera flygplatsgeometrin i kartbilden och tilldela den nya funktionen till den aktuella regionen som standard. Observera att ikonen kommer att ändras beroende på geometritypen.

• Knappen lägger till en ny post i attributtabellen för flygplatslagret och tilldelar den nya funktionen till den aktuella regionen som standard. Geometrin kan ritas senare med digitaliseringsverktyget Add part.

• Med knappen kan du kopiera och klistra in en eller flera underordnade funktioner i det underordnade lagret. De kan senare tilldelas en annan överordnad funktion eller få sina attribut modifierade.

• Knappen raderar den eller de valda flygplatserna permanent.

• Symbolen öppnar en ny dialogruta där du kan välja en befintlig flygplats som sedan kommer att tilldelas den aktuella regionen. Detta kan vara praktiskt om du råkade skapa flygplatsen i fel region.

• Symbolen kopplar bort den eller de valda flygplatserna från den aktuella regionen och lämnar dem utan tilldelning (främmande nyckel sätts till NULL) i praktiken.

• Med knappen kan du zooma kartan till de valda barnfunktionerna.

• De två knapparna och till höger växlar mellan tabellvy och formulärvy för de relaterade underordnade funktionerna.

Om du använder Drag and Drop Designer för regionfunktionen kan du välja vilka verktyg som ska vara tillgängliga. Du kan även bestämma om ett nytt formulär ska öppnas när en ny funktion läggs till med hjälp av alternativet Force hide form on add feature. Tänk på att detta alternativ innebär att not null-attribut måste ha ett giltigt standardvärde för att fungera korrekt.

Fig. 12.110 Drag and Drop Designer för att konfigurera verktyg för relationer mellan regioner och flygplatser

I exemplet ovan har referenslagret geometrier (så det är inte bara en alfanumerisk tabell) så stegen ovan kommer att skapa en post i lagerattributtabellen som inte har någon motsvarande geometrisk funktion. För att lägga till geometrin:

1. Välj Open Attribute Table för referenslagret.

2. Välj den post som tidigare har lagts till i det refererade lagrets funktionsform.

3. Använd digitaliseringsverktyget ^{Add Part} för att koppla en geometri till den valda attributtabellposten.

Om du arbetar med flygplatstabellen konfigureras widgeten Relation Reference automatiskt för fältet fk_region (det som används för att skapa relationen), se Relation Reference widget.

I flygplatsformuläret ser du knappen till höger om fältet fk_region: om du klickar på knappen öppnas formuläret för regionlagret. Med den här widgeten kan du enkelt och snabbt öppna formulären för de länkade överordnade funktionerna.

Fig. 12.111 Identifieringsdialog flygplats med relation till regioner

Widgeten Relationsreferens har också ett alternativ för att bädda in formuläret för det överordnade lagret i det underordnade. Det finns tillgängligt i menyn Egenskaper ► Attribut Form i flygplatslagret: välj fältet fk_region och markera alternativet Visa inbäddat formulär.

Om du tittar på funktionsdialogen nu kommer du att se att regionformuläret är inbäddat i flygplatsformuläret och till och med har en kombinationsruta som gör att du kan tilldela den aktuella flygplatsen till en annan region.

Om du växlar redigeringsläget för flygplatslagret har fältet fk_region dessutom en autokompletteringsfunktion: när du skriver kommer du att se alla värden i fältet id för regionlagret. Här är det möjligt att digitalisera en polygon för regionlagret med hjälp av knappen om du har valt alternativet Allow adding new features i menyn Egenskaper ► Attributformulär i flygplatslagret.

Barnskiktet kan också användas i verktyget Välj funktioner efter värde för att välja funktioner i det överordnade lagret baserat på attribut för deras barn.

I Fig. 12.112 väljs alla regioner där flygplatsernas medelhöjd är större än 500 meter över havet.

Du kommer att upptäcka att många olika aggregeringsfunktioner finns tillgängliga i formuläret.

Fig. 12.112 Välj föräldrafunktioner med barnvärden

12.4.2.2. Många-till-många-relationer (N-M)

N-M-relationer är många-till-många-relationer mellan två tabeller. Till exempel lagren flygplatser och flygbolag: en flygplats tar emot flera flygbolag och ett flygbolag flyger till flera flygplatser.

Denna SQL-kod skapar de tre tabellerna vi behöver för en N-M-relation i ett PostgreSQL / PostGIS-schema med namnet locations *. Du kan köra koden med hjälp av :menuselection:`Database –> DB Manager…` för PostGIS eller externa verktyg som `pgAdmin <https://www.pgadmin.org>`_. Flygplatstabellen lagrar ``airports``-lagret och flygbolagstabellen lagrar ``airlines``-lagret. I båda tabellerna används få fält för tydlighetens skull. Den * knepiga * delen är tabellen ``airports_airlines``. Vi behöver den för att lista alla flygbolag för alla flygplatser (eller vice versa). Den här typen av tabell kallas för en *pivottabell. Begränsningarna i den här tabellen gör att en flygplats kan associeras med ett flygbolag endast om båda redan finns i sina lager.

CREATE SCHEMA locations;

CREATE TABLE locations.airports
(
   id serial NOT NULL,
   geom geometry(Point, 4326) NOT NULL,
   airport_name text NOT NULL,
   CONSTRAINT airports_pkey PRIMARY KEY (id)
);

CREATE INDEX airports_geom_idx ON locations.airports USING gist (geom);

CREATE TABLE locations.airlines
(
   id serial NOT NULL,
   geom geometry(Point, 4326) NOT NULL,
   airline_name text NOT NULL,
   CONSTRAINT airlines_pkey PRIMARY KEY (id)
);

CREATE INDEX airlines_geom_idx ON locations.airlines USING gist (geom);

CREATE TABLE locations.airports_airlines
(
   id serial NOT NULL,
   airport_fk integer NOT NULL,
   airline_fk integer NOT NULL,
   CONSTRAINT airports_airlines_pkey PRIMARY KEY (id),
   CONSTRAINT airports_airlines_airport_fk_fkey FOREIGN KEY (airport_fk)
      REFERENCES locations.airports (id)
      ON DELETE CASCADE
      ON UPDATE CASCADE
      DEFERRABLE INITIALLY DEFERRED,
   CONSTRAINT airports_airlines_airline_fk_fkey FOREIGN KEY (airline_fk)
      REFERENCES locations.airlines (id)
      ON DELETE CASCADE
      ON UPDATE CASCADE
      DEFERRABLE INITIALLY DEFERRED
 );

Istället för PostgreSQL kan du också använda GeoPackage. I det här fallet kan de tre tabellerna skapas manuellt med hjälp av Databas ► DB Manager…. I GeoPackage finns det inga scheman så prefixet locations behövs inte.

Foreign key constraints i tabellen airports_airlines kan inte skapas med hjälp av Table ► Create Table… eller Table ► Edit Table… så de bör skapas med hjälp av Database ► SQL Window…. GeoPackage stöder inte ADD CONSTRAINT-satser så tabellen airports_airlines bör skapas i två steg:

1. Ställ in tabellen endast med fältet id med hjälp av Tabell ► Skapa tabell…

2. Använd Database ► SQL Window…, skriv och kör denna SQL-kod:

   ALTER TABLE airports_airlines
      ADD COLUMN airport_fk INTEGER
      REFERENCES airports (id)
      ON DELETE CASCADE
      ON UPDATE CASCADE
      DEFERRABLE INITIALLY DEFERRED;
   
   ALTER TABLE airports_airlines
      ADD COLUMN airline_fk INTEGER
      REFERENCES airlines (id)
      ON DELETE CASCADE
      ON UPDATE CASCADE
      DEFERRABLE INITIALLY DEFERRED;
   

I QGIS ska du sedan ställa in två one-to-many-relationer enligt förklaringen ovan:

• en relation mellan airlines tabellen och pivottabellen;

• och en andra mellan airports tabellen och pivottabellen.

Ett enklare sätt att göra det (endast för PostgreSQL) är att använda Discover Relations i Projekt ► Egenskaper ► Relations. QGIS kommer automatiskt att läsa alla relationer i din databas och du behöver bara välja de två du behöver. Kom ihåg att först ladda in de tre tabellerna i QGIS-projektet.

Fig. 12.113 Relationer och autodiscover

Om du vill ta bort en ”flygplats” eller ett ”flygbolag” kommer QGIS inte att ta bort de tillhörande posterna i tabellen ”airports_airlines”. Denna uppgift kommer att utföras av databasen om vi anger rätt begränsningar i skapandet av pivottabellen som i det aktuella exemplet.

Observera

Kombinera N-M-relation med automatisk transaktionsgrupp

Du bör aktivera transaktionsläget i Projektegenskaper ► Datakällor ► när du arbetar med en sådan kontext. QGIS bör kunna lägga till eller uppdatera rad(ar) i alla tabeller (flygbolag, flygplatser och pivottabeller).

Slutligen måste vi välja rätt kardinalitet i Lageregenskaper ► Attributes Form för lagren airports och airlines. För det första bör vi välja alternativet airlines (id) och för det andra alternativet airports (id).

Fig. 12.114 Ange kardinalitet för relation

Nu kan du koppla ihop en flygplats med ett flygbolag (eller ett flygbolag med en flygplats) med hjälp av Add child feature eller Link existing child feature i underformulären. En post kommer automatiskt att infogas i tabellen airports_airlines.

Fig. 12.115 N-M-förhållande mellan flygplatser och flygbolag

Observera

Använda Många till en relation kardinalitet

Ibland är det inte önskvärt att dölja pivottabellen i en N-M-relation. Främst för att det finns attribut i relationen som bara kan ha värden när en relation är etablerad. Om dina tabeller har ett geometrifält kan det vara intressant att aktivera alternativet On map identification (Lageregenskaper ► Attributes Form ► Available widgets ► Fields) för fälten med främmande nycklar i pivottabellen.

Observera

Pivottabellens primärnyckel

Undvik att använda flera fält i den primära nyckeln i en pivottabell. QGIS förutsätter en enda primärnyckel, så en begränsning som constraint airports_airlines_pkey primary key (airport_fk, airline_fk) fungerar inte.

12.4.2.3. Polymorfa relationer

Syftet med

Polymorfa relationer är ett specialfall av 1-N-relationer, där ett enda refererande (dokument)lager innehåller egenskaper för flera refererade lager. Detta skiljer sig från normala relationer som kräver olika referenslager för varje refererat lager. Ett enda referenslager (dokumentlager) uppnås genom att lägga till en extra kolumn ”layer_field” i referenslagret (dokumentlagret) som lagrar information för att identifiera det refererade lagret. I sin enklaste form kommer det refererande lagret (dokumentlagret) bara att infoga lagernamnet för det refererade lagret i detta fält.

För att vara mer exakt är en polymorf relation en uppsättning normala relationer som har samma referenslager men där det refererade lagret definieras dynamiskt. Den polymorfa inställningen av lagret löses genom att använda ett uttryck som måste matcha vissa egenskaper hos det refererade lagret, t.ex. tabellnamn, lager-ID, lagernamn.

Tänk dig att vi går till parken och vill ta bilder av olika arter av ”växter” och ”djur” som vi ser där. Varje växt eller djur har flera bilder associerade med sig, så om vi använder de normala 1:N-relationerna för att lagra bilder skulle vi behöva två separata tabeller, animal_images och plant_images. Detta kanske inte är ett problem för 2 tabeller, men tänk om vi vill ta separata bilder för svampar, fåglar etc.

Polymorfiska relationer löser detta problem eftersom alla refererande funktioner lagras i samma tabell documents. För varje funktion lagras det refererade lagret i fältet referenced_layer och den refererade funktionens id i fältet referenced_id.

Definiera polymorfa relationer

Låt först QGIS veta om de polymorfa relationerna mellan lagren. Detta görs i Projekt ► Egenskaper…. Öppna fliken Relationer och klicka på den lilla nedåtpilen bredvid knappen Lägg till relation, så att du kan välja alternativet Lägg till polymorfisk relation i den nya rullgardinsmenyn.

Fig. 12.116 Lägga till en polymorf relation med lagret dokument som refererande och lagren djur och växter som refererande.

• Id kommer att användas för interna ändamål och måste vara unikt. Du kan behöva det för att bygga custom forms. Om du lämnar det tomt kommer ett att genereras åt dig, men du kan tilldela ett själv för att få ett som är lättare att hantera

• Referencing Layer (Child) betraktas också som barnlager och är det lager som innehåller fältet med främmande nyckel. I vårt fall är detta documents-lagret. För detta lager måste du lägga till ett referensfält som pekar på det andra lagret, så detta är referenced_id.

  Observera

  Ibland behöver du mer än ett enda fält för att unikt identifiera funktioner i ett lager. För att skapa en relation med ett sådant lager krävs en kompositnyckel, dvs. mer än ett enda par matchande fält. Använd knappen ^{Lägg till nytt fältpar som en del av en sammansatt främmande nyckel} för att lägga till så många par som behövs.

• Lagerfält är det fält i referenstabellen som lagrar resultatet av det utvärderade lageruttrycket, vilket är den referenstabell som den här funktionen tillhör. I vårt exempel skulle detta vara fältet referenced_layer.

• Layer expression utvärderas till en unik identifierare för lagret. Detta kan vara lagernamnet @layer_name, lagrets id @layer_id, lagrets tabellnamn decode_uri(@layer, 'table') eller något annat som kan identifiera ett lager på ett unikt sätt.

• Relationship strength anger styrkan i de genererade relationerna mellan det överordnade och det underordnade lagret. Standardtypen Association innebär att det överordnade lagret är enkelt länkat till det underordnade medan typen Composition gör att du kan duplicera även de underordnade funktionerna när du duplicerar de överordnade och när du tar bort en funktion tas även de underordnade bort, vilket resulterar i en kaskad över alla nivåer (vilket innebär att barn till barn till… också tas bort).

• ** Refererade lager ** betraktas också som föräldralager, är de med den primära nyckeln, pekade på, så här skulle de vara `` växter `` och `` djur `` lager. Du måste definiera den primära nyckeln för de refererade lagren från rullgardinsmenyn, så det är fid. Observera att definitionen av en giltig primärnyckel kräver att alla refererade lager har ett fält med det namnet. Om det inte finns något sådant fält kan du inte spara en polymorf relation.

När den polymorfa relationen har lagts till kan den redigeras via menyalternativet Edit Polymorphic Relation.

Fig. 12.117 Förhandsgranskning av den nyskapade polymorfa relationen och dess underordnade relationer för djur och växter.

I exemplet ovan används följande databasschema:

CREATE SCHEMA park;

CREATE TABLE park.animals
(
   fid serial NOT NULL,
   geom geometry(Point, 4326) NOT NULL,
   animal_species text NOT NULL,
   CONSTRAINT animals_pkey PRIMARY KEY (fid)
);

CREATE INDEX animals_geom_idx ON park.animals USING gist (geom);

CREATE TABLE park.plants
(
   fid serial NOT NULL,
   geom geometry(Point, 4326) NOT NULL,
   plant_species text NOT NULL,
   CONSTRAINT plants_pkey PRIMARY KEY (fid)
);

CREATE INDEX plants_geom_idx ON park.plants USING gist (geom);

CREATE TABLE park.documents
(
   fid serial NOT NULL,
   referenced_layer text NOT NULL,
   referenced_id integer NOT NULL,
   image_filename text NOT NULL,
   CONSTRAINT documents_pkey PRIMARY KEY (fid)
);