33. Topologi och geometri Representation

Innan du läser detta dokument bör du läsa igenom minst en av dessa resurser:

• Grundläggande topologityper

• Introduktiv workshop: PostGIS Topology Workshop

Att ha en topologi med alla dess primitiver är användbart, men för att göra det mer praktiskt behöver vi ett sätt att representera dessa element i en tabell. På samma sätt som vi har spatiala tabeller kan vi ha topologitabeller.

33.1. Introduktion till geometrisk representation

Om du har följt något exempel på användning av topologi för att representera geometrier kan du komma ihåg detta, när vi fyller i en topologitabell från en geometritabell använder vi TopoGeometries istället för geometrier, och på något sätt kan varje TopoGeometry representera en eller flera primitiver som finns i topologin.

Poängen är hur vi når de faktiska primitiverna från TopoGeometry, hur data är strukturerade, så låt oss först se de mest globala definitionerna:

En TopoGeometry kan representera en grupp av Primitives eller andra TopoGeometries, för att skapa en TopoGeometry behöver du en Layer.

Layers är den största lådan, de lagrar TopoGeometries som också lagrar TopoElements, de sista representerar Primitives eller andra TopoGeometries.

Bara för att skriva på två sätt:

• Layer innehåller

  • TopoGeometries där alla har samma typ av TopoElement, var och en innehåller:

    • TopoElement där var och en kan representera en:

      • TopoGeometry för andra Layer

      • Geometry Collection

      • Primitiv från topologin

        • Noder

        • Kanter

        • Faces

TopoGeometries exponeras som nycklar, de har en unik nyckel inuti lagret, men lagrar också sin Layer Key, vilket gör att Postgis kan lagra den i en godtycklig kolumn och alltid kunna hitta dess TopoElements och med dem vad de representerar.

Du behöver ett Layer där en TopoGeometry ska konstrueras, och efter det behöver du inte komma ihåg vilket Layer det tillhör.

Detta koncept är det som används för användaren, från denna punkt kommer vi att förklara djupa och tekniska detaljer.

Som en sidoanteckning har Postgis Topology internt några knep när det gäller nycklar, hjälper till att optimera många delar men samtidigt finns det mycket reduntant information, bli inte förvånad om du hittar samma information på två eller flera ställen.

33.2. Features

TopoElements kan representera en TopoGeometry och en Primitive, tänk i en TopoGeometry, om du lagrar dem i en TopoElement, de innehåller fortfarande andra TopoElements, om vi följer dess väg kommer vi alltid att sluta i Primitives för Topology.

Features representerar vilken typ av geometriuppsättning som ska användas, det är inte viktigt om du använder TopoGeometries eller Primitives, i slutändan kan ett Layer direkt eller indirekt innehålla vilken som helst av dessa uppsättningar:

• 1. Noder

• 2. Kanter

• 3. Faces

• 4. Geometry Collections

Siffrorna är viktiga, i alla funktioner som begär Feature Type kan du ange den med hjälp av siffran eller namnet som sträng.

33.3. Hierarkiska Layers, Childs och Parents

Jag skulle vilja introducera detta koncept senare, men för att förklara konceptet bättre och djupare kommer du att tycka att detta behövs.

Den första aspekten på bilden är en tabell som är uppbyggd med hjälp av Primitives, Layer 1 kommer att ha TopoGeometries där dess TopoElements endast refererar till Primitives i topologin.

Vi definierar förhållandet mellan Layer 1 och Primitives som:

• Layer 1 är överordnat primitiverna

• Primitiver är Childs till Layer 1

Förhållandet mellan Parent och Child handlar om storlek, Childs är små, när vi har en grupp av dem bygger vi en Parent, en större grupp.

Layer 2 har Layer 1 som child, vilket innebär att varje TopoGeometry från detta layer kan göra en referens till en eller flera TopoGeometries från Layer 1.

Detta innebär också att du inte kan välja hälften av en TopoGeometry från Layer 1, att välja hälften av den innebär att du behöver en referens till ett av TopoElements i en TopoGeometry, som i det här fallet tillhör Primitives (dess Child), om du verkligen behöver det, bygg Layer 2 med hjälp av Layer 1 childs (Primitives).

Varje Layer kan bara ha ett Child Layer, vilket innebär att Child och Parent delar samma Topology-schema.

Du kommer att märka att vissa aspekter av Hierarchy kan ändras för att kanske stödja något som halv TopoGeometry eller blanda Layers, men just nu är det inte implementerat.

33.4. Layers

För att lagra TopoGeometries behöver vi ett Layer, på grund av detta när vi skapar en TopoGeometries kolumn skapar vi också ett Layer, det är därför vi använder en speciell funktion för att skapa en kolumn för detta.

Crete TopoGeometry Column

Layers och TopoGeometry-kolumner har en speciell relation, de är länkade, men de är inte samma sak.

Layers har en hel del information som vi måste tillhandahålla för att veta vilken typ av Layer vi vill ha.

Layers har en unik identifierare i varje topologi, denna identifierare kallas layer_id.

• Layers-nyckel: Sammansatt nyckel med [topology_id, layer_id]

• Table route: Schemanamn, tabellnamn och kolumnnamn för att veta var den är länkad.

• Feature Type: Den typ av objekt som lagret ska innehålla.

