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 rumsliga 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 skikt med attributen för objekt i ett annat skikt 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 rumsligt aktiverade eller vilken typ av geometri det rör sig om. Sammankopplingen baseras på ett attribut som delas av skikten, i ett ett-till-ett-förhållande.
För att skapa en join på ett lager (identifieras nedan som mållager
):
Klicka på knappen
Lägg till ny länk. Dialogrutan Add vector join visas.
Välj det Join-lager som du vill ansluta till målvektorlagret
Ange Join field (från
join layer
) och Target field (fråntarget layer
). Det är dessa fält som används för att hitta matchande objekt i båda skikten och de bör därför ha gemensamma värden.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ålskiktet 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 skiktet.
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.
|ej markerad| Skapa attributindex på join-fältet för att snabba upp sökningar
|ej markerad| 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ålskiktet ä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 skiktet är redigerbart, men synkroniseringsmekanismerna är inte aktiverade. Om du automatiskt vill lägga till en funktion i det anslutande skiktet när en funktion skapas i målskiktet måste du markera alternativet
Upsert on edit. Symmetriskt kan alternativet
Delete cascade aktiveras om du automatiskt vill ta bort join-funktioner.
|ej markerad| Joined fields: istället för att lägga till alla fält från det sammanfogade lagret kan du ange en delmängd.
|ej markerad| 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 Relations tab. 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.

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 regionskiktet 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
Skikt 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 skikten 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-skiktet 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 Relations och klicka på Add 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 ärID
.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
-skiktet. För detta lager måste du lägga till ett referensfält som pekar på det andra lagret, så det här ärfk_region
.Observera
Ibland behöver du mer än ett enda fält för att unikt identifiera funktioner i ett skikt. För att skapa en relation med ett sådant skikt 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 skikt 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 legenden 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 flygplatsskiktet, även om vi befinner oss i funktionsformatet för en funktion från regionskiktet. 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.
Symbolen |länk| ö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:
Välj den post som tidigare har lagts till i det refererade skiktets funktionsform.
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 Relation Reference 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 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 i flygplatslagret.
Barnskiktet kan också användas i verktyget Välj funktioner efter värde för att välja funktioner i det överordnade skiktet 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``-skiktet och flygbolagstabellen lagrar ``airlines``-skiktet. 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 *locations * behövs inte.
. I GeoPackage finns det inga scheman så prefixetForeign key constraints i tabellen airports_airlines
kan inte skapas med hjälp av eller så de bör skapas med hjälp av . GeoPackage stöder inte ADD CONSTRAINT-satser så tabellen airports_airlines
bör skapas i två steg:
Ställ in tabellen endast med fältet
id
med hjälp avAnvänd
, 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 . 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
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 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 :guilabel:On map identification
(:menuselection:Layer Properties --> 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 skiktet löses genom att använda ett uttryck som måste matcha vissa egenskaper hos det refererade skiktet, t.ex. tabellnamn, skikt-ID, skiktnamn.
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 Relations och klicka på den lilla nedåtpilen bredvid knappen Add Relation, så att du kan välja alternativet Add Polymorphic Relation i den nya rullgardinsmenyn.

Fig. 12.116 Lägga till en polymorf relation med skiktet dokument
som refererande och skikten 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
-skiktet. För detta lager måste du lägga till ett referensfält som pekar på det andra lagret, så detta ärreferenced_id
.Observera
Ibland behöver du mer än ett enda fält för att unikt identifiera funktioner i ett skikt. För att skapa en relation med ett sådant skikt 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 skiktnamnet
@layer_name
, skiktets id@layer_id
, skiktets tabellnamndecode_uri(@layer, 'table')
eller något annat som kan identifiera ett skikt 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)
);