PostGIS Topology-typer och -funktioner används för att hantera topologiska objekt som ytor, kanter och noder.
Sandro Santillis presentation på konferensen PostGIS Day Paris 2011 ger en bra sammanfattning av PostGIS Topology och vart det är på väg Topology with PostGIS 2.0 slide deck..
Vincent Picavet ger en bra sammanfattning och översikt över vad Topology är, hur det används och olika FOSS4G-verktyg som stöder det i PostGIS Topology PGConf EU 2012.
Ett exempel på en topologiskt baserad GIS-databas är US Census Topologically Integrated Geographic Encoding and Referencing System (TIGER) -databasen. Om du vill experimentera med PostGIS-topologi och behöver lite data kan du kolla in Topology_Load_Tiger.
The PostGIS topology module has existed for a long time but was not always part of the official documentation. Extensive cleanup removed deprecated functions, fixed known usability issues, documented the features and functions, added new functionality, and improved SQL-MM compliance.
Mer information om detta projekt finns på PostGIS Topology Wiki
Alla funktioner och tabeller som är kopplade till denna modul är installerade i ett schema som kallas topologi.
Funktioner som är definierade i SQL/MM-standarden har prefixet ST_ och funktioner som är specifika för PostGIS har inget prefix.
Topology support is built by default and can be disabled by specifying the --without-topology configure option at build time as described in Chapter 2, Installation av PostGIS
The core primitives of any topology are stored in the edge_data, node, and face tables that live in the schema created by CreateTopology. Each row of edge_data represents an oriented edge: it records a directed curve from start_node to end_node together with the identifier of the face encountered on the left of that direction (left_face) and the face encountered on the right (right_face). The same geometric segment may therefore appear twice—once for each orientation—when it belongs to two faces.
The next_left_edge and next_right_edge columns complete this orientation information by encoding how to keep walking around a face. They store signed integers whose absolute value is the identifier of the next oriented edge and whose sign determines whether the stored orientation has to be followed as-is or reversed when traversing. Formally, the following rules hold for every edge e:
abs(next_left_edge) is the identifier of the edge reached by continuing around the face that lies to the left of e. If the value is positive the walk continues from the end node of e along the stored orientation of the referenced edge; if it is negative the referenced edge must be followed backwards so that the shared face remains on the walker’s left.
abs(next_right_edge) analogously follows the boundary of the face located on the right of e. A positive value means that the next edge is taken with its recorded orientation starting from the end node of e, whereas a negative value instructs to traverse the referenced edge in reverse, starting from its end node, so that the right-hand face is preserved.
A zero value indicates that the edge is dangling on the corresponding side (for example an isolated edge whose incident face is the universal face 0). The abs_next_left_edge and abs_next_right_edge columns exposed by the edge view are convenience projections of these absolute values.
This representation is a variant of a doubly connected edge list and is exploited by many topology routines. Functions such as GetRingEdges and ValidateTopology rely on it to reconstruct face boundaries and to diagnose inconsistencies—hence the “invalid next_left_edge” and “invalid next_right_edge” diagnostics reported during validation. Constructors like AddEdge initialise the next_* attributes with trivial self references, while editing routines including ST_AddEdgeModFace and ST_RemEdgeModFace update the links as edges are inserted or removed. Other bulk operations (for example Polygonize) may intentionally leave the fields unset, which is why the documentation flags their behaviour explicitly.
Detta avsnitt listar PostgreSQL-datatyper installerade av PostGIS Topology. Observera att vi beskriver casting-beteendet för dessa, vilket är mycket viktigt, särskilt när du utformar dina egna funktioner.
ValidateTopology.
Detta avsnitt listar PostgreSQL-domänerna installerade av PostGIS Topology. Domäner kan användas som objekttyper som returobjekt för funktioner eller tabellkolumner. Skillnaden mellan en domän och en typ är att en domän är en befintlig typ med en kontrollbegränsning bunden till den.
I det här avsnittet listas Topology-funktioner för att skapa nya Topology-scheman, validera topologier och hantera TopoGeometry-kolumner
table_name i schema schema_name och avregistrerar kolumnerna från tabellen topology.layer.
I detta avsnitt beskrivs hantering av databasstatistik under topologibyggandet.
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. |
I detta avsnitt beskrivs topologifunktionerna för att skapa nya topologier.
I detta avsnitt beskrivs topologifunktioner för att lägga till, flytta, ta bort och dela kanter, ytor och noder. Alla dessa funktioner definieras av ISO SQL/MM.
alinestring till en topologi som förbinder två befintliga isolerade noder anode och anothernode och returnerar kant-ID för den nya kanten.
apoint-geometrin existerar som en nod kastas ett fel. Returnerar beskrivning av förflyttning.
avgränsar en yta..
I detta avsnitt beskrivs funktionerna för att bearbeta topologier på icke-standardiserade sätt.
I detta avsnitt beskrivs topologifunktionerna för att skapa nya topogeometrier.
Returnerar en topoelementarray för en uppsättning element_id, typ arrayer (topoelements).
I detta avsnitt beskrivs topologifunktionerna för redigering av befintliga topogeometrier.
Returnerar en topoelementarray (en array av topoelements) som innehåller de topologiska elementen och typen för den givna TopoGeometry (primitiva element).
topoelement-objekt som innehåller topologiska element_id,element_type för den givna TopoGeometry (primitiva element).
I detta avsnitt listas de topologifunktioner som används för att kontrollera relationer mellan topogeometrier och topologiprimitiver
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
Skriptet pgtopo_export tar namnet på en databas och en topologi och matar ut en dumpfil som kan användas för att importera topologin (och tillhörande lager) till en ny databas.
Som standard skriver pgtopo_export dumpfilen till standardutdata så att den kan pipas till pgtopo_import eller omdirigeras till en fil (vägrar att skriva till terminalen). Du kan ange ett filnamn för utdata med kommandoradsalternativet -f..
Som standard inkluderar pgtopo_export en dumpning av alla lager som definierats mot den givna topologin. Detta kan vara mer data än du behöver, eller kanske inte fungerar (om dina lagertabeller har komplexa beroenden), i vilket fall du kan begära att lagren hoppas över med omkopplaren --skip-layers och hantera dem separat.
Om pgtopo_export an ropas med kommandot --help (eller -h förkortat) skrivs alltid en kort användningssträng ut.
Dumpfilformatet är ett komprimerat tar-arkiv med en pgtopo_export-katalog som innehåller minst en pgtopo_dump_version-fil med information om formatversion. Från och med version 1 innehåller katalogen tabbavgränsade CSV-filer med data från de primitiva tabellerna för topologi (nod, kantdata, yta, relation), topologi- och lagerposterna som är associerade med den och (om inte --skip-layers ges) en PostgreSQL-dump i anpassat format av tabeller som rapporteras som lager i den givna topologin.
Skriptet pgtopo_import tar en topologidump i pgtopo_export-format och ett namn på den topologi som ska skapas och matar ut ett SQL-skript som rekonstruerar topologin och tillhörande lager.
Den genererade SQL-filen kommer att innehålla satser som skapar en topologi med det angivna namnet, laddar primitiva data i den, återställer och registrerar alla topologilager genom att korrekt länka alla TopoGeometry-värden till deras korrekta topologi.
Som standard läser pgtopo_import dumpningen från standardinmatningen så att den kan användas tillsammans med pgtopo_export i en pipeline. Du kan eventuellt ange ett filnamn för indata med kommandoradsalternativet -f.
Som standard inkluderar pgtopo_import i SQL-filen koden för att återställa alla lager som finns i dumpningen.
Detta kan vara oönskat eller inte fungera om din måldatabas redan har tabeller med samma namn som de i dumpningen. I så fall kan du begära att lagren hoppas över med --skip-layers och hantera dem separat (eller senare).
SQL för att endast läsa in och länka lager till en namngiven topologi kan genereras med hjälp av omkopplaren --only-layers. Detta kan vara användbart för att läsa in lager EFTER att namnkonflikterna har lösts eller för att länka lager till en annan topologi (t.ex. en spatialt förenklad version av starttopologin).
Om måltopologin redan finns och du vill att den ska tas bort i förväg kan du använda kommandot --drop-topology (sedan PostGIS-3.6.0).