• Level: Detta värde börjar på 0, om vi konstruerar detta layer med hjälp av ett annat layer kommer det att lägga till 1, så vi vet hur många layers vi har från primitiverna, om värdet är 0 betyder det att lagret är konstruerat med hjälp av primitiver istället för TopoGeometries.

• child_id: Om lagret byggs utan att använda primitiver och med ett annat Layer som bas behöver vi layer-identifieringen (layer_id) för detta layer, men vi behöver inte topology_id eftersom vi redan känner till det från föräldern.

33.5. Relationstabell

Slutligen, det avsnitt som du kanske tittar på, hur Postgis Topology går från en TopoGeometry till vad de innehåller.

Relationens tabellfunktion är att vara bryggan mellan Parent och Childs.

Denna tabell finns i: my_topology.relation.

33.5.1. Nycklar och identifierare som vi känner till nu

Jag kommer att använda ordet ”Identifier” som en unik nyckel i ett visst sammanhang. Till exempel har varje layer ett nummer som identifierare (layer_id), det är unikt i sitt topologiska sammanhang, men räcker inte för att hitta ett layer i en databas.

Medan identifierare fungerar i ett sammanhang är nyckeln det fullständiga sättet att adressera ett element, t.ex. är nyckeln för ett layer två värden [topology_id, layer_id].

Bilden är en bra sammanfattning av hur nycklarna för respektive är uppbyggda.

33.5.1.1. Implicita identifierare på nycklar

Postgis använder i viss utsträckning en implicit logik när man arbetar med Layers och TopoGeometries, eftersom de har ett sammanhang där du inte behöver lagra hela nyckeln för att veta den.

För att visa ett exempel:

TopoGeometry är sammansatt av:

• topology_id

• layer_id

• topogeometry_id

Som vi nämnde tidigare lagras relationstabellen i topologischemat. Denna tabell kommer att innehålla relationen mellan TopoGeometry och TopoElements, för att göra en referens i detta sammanhang, behöver vi topology_id?

Vi kan hoppa över det! När vi är utanför topologischemat behöver vi id för att hitta det, men när vi är inne i det kan vi titta på schemanamnet och hitta dess id i tabellen topology.topology, som har alla topologiers id och namn.

33.5.2. TopoGeometry

TopoGeometry är en sammansatt nyckel med följande element:

• topology_id: topology_id för TopoGeometry-nyckel

• layer_id: layer_id för TopoGeometry-nyckeln

• id: topogeometry_id för TopoGeometry-nyckeln

• type: Funktionstyp som nummer

33.5.3. Grundläggande relationers tabellstruktur

Varje schematopologi kan ha sin egen relationstabell, den kommer att skapas när du skapar din första TopoGeometry, tabellen lagras inuti topologin som custom_topology.relation.

Varje rad i tabellen kallas för en ”Component”, som en komponent i relationerna.

Komponenten sparar par av två saker, en TopoGeometry Key och en TopoElement, kom ihåg att varje TopoElement bara kan representera en Primitive eller TopoGeometry, så för att en TopoGeometry ska kunna representera flera av dem lagrar tabellerna flera rader med samma TopoGeometry Key och olika TopoElements, på detta sätt kan vi bara filtrera i tabellen få alla TopoElements för alla TopoGeometry.

33.5.4. Hitta komponenter i en TopoGeometry

Att hitta vilka komponenter som hör till en TopoGeometry är lite knepigt, eftersom här fungerar de implicita nycklarna.

En komponent har följande element:

• TopoGeometry Key

  • topogeom_id: topogeometry_id från TopoGeometry Key

  • layer_id: layer_id från TopoGeometry-nyckel

• TopoElement

  • element_id

  • element_type

Vi kan se att TopoGeometry Key är ofullständig, vilket beror på att relationens tabell redan tillhör en topologi, så det finns inget behov av att lagra topologiidentifieraren igen.

För att nå från en TopoGeometry till en Component måste vi titta på TopoGeometry.topology_id och söka på topology.topology.id och hämta Topology Name, med det kan vi hitta relationens tabell i deras respektive schema.

33.5.5. Läsning av TopoElement

Den sista delen för att bryta ned TopoGeometry är att kunna tolka TopoElements som är mer komplex än andra nycklar, eftersom dess betydelse kan ändras beroende på vilket Layer den sparas i.

Som vi nämnde tidigare kan en Layer ha två alternativ som Childs, Primitives eller TopoGeometries.

Det första vi behöver veta är vilka barn det använder, för detta måste vi titta på topology.layer.id med hjälp av TopoGeometry Key.layer_id och få `topology.layer.child_id`.

Så fallen beror på child_id:

• Om är NULL:

  • element_id: Primitiv identifierare

  • element_type: Feature number, titta på Features för att veta vilken primitiv tabell du ska titta på.

• Om är inte NULL:

  • element_id: topogeometry_id från en TopoGeometry-nyckel

  • element_type: layer_id från en TopoGeometry-nyckel

Det första fallet är trivialt, titta bara på deras respektive Primitive-tabell och använd identifieraren för att veta vilken primitive det är.

I det andra fallet används TopoElement för att bygga en ny TopoGeometry Key, topology_id är implicit som vi sa, så nyckeln är komplett, för att hitta de nya elementen tittar du igen på relationens tabell men använder de nya nycklarna.