PostGIS 지형 유형 및 함수는 표면(face), 가장자리(edge), 노드(node)와 같은 위상기하학적 객체를 관리했습니다.
Sandro Santilli's presentation at PostGIS Day Paris 2011 conference gives a good synopsis of PostGIS Topology and where it is headed Topology with PostGIS 2.0 slide deck.
Vincent Picavet provides a good synopsis and overview of what is Topology, how is it used, and various FOSS4G tools that support it in PostGIS Topology PGConf EU 2012.
지형에 기반한 GIS 데이터베이스의 예로는 US Census Topologically Integrated Geographic Encoding and Referencing System (TIGER) 데이터베이스가 있습니다. PostGIS 지형 유형을 테스트해보고 싶은데 데이터가 필요하다면, Topology_Load_Tiger 를 확인해보십시오.
PostGIS 지형 모듈은 PostGIS 이전 버전에도 있었지만, 공식 PostGIS 문서에 포함된 적은 없었습니다. PostGIS 2.0.0 버전에서, 지원이 중단된 모든 함수를 제거하고, 알려진 사용성 문제들을 해결하고, 기능 및 함수들을 새로이 문서화하며, 새로운 함수들을 추가하고, SQL-MM 표준을 더 잘 준수하도록 개선하는 등 주요한 정리 작업이 이루어졌습니다.
이 프로젝트에 대한 자세한 내용을 PostGIS Topology Wiki 에서 찾아볼 수 있습니다.
이 모듈과 관련된 모든 함수 및 테이블이 topology
라는 스키마에 설치돼 있습니다.
SQL/MM 표준이 정의하는 함수들은 접두사 ST_ 가 붙은 명칭을 가지고 있으며, PostGIS에 특화된 함수들의 명칭에는 접두사가 붙지 않습니다.
Topology support is build by default starting with PostGIS 2.0, and can be disabled specifying --without-topology configure option at build time as described in Chapter 2, PostGIS 설치
이 단원에서 PostGIS 지형이 설치한 PostgreSQL 데이터 유형을 소개합니다. 사용자 지정 함수를 설계할 때 특히 중요한 이 유형들의 형변환 습성(cast behavior)을 설명한다는 점에 주의하십시오.
ValidateTopology
.
이 단원에서 PostGIS 지형이 설치한 PostgreSQL 도메인을 소개합니다. 함수가 반환하는 유형 또는 테이블 열 등, 도메인을 객체 유형처럼 이용할 수 있습니다. 도메인과 유형의 차이점은, 도메인이 확인 제약조건으로 묶여 있는 기존 유형이라는 점입니다.
이 단원에서 새로운 지형 스키마를 빌드하고, 지형이 유효한지 확인하고, TopoGeometry 열을 관리하기 위한 지형 함수들을 소개합니다.
schema_name
스키마 안의 table_name
명칭의 테이블에서 Topogeometry 열을 삭제하고 topology.layer 테이블에서 해당 열을 등록 해제합니다.
This section discusses management of database statistics during topology building.
Adding elements to a topology triggers many database queries for finding existing edges that will be split, adding nodes and updating edges that will node with the new linework. For this reason it is useful that statistics about the data in the topology tables are up-to-date.
PostGIS Topology population and editing functions do not automatically update the statistics because a updating stats after each and every change in a topology would be overkill, so it is the caller's duty to take care of that.
That the statistics updated by autovacuum will NOT be visible to transactions which started before autovacuum process completed, so long-running transactions will need to run ANALYZE themselves, to use updated statistics. |
이 단원에서 새 지형을 생성하기 위한 지형 함수에 대해 설명합니다.
이 단원에서 경계선, 표면, 노드를 추가하고, 이동하고, 삭제하고, 분할하기 위한 지형 함수에 대해 설명합니다. ISO SQL/MM이 이 단원의 모든 함수를 정의합니다.
anode
와 anothernode
를 연결하는 alinestring
도형이 정의하는 고립된 경계선을 추가하고 새 경계선의 ID를 반환합니다.
apoint
geometry exists as a node an error is thrown. Returns description of move.
aface
의 경계를 이루는 정렬된 경계선들의 집합을 반환합니다.
이 단원에서 비표준적인 방법으로 지형을 공간 처리하기 위한 함수에 대해 설명합니다.
이 단원에서 새 TopoGeometry를 생성하기 위한 지형 함수에 대해 설명합니다.
topoelementarray
for a set of element_id, type arrays (topoelements).
이 단원에서 기존 지형을 편집하기 위한 지형 함수에 대해 설명합니다.
topoelementarray
(an array of topoelements) containing the topological elements and type of the given TopoGeometry (primitive elements).
topoelement
objects containing the topological element_id,element_type of the given TopoGeometry (primitive elements).
이 단원에서 TopoGeometry와 지형 원시형 사이의 관계를 확인하는 데 쓰이는 지형 함수에 대해 설명합니다.
Once you have created topologies, and maybe associated topological layers, you might want to export them into a file-based format for backup or transfer into another database.
Using the standard dump/restore tools of PostgreSQL is problematic because topologies are composed by a set of tables (4 for primitives, an arbitrary number for layers) and records in metadata tables (topology.topology and topology.layer). Additionally, topology identifiers are not univoque across databases so that parameter of your topology will need to be changes upon restoring it.
In order to simplify export/restore of topologies a pair of executables are provided: pgtopo_export
and pgtopo_import
. Example usage:
pgtopo_export dev_db topo1 | pgtopo_import topo1 | psql staging_db
The pgtopo_export
script takes the name of a database and a topology and outputs a dump file which can be used to import the topology (and associated layers) into a new database.
By default pgtopo_export
writes the dump file to the standard output so that it can be piped to pgtopo_import
or redirected to a file (refusing to write to terminal). You can optionally specify an output filename with the -f
commandline switch.
By default pgtopo_export
includes a dump of all layers defined against the given topology. This may be more data than you need, or may be non-working (in case your layer tables have complex dependencies) in which case you can request skipping the layers with the --skip-layers
switch and deal with those separately.
Invoking pgtopo_export
with the --help
(or -h
for short) switch will always print short usage string.
The dump file format is a compressed tar archive of a pgtopo_export
directory containing at least a pgtopo_dump_version
file with format version info. As of version 1
the directory contains tab-delimited CSV files with data of the topology primitive tables (node, edge_data, face, relation), the topology and layer records associated with it and (unless --skip-layers
is given) a custom-format PostgreSQL dump of tables reported as being layers of the given topology.
The pgtopo_import
script takes a pgtopo_export
format topology dump and a name to give to the topology to be created and outputs an SQL script reconstructing the topology and associated layers.
The generated SQL file will contain statements that create a topology with the given name, load primitive data in it, restores and registers all topology layers by properly linking all TopoGeometry values to their correct topology.
By default pgtopo_import
reads the dump from the standard input so that it can be used in conjunction with pgtopo_export
in a pipeline. You can optionally specify an input filename with the -f
commandline switch.
By default pgtopo_import
includes in the output SQL file the code to restore all layers found in the dump.
This may be unwanted or non-working in case your target database already have tables with the same name as the ones in the dump. In that case you can request skipping the layers with the --skip-layers
switch and deal with those separately (or later).
SQL to only load and link layers to a named topology can be generated using the --only-layers
switch. This can be useful to load layers AFTER resolving the naming conflicts or to link layers to a different topology (say a spatially-simplified version of the starting topology).