Kapitel 9. Topologi

Detta exempel bygger topologiytor av nodad linjegeometri och kopplar punktattribut till de resulterande ytorna. Det använder ST_CreateTopoGeo för att fylla en tom topologi, ValidateTopology för att kontrollera resultatet, GetFaceByPoint för att hitta varje attributpunkt och ST_GetFaceGeometry för att materialisera vanliga polygongeometrier.

Skapa en tom topologi och fyll den med linjearbete som omsluter två ytor:

CREATE EXTENSION IF NOT EXISTS postgis_topology;

SELECT topology.CreateTopology('topo_example', 3857);

WITH lines(geom) AS (VALUES
    ('SRID=3857;LINESTRING(0 0, 2 0)'::geometry),
    ('SRID=3857;LINESTRING(0 1, 2 1)'::geometry),
    ('SRID=3857;LINESTRING(0 0, 0 1)'::geometry),
    ('SRID=3857;LINESTRING(1 0, 1 1)'::geometry),
    ('SRID=3857;LINESTRING(2 0, 2 1)'::geometry)
)
SELECT topology.ST_CreateTopoGeo(
    'topo_example',
    ST_Collect(geom)
)
FROM lines;

SELECT * FROM topology.ValidateTopology('topo_example');

Ett tomt resultat från ValidateTopology innebär att inga topologifel hittades. Attributpunkter kan nu matchas mot ytor. En ytid på 0 betecknar den universella ytan, så punkten ligger utanför varje begränsad yta.

WITH labels(name, geom) AS (VALUES
    ('west', 'SRID=3857;POINT(0.5 0.5)'::geometry),
    ('east', 'SRID=3857;POINT(1.5 0.5)'::geometry),
    ('outside', 'SRID=3857;POINT(3 0.5)'::geometry)
),
located AS (
    SELECT name,
           topology.GetFaceByPoint('topo_example', geom, 0) AS face_id
    FROM labels
)
SELECT name,
       face_id,
       CASE WHEN face_id = 0 THEN NULL
            ELSE topology.ST_GetFaceGeometry('topo_example', face_id)
       END AS geom
FROM located
ORDER BY name;

Innan attribut kopieras till en yttabell bör du kontrollera både punkter utanför begränsade ytor och flera källpunkter som tilldelats samma yta:

WITH labels(name, geom) AS (VALUES
    ('west', 'SRID=3857;POINT(0.5 0.5)'::geometry),
    ('east', 'SRID=3857;POINT(1.5 0.5)'::geometry),
    ('outside', 'SRID=3857;POINT(3 0.5)'::geometry)
),
located AS (
    SELECT name,
           topology.GetFaceByPoint('topo_example', geom, 0) AS face_id
    FROM labels
)
SELECT 'outside face' AS problem,
       array_agg(name ORDER BY name) AS labels
FROM located
WHERE face_id = 0
HAVING count(*) > 0
UNION ALL
SELECT 'duplicate face ' || face_id,
       array_agg(name ORDER BY name)
FROM located
WHERE face_id != 0
GROUP BY face_id
HAVING count(*) > 1;

Använd DropTopology för att ta bort exempeltopologin när den inte längre behövs:

SELECT topology.DropTopology('topo_example');

Kärnprimitiverna i varje topologi lagras i tabellerna edge_data, node och face i schemat som skapas av CreateTopology. Varje rad i edge_data representerar en orienterad kant: den registrerar en riktad kurva från start_node till end_node, tillsammans med identifieraren för ytan till vänster om riktningen (left_face) och ytan till höger (right_face). Samma geometriska segment kan därför förekomma två gånger, en gång för varje orientering, när det tillhör två ytor.

Kolumnerna next_left_edge och next_right_edge kompletterar orienteringsinformationen genom att koda hur man fortsätter runt en yta. De lagrar heltal med tecken, vars absolutbelopp är identifieraren för nästa orienterade kant och vars tecken avgör om den lagrade orienteringen ska följas som den är eller omvändas vid traversering. Formellt gäller följande regler för varje kant e:

Denna representation är en variant av en dubbellänkad kantlista och används av många topologirutiner. Funktioner som GetRingEdges och ValidateTopology använder den för att återskapa ytgränser och diagnostisera inkonsekvenser, vilket förklarar diagnoserna ”invalid next_left_edge” och ”invalid next_right_edge” vid validering. Konstruktorer som AddEdge initierar attributen next_* med triviala självreferenser, medan redigeringsrutiner som ST_AddEdgeModFace och ST_RemEdgeModFace uppdaterar länkarna när kanter läggs till eller tas bort. Andra massåtgärder, exempelvis Polygonize, kan avsiktligt lämna fälten oinställda, varför dokumentationen uttryckligen anger detta.

Att lägga till element i en topologi utlöser många databasfrågor för att hitta befintliga kanter som ska delas, lägga till noder och uppdatera kanter som ska knytas till det nya linjeverket. Därför är det bra om statistiken över data i topologitabellerna är uppdaterad.

PostGIS topologipopulation och redigeringsfunktioner uppdaterar inte statistiken automatiskt eftersom det skulle vara onödigt att uppdatera statistiken efter varje ändring i en topologi, så det är uppringarens skyldighet att ta hand om det.

	Att statistiken som uppdateras av autovacuum INTE kommer att vara synlig för transaktioner som startade innan autovacuum-processen slutfördes, så långvariga transaktioner måste köra ANALYZE själva för att använda uppdaterad statistik.

När du har skapat topologier och kanske tillhörande topologiska lager kanske du vill exportera dem till ett filbaserat format för säkerhetskopiering eller överföring till en annan databas.

Att använda standardverktygen för dumpning / återställning av PostgreSQL är problematiskt eftersom topologier består av en uppsättning tabeller (4 för primitiver, ett godtyckligt antal för lager) och poster i metadatatabeller (topology.topology och topology.layer). Dessutom är topologiidentifierare inte univoque över databaser så att parametern för din topologi måste ändras när du återställer den.

För att förenkla export/återställning av topologier tillhandahålls ett par körbara program: pgtopo_export och pgtopo_import. Exempel på användning:

pgtopo_export dev_db topo1 | pgtopo_import topo1 | psql staging_db