본 장에서는 PostGIS의 근본적인 맥락을 정립하고, 그 성공이 PostgreSQL과의 공생 관계 및 강력한 오픈소스 지리 공간 스택의 전략적 통합의 직접적인 결과임을 논증한다.
지리 정보 시스템(GIS)의 초기 단계는 셰이프파일(Shapefile)과 같은 파일 기반 저장 방식이 지배적이었다.1 그러나 이러한 방식은 현대적인 데이터 관리 요구사항을 충족시키기에 여러 가지 본질적인 한계를 드러냈다. 첫째, 셰이프파일과 같은 형식은 데이터를 읽고 쓰기 위해 전용 소프트웨어가 필요하며, 이는 데이터 접근성에 장벽으로 작용했다.2 둘째, 동시 다중 사용자 환경을 제대로 지원하지 못해 데이터 손상 위험이 높았고, 여러 사용자가 동시에 데이터를 수정하는 협업 환경에 부적합했다.2 셋째, 복잡한 공간 질의, 특히 대용량 데이터셋 간의 공간 조인(spatial join)과 같은 연산은 극도로 비효율적이었다. 예를 들어, 10GB 크기의 셰이프파일 두 개를 조인하는 작업은 수 분에서 수 시간이 소요될 수 있지만, 잘 설계된 공간 데이터베이스에서는 동일한 작업을 수 분 내에 완료할 수 있다.3 또한 셰이프파일은 2GB의 파일 크기 제한과 11자로 제한되는 필드명 길이 등 기술적인 제약도 명확했다.3
이러한 한계는 자연스럽게 관계형 데이터베이스 관리 시스템(RDBMS)이 제공하는 표준 SQL 접근, 트랜잭션 무결성(ACID), 보안, 다중 사용자 지원, 그리고 규모에 따른 성능 보장과 같은 특징들에 대한 요구로 이어졌다.2 PostGIS는 바로 이 간극을 메우기 위해 탄생했으며, 대용량의 지리 정보를 안전하고 효율적으로 저장 및 접근할 수 있는 표준화된 방법을 제공하는 것을 목표로 했다.5
PostGIS는 2001년 캐나다의 리프랙션스 리서치(Refractions Research)사에 의해 처음 구상되었으며, 데이브 블래스비(Dave Blasby)와 폴 램지(Paul Ramsey)와 같은 핵심 인물들이 프로젝트를 주도했다.1 이 프로젝트는 학술적 연구가 아닌, 변화가 잦은 공간 데이터를 버전 관리형 데이터베이스에서 효율적으로 관리하고자 했던 고객의 실질적인 요구에서 출발했다.1 PostGIS는 OSGeo(Open Source Geospatial Foundation) 재단의 육성 프로젝트 중 하나로, 이는 프로젝트의 개발 방향이 커뮤니티 주도적으로 이루어지고 개방형 표준을 지향함을 보장하는 중요한 배경이 된다.7 개발팀은 레지나 오베(Regina Obe), 산드로 산틸리(Sandro Santilli) 등 저명한 전문가들을 포함한 핵심 기여자들과 전 세계의 수많은 개발자들로 구성된 역동적인 커뮤니티에 의해 운영된다.7
이러한 탄생 배경은 PostGIS가 이론적 탐구가 아닌 현실 세계의 문제 해결을 위한 실용적인 도구로서의 정체성을 갖게 했음을 시사한다. OSGeo의 지원 아래 FOSS4G(Free and Open Source Software for Geospatial) 운동의 핵심적인 부분으로 자리 잡음으로써, PostGIS는 지속 가능하고 개방적인 발전을 거듭해왔다.
PostGIS는 PostgreSQL의 외부 확장 기능(external extension)으로 구현된다.8 이는 PostgreSQL이 설계 초기부터 강력한 확장성을 염두에 두고 개발되었기 때문에 가능한 일이다. PostgreSQL은 런타임에 새로운 사용자 정의 데이터 타입(예: geometry), 함수, 연산자, 그리고 인덱스 메소드를 추가할 수 있는 기능을 제공한다.2 PostGIS는 특정 PostgreSQL 버전에 대한 의존성을 가지며, 새로운 PostgreSQL 릴리스에 맞춰 함께 발전한다.8 데이터베이스에서 PostGIS를 활성화하는 것은 CREATE EXTENSION postgis;라는 간단한 SQL 명령 한 줄로 충분하다.16
이러한 PostgreSQL과의 관계는 PostGIS 성공의 가장 핵심적인 기반이다. PostGIS는 데이터베이스의 근본적인 기능을 재발명하는 대신, 이미 세계 최고 수준으로 인정받는 RDBMS를 기반으로 그 기능을 공간적으로 확장하는 전략을 택했다. 이를 통해 PostGIS는 PostgreSQL의 핵심 강점들을 자연스럽게 상속받았다.
이러한 긴밀한 관계는 PostGIS가 단순한 ‘추가 기능’을 넘어, PostgreSQL의 아키텍처적 우월성을 증명하는 사례임을 보여준다. 초기 개발 당시 많이 제기되었던 “왜 MySQL 기반으로 만들지 않았는가?”라는 질문에 대한 답은 명확하다.2 PostgreSQL이 사용자 정의 타입, 함수, 그리고 결정적으로 GiST 인덱스 프레임워크와 같은 핵심적인 확장성 기능에서 월등했기 때문이다.2 따라서 PostGIS의 존재와 성공은 PostgreSQL 개발자들이 가졌던 확장성에 대한 설계 철학의 선견지명을 입증하는 ‘킬러 앱(killer app)’이라고 할 수 있다. 이 공생 관계 덕분에 PostgreSQL의 성능이 향상되고 새로운 기능(예: 병렬 처리 강화)이 추가될 때마다 PostGIS는 그 혜택을 직접적으로 누리게 되며, 이는 강력한 전략적 이점으로 작용한다.
PostGIS는 단일체(monolith)가 아니다. 그 기능은 여러 강력한 오픈소스 라이브러리들의 기반 위에 구축되어 있다.8
ST_Intersects, ST_Buffer, ST_Union과 같은 핵심적인 2D 계산 기하학 알고리즘을 제공한다.21 PostGIS 개발은 새로운 GEOS 기능을 통합하기 위해 릴리스 주기를 긴밀하게 맞춘다.23ST_Transform)을 처리하는 필수 라이브러리다.21이러한 구조는 PostGIS가 단순한 공간 데이터베이스를 넘어, 분산된 FOSS4G 스택에 대한 통합된 SQL 인터페이스 역할을 수행함을 의미한다. PostGIS의 핵심적인 아키텍처 역할은 이처럼 각 분야에서 최고로 인정받는 라이브러리들을 통합하고, 그들의 강력한 기능을 보편적으로 이해되는 단일 언어인 SQL을 통해 노출시키는 것이다. 이로 인해 개발자나 분석가는 GEOS의 C++ API나 PROJ의 커맨드 라인 인터페이스를 직접 배울 필요 없이, SQL만으로 전체 생태계의 결합된 힘을 활용할 수 있다. 이는 강력한 지리 공간 분석의 진입 장벽을 극적으로 낮추는 효과를 가져왔으며, PostGIS가 널리 채택된 핵심적인 이유 중 하나이다. 또한, GEOS의 ‘Overlay NG’ 엔진과 같은 기반 라이브러리의 혁신은 PostGIS의 기능에 즉각적으로 상속되어, 그 능력에 강력한 복리 효과를 창출한다.22
본 장에서는 PostGIS가 현실 세계의 지리 정보를 어떻게 구조화되고 질의 가능한 데이터 모델로 변환하는지 상세히 설명하며, 특히 평면 모델과 구체 모델의 결정적인 차이점을 강조한다.
PostGIS는 OGC(Open Geospatial Consortium)의 SFS(Simple Features for SQL) 명세를 충실히 따른다.10 이 표준은 기본적인 지오메트리 타입과 연산을 정의하며, PostGIS는 SFS 명세의 모든 객체와 함수를 지원할 뿐만 아니라, 3D(Z-값) 및 측정값(M-값) 차원을 지원하도록 확장했다.28
OGC 표준을 준수하는 것은 단순한 기술적 선택이 아닌 전략적 결정이다. 이는 PostGIS에 저장된 데이터가 QGIS와 같은 데스크톱 클라이언트나 GeoServer와 같은 웹 서버 등 OGC 표준을 따르는 방대한 GIS 소프트웨어 생태계와 원활하게 호환됨을 보장한다.15 이는 특정 벤더에 대한 종속성을 방지하고, PostGIS가 다중 컴포넌트로 구성된 지리 공간 아키텍처에서 신뢰할 수 있는 허브 역할을 수행하게 한다.
PostGIS는 두 가지 주요 공간 데이터 타입을 제공한다: geometry와 geography.32 이 둘 사이의 선택은 성능과 정확성 사이의 트레이드오프를 포함하는 근본적인 아키텍처 결정이다.
geometry 타입: 데이터를 평면(유클리드, 데카르트) 좌표계 상에서 표현한다. 연산 속도는 빠르지만, 지구의 곡률로 인해 넓은 지역에 걸쳐 정확도가 저하될 수 있다. ST_Area나 ST_Length와 같은 함수의 결과 단위는 해당 공간 참조 시스템(SRS)의 단위를 따른다(예: 도, 미터, 피트).32 geography 타입보다 훨씬 더 넓은 범위의 함수를 지원한다.32
geography 타입: 데이터를 구체(spheroid) 모델, 주로 WGS84(SRID 4326) 좌표계 상에서 표현한다.32 계산은 더 복잡하고 느리지만, 전 지구적 데이터셋에 대해 매우 높은 정확도를 보장한다. 거리나 면적과 같은 측정 함수는 각각 미터(m)와 제곱미터(m2) 단위로 결과를 반환하여 현실 세계의 측정값과 직관적으로 일치한다.33 사용 가능한 함수 집합은 geometry 타입에 비해 제한적이다.32
분석 결과, 특정 도시나 주(state)와 같이 지역화된 데이터에 대해서는 적절한 투영법을 사용하여 왜곡을 최소화할 수 있으므로, 속도와 폭넓은 함수 지원을 위해 geometry 타입을 사용하는 것이 종종 더 나은 선택이다.32 반면, 전 지구적이거나 대륙 규모의 데이터를 다루거나, 미터 단위의 정확한 실세계 측정이 무엇보다 중요한 경우에는 평면 계산으로 인한 심각한 오류를 피하기 위해 geography 타입이 필수적이다.34
geometry와 geography 타입의 존재는 단순한 중복이 아니라, 서로 다른 사용자 요구에 대한 성숙한 이해를 반영한다. geometry 타입은 OGC 표준에 기반한 순수한 수학적 구현으로, 사용자에게 투영법과 그 왜곡에 대한 전문 지식을 요구한다. 위경도 좌표계에서 “제곱도(square degrees)” 단위로 면적을 계산하는 것은 대부분의 사용자에게 의미가 없다.34 반면 geography 타입은 이러한 복잡성을 추상화한다. 모델을 구체로, 출력 단위를 미터로 고정함으로써, GIS 전문가가 아닌 개발자나 분석가에게도 즉각적으로 직관적이고 정확한 실세계 의미를 갖는 답을 제공한다. “반경 5km 이내의 모든 상점 찾기”와 같은 일반적인 활용 사례에서 이는 매우 유용하다. 이 편의성과 정확성을 위해 성능 저하라는 명시적인 트레이드오프가 발생한다.32 따라서 두 타입의 공존은 GIS 전문가(자신만의 투영법을 관리하는)와 애플리케이션 개발자(깊은 지도학적 지식 없이 전 지구적으로 정확한 답을 필요로 하는)의 서로 다른 요구를 모두 충족시키기 위한 설계의 결과물이다.
| 기능 | geometry 타입 |
geography 타입 |
|---|---|---|
| 모델 | 평면 / 데카르트 (유클리드) | 구체 / 회전타원체 (측지) |
| 좌표계 | 모든 투영 또는 지리 좌표계 | 경도/위도 기반 좌표계 (예: WGS84, SRID 4326) |
| 측정 단위 | 공간 참조 시스템(SRS)의 단위 (예: 도, 미터, 피트) | 미터(m) |
| 성능 | 단순한 계산으로 인해 일반적으로 더 빠름 | 복잡한 구면/회전타원체 수학으로 인해 더 느림 |
| 함수 지원 | 수백 개의 매우 광범위한 함수 지원 | 더 제한된 함수 집합 |
| 주요 사용 사례 | 지역적 분석 (도시, 주 단위)에서 적절한 투영법으로 왜곡을 최소화할 수 있는 경우 | 전 지구적 또는 대륙 규모의 분석, 높은 정확도의 거리/면적 계산이 필수적인 애플리케이션 |
PostGIS는 OGC 표준을 준수하는 풍부한 벡터 지오메트리 타입 계층을 지원한다. 여기에는 기본 타입인 POINT, LINESTRING, POLYGON과 이들의 집합 형태인 MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, 그리고 이종의 지오메트리를 담을 수 있는 GEOMETRYCOLLECTION이 포함된다.27 또한 CIRCULARSTRING, COMPOUNDCURVE, TRIANGLE, TIN, POLYHEDRALSURFACE와 같은 특수 타입도 지원하여 더욱 정교한 모델링이 가능하다.27
이러한 지오메트리들은 입출력을 위해 여러 표준 형식으로 표현될 수 있다.
POINT(0 0).28SRID=4326;POINT(-44.3 60.1).29ST_AsGeoJSON, ST_AsGML, ST_AsKML과 같은 함수를 통해 GeoJSON, GML, KML 등 널리 사용되는 웹 및 GIS 형식으로의 변환을 직접 지원한다.40이처럼 포괄적인 지오메트리 타입 지원은 거의 모든 현실 세계의 피처를 정확하게 모델링할 수 있게 해준다. 특히 GeoJSON을 직접 지원하는 ST_AsGeoJSON과 같은 다양한 입출력 형식 지원은 현대 웹 매핑 애플리케이션 개발에 매우 중요하다. 이는 데이터베이스가 최소한의 미들웨어만으로 Leaflet이나 Mapbox GL JS와 같은 프론트엔드 자바스크립트 라이브러리에 데이터를 직접 제공할 수 있게 해주기 때문이다.42
본 장에서는 공간 인덱싱의 원리를 파헤치고, PostGIS가 PostgreSQL의 확장 가능한 GiST 프레임워크 위에 R-Tree 로직을 구현함으로써 어떻게 대용량 데이터셋에 대한 고성능 질의를 달성하는지 설명한다.
단일 축을 따라 정렬 가능한 데이터에 효과적인 표준 B-Tree 인덱스는 다차원 공간 데이터에는 부적합하다.2 공간 인덱스는 R-Tree(Rectangle-Tree) 구조를 사용하는데, 이는 지리적 객체들을 최소 경계 사각형(Minimum Bounding Rectangle, MBR)으로 감싸고 이를 계층적인 트리 구조로 구성하는 방식이다.44 이러한 중첩된 사각형들의 계층 구조는 효율적인 검색을 가능하게 한다.47
핵심 개념은 ‘근사(approximation)’이다. 인덱스는 복잡한 폴리곤 자체를 직접 비교하는 대신, 먼저 그 폴리곤을 감싸는 단순한 직사각형 형태의 MBR을 사용하여 매우 빠른 비교를 수행한다.46 이를 통해 데이터베이스는 질의와 관련 없는 대다수의 객체들을 매우 신속하게 후보군에서 제외할 수 있다.
PostGIS는 PostgreSQL의 GiST(Generalized Search Tree) 프레임워크를 사용하여 R-Tree 인덱스를 구현한다.8 SQL 구문은 CREATE INDEX... USING GIST (geom_column); 형식을 따른다.46 초기 PostGIS 버전은 PostgreSQL의 네이티브 R-Tree 구현을 사용했지만, 이는 곧 폐기되었다.19
네이티브 R-Tree는 8KB보다 큰 지오메트리를 처리할 수 없고, NULL 값을 포함한 컬럼에 인덱스를 생성할 수 없는 ‘null-safe’하지 않은 치명적인 한계를 가지고 있었다.19 더 일반적인 프레임워크인 GiST는 이러한 문제들을 극복하게 해주었다. GiST는 ‘손실 있는(lossy)’ 인덱스로, 인덱스 자체에는 전체 지오메트리 대신 그 MBR을 프록시로 저장한다.19
네이티브 R-Tree의 한계는 실제 GIS 데이터(크고 복잡한 폴리곤과 null 값을 자주 포함하는)를 다루는 데 있어 결정적인 장애물이었다. PostGIS 개발팀이 더 유연한 GiST 프레임워크 기반의 R-Tree 구현으로 전환한 것은 단순한 기술적 변경이 아니었다. 이는 PostGIS가 대규모의 복잡하고 정제되지 않은 실제 데이터를 처리할 수 있는 능력을 갖추게 된 핵심적인 전환점이었다. 이 결정이 없었다면 PostGIS는 상용 제품과 경쟁하거나 기업 규모의 데이터를 관리할 수 없는 틈새 도구로 남았을 것이다. 따라서 GiST의 채택은 PostGIS가 강력하고 안정적인 프로덕션급 공간 데이터베이스로 나아가는 길을 연 전략적 분기점이었다.
ST_Intersects와 같은 공간 질의가 실행될 때, PostgreSQL 질의 계획기는 지능적으로 GiST 인덱스를 활용한다.19 이 과정은 일반적으로 두 단계로 이루어진다.
&& 연산자를 통해 수행된다.19ST_Intersects)를 실행하여 정확한 공간 관계를 판별한다.19이 2단계 접근 방식이 PostGIS 성능의 비결이다. 빠르지만 근사적인 인덱스 스캔이, 느리지만 정확한 기하학적 계산을 수행해야 하는 객체의 수를 극적으로 줄여준다.44
ST_Intersects, ST_Contains, ST_DWithin과 같은 많은 함수들은 이 인덱스 검사를 자동으로 포함한다.55 그러나 개발자는 ST_Distance와 같은 일부 함수는 그 자체로는 인덱스를 사용하지 않는다는 점을 인지하는 것이 중요하다. 이러한 경우, 성능을 확보하기 위해서는 ST_DWithin과 같이 인덱스를 활용하는 함수를 사용하여 질의를 구조화해야 한다.56
본 장에서는 PostGIS의 핵심 분석 도구킷에 대한 실용적인 가이드를 제공하며, SQL이 어떻게 지리 공간적 탐구를 위한 강력한 언어로 확장되는지를 보여준다.
PostGIS는 공간적 관계를 테스트하기 위한 OGC 표준의 불리언(boolean) 함수들을 제공한다.
ST_Intersects: 가장 일반적으로 사용되는 술어(predicate)로, 지오메트리들이 공간을 일부라도 공유하면 참(true)을 반환한다.55
WHERE 절이나 JOIN ON 절에서 빈번하게 사용된다.50
ST_Contains / ST_Within: 완전한 포함 관계를 테스트한다. ST_Contains(A,B)는 ST_Within(B,A)의 역관계이다.58 경계(boundary)에 대한 미묘한 차이가 존재하며,
ST_Covers는 경계를 포함하는 더 포괄적인 관계를 검사한다.61
ST_Touches, ST_Crosses, ST_Overlaps, ST_Disjoint: 그 외 특정 관계를 테스트하기 위한 함수들이다.56
이러한 술어 함수들은 공간 필터링의 기본 구성 요소이며, 인덱스를 활용하도록 설계되어 매우 효율적이다. 예를 들어, 특정 행정 구역 내에 위치한 관심 지점(POI)을 찾는 일반적인 공간 조인 패턴은 다음과 같이 작성할 수 있다.64
SELECT p.name
FROM points_of_interest p
JOIN admin_boundaries b ON ST_Contains(b.geom, p.geom)
WHERE b.name = 'Downtown';
더 나아가, PostGIS는 ST_Relate 함수를 통해 완전한 DE-9IM(Dimensionally Extended 9-Intersection Model) 행렬을 계산할 수 있게 하여, 매우 구체적이고 복잡한 위상 관계를 질의할 수 있는 고급 기능을 제공한다.55
ST_Buffer 함수는 원본 지오메트리로부터 지정된 거리 내에 있는 모든 점들을 나타내는 폴리곤을 생성한다.66 거리는 양수(확장) 또는 음수(축소)일 수 있다. 이 함수는 버퍼의 끝 모양(end cap: round, flat, square)과 연결 모양(join: round, mitre, bevel)에 대한 광범위한 스타일 옵션을 제공한다.66
이것은 “이 파이프라인으로부터 500m 이내의 영역은 어디인가?”와 같은 근접성 분석을 위한 기본적인 지오프로세싱 도구이다. 하지만 단순한 반경 검색을 위해서는 버퍼를 생성하고 교차 검사를 하는 것보다 ST_DWithin 함수를 사용하는 것이 훨씬 더 성능이 우수하다는 점을 유념해야 한다.68
예를 들어, ‘Main St’ 도로에 대해 끝이 평평하고 모서리가 각진 버퍼를 생성하는 질의는 다음과 같다.66
SELECT ST_Buffer(geom, 50, 'endcap=flat join=mitre')
FROM roads
WHERE road_name = 'Main St';
ST_Intersection 함수는 두 입력 지오메트리가 공유하는 부분을 나타내는 새로운 지오메트리를 반환한다.57 만약 두 지오메트리가 교차하지 않으면 빈 지오메트리가 반환된다.
이 함수는 하나의 피처를 다른 피처의 경계에 맞춰 잘라내는 “클리핑(clipping)” 작업에 필수적이다. 예를 들어, 특정 필지가 홍수 구역 내에 포함되는 부분을 찾아낼 때 사용된다.53 최적의 성능을 위해서는 인덱스를 활용할 수 있도록 WHERE 절에 ST_Intersects 검사를 함께 사용하는 것이 거의 항상 권장된다.72
‘West Village’ 동네에 맞춰 도로를 클리핑하는 질의 예시는 다음과 같다.73
SELECT r.road_name, ST_Intersection(r.geom, n.geom) AS clipped_road
FROM roads r
JOIN neighborhoods n ON ST_Intersects(r.geom, n.geom)
WHERE n.name = 'West Village';
ST_Union 함수는 여러 지오메트리를 내부 경계를 녹여 하나의 지오메트리로 병합한다.76 이 함수는 두 개의 인자를 받는 버전과 GROUP BY 절과 함께 사용되는 집계(aggregate) 버전이 있다.
집계 버전은 여러 군(county) 폴리곤을 단일 주(state) 폴리곤으로 병합하는 것과 같은 요약 지오메트리를 생성하는 데 매우 강력하다.76
ST_Union은 경계를 녹이는 복잡한 기하학적 처리를 수행하기 때문에, 단순히 지오메트리를 그룹화하기만 하는 ST_Collect 함수보다 훨씬 느리다.77
지역별로 카운티 폴리곤을 병합하는 질의 예시는 다음과 같다.77
SELECT region_name, ST_Union(geom) AS region_geom
FROM counties
GROUP BY region_name;
PostGIS는 공간 객체를 정량적으로 측정하기 위한 함수들을 제공한다.
ST_Area: 폴리곤 또는 멀티폴리곤의 면적을 계산한다.36ST_Length: 라인스트링 또는 멀티커브의 길이를 계산한다.37ST_Distance: 두 지오메트리 간의 최소 거리를 계산한다.81이 함수들의 동작은 사용하는 데이터 타입에 결정적으로 의존한다. geometry 타입의 경우, 결과는 SRS의 단위(예: 제곱도)로 반환되는데, 이는 오해의 소지가 있을 수 있다. 반면 geography 타입의 경우, 결과가 미터, 제곱미터 등 실세계 단위로 반환되어 직관적인 답을 제공한다.36
이러한 측정 함수들은 geometry와 geography 타입 간의 구분이 왜 실용적으로 중요한지를 명확히 보여준다. 사용자가 한 필지의 면적을 알고 싶어 ST_Area(geom)을 실행했다고 가정해보자. 만약 geom 컬럼이 위경도 좌표계인 SRID 4326을 사용한다면, 결과는 “제곱도”라는, 물리적으로 직관적인 의미가 없고 위도에 따라 그 크기가 변하는 단위로 나올 것이다. 이는 초보자들이 흔히 저지르는 실수이다.34 의미 있는 제곱미터 단위의 답을 얻기 위해서는, 사용자가 (a) 면적을 계산하기 전에 geometry를 적절한 투영 좌표계(예: UTM 존)로 변환하거나, (b) 처음부터 geography 타입을 사용해야 한다. 이는 측정 함수가 개발자로 하여금 지구의 곡률이라는 현실을 직시하고, 의식적인 설계 결정을 내리도록 강제하는 주요 동인임을 보여준다. 즉, geography 타입을 선택하거나 엄격한 투영 관리 워크플로우를 구현하게 만드는 것이다.
본 장에서는 PostGIS를 단순한 벡터 데이터 저장소에서 포괄적인 다중 모드 공간 분석 플랫폼으로 격상시키는 기능들을 탐구한다.
PostGIS는 고도 모델이나 위성 이미지와 같은 래스터(그리드 기반) 데이터를 저장하고 분석할 수 있다.15 이 기능은 postgis_raster 확장을 통해 제공되며, GDAL 라이브러리에 크게 의존한다.24 래스터는 픽셀 데이터를 데이터베이스 내부에 저장하는 “in-db” 방식과, 데이터베이스에는 외부 파일에 대한 포인터만 저장하는 “out-db” 방식으로 관리될 수 있다.83
PostGIS는 강력한 맵 대수(Map Algebra)를 지원하여, ST_MapAlgebraExpr와 같은 함수를 사용해 래스터 간 또는 래스터와 상수 간의 픽셀 단위 연산을 가능하게 한다.85 이를 통해 데이터베이스 내에서 직접 복잡한 모델링을 수행할 수 있다. PostGIS의 핵심 강점 중 하나는 폴리곤으로 래스터를 자르거나(ST_Clip), 특정 폴리곤 내에 있는 래스터 픽셀의 통계치를 계산하는(ST_SummaryStats) 등, 래스터와 벡터 데이터를 원활하게 통합하여 분석하는 능력이다.21
강력한 기능에도 불구하고, 단순한 데이터 제공(예: WMS) 목적이라면 데이터베이스 내 래스터 저장은 파일 기반 접근 방식보다 느릴 수 있다.83 이 기능의 진정한 강점은 대용량 데이터를 파일 시스템과 데이터베이스 간에 이동시키는 것이 큰 병목이 되는 복잡한 통합 래스터-벡터 분석에 있다. 특히 클라우드 최적화 GeoTIFF(COG)에 대한 “out-db” 지원은 데이터베이스의 질의 능력과 클라우드 객체 저장소의 효율성을 결합한 현대적인 하이브리드 접근 방식이다.84
PostGIS의 geometry 타입은 Z 좌표를 저장할 수 있지만, 대부분의 표준 함수는 2D 공간에서 작동한다. 진정한 3D 분석을 위해 PostGIS는 CGAL 라이브러리의 C++ 래퍼인 SFCGAL과 통합된다.25 이 기능은 postgis_sfcgal 확장을 통해 활성화된다.
SFCGAL은 3D 교차(ST_3DIntersection), 3D 차집합(ST_3DDifference), 3D 합집합(ST_3DUnion), 부피 계산(ST_Volume), 그리고 3D 객체 생성(ST_MakeSolid, ST_Extrude)과 같은 고급 함수들을 제공한다.25 이로써 PostGIS는 도시 계획(건물 모델링), 지질학, 공학 등 고급 3D 모델링을 위한 실행 가능한 플랫폼이 된다. SFCGAL의 통합은 PostGIS가 외부의 전문 라이브러리를 활용하여 처음부터 모든 것을 구축하지 않고도 새로운 영역으로 그 능력을 확장하는 아키텍처 패턴의 또 다른 예시이다.
pgRouting은 PostgreSQL/PostGIS를 위한 또 다른 강력한 확장 기능으로, 네트워크 분석 및 경로 최적화 함수를 제공한다.89 이 확장은 최단 경로 문제(다익스트라, A* 알고리즘), 외판원 문제(TSP), 그리고 주행 가능 거리 등시선(isochrone) 계산과 같은 문제들을 해결할 수 있다.
일반적인 작업 흐름은 OpenStreetMap과 같은 도로망 데이터를 라우팅 가능한 엣지(edge)와 버텍스(vertex)의 위상 구조로 변환한 다음, pgRouting의 함수를 사용하여 최적의 경로를 찾는 것이다.90
pgRouting은 PostGIS를 단순한 데이터 저장소에서 물류, 교통 계획 및 모빌리티 애플리케이션의 핵심 엔진으로 변모시킨다. 이는 많은 오픈소스 라우팅 솔루션에서 핵심 구성 요소로 사용된다.91
PostGIS는 미국 인구조사국의 TIGER/Line 데이터를 사용하는 postgis_tiger_geocoder 확장을 통해 미국 중심의 지오코더를 제공한다.89 이 확장에는 주소를 좌표로 변환하는 지오코딩(geocode), 좌표를 주소로 변환하는 리버스 지오코딩(reverse_geocode), 그리고 주소를 표준화하는(standardize_address) 함수가 포함되어 있다.94
미국 내에서는 강력하지만, 이는 PostGIS에 내장된 전 지구적 지오코더가 없다는 한계를 드러낸다. 다른 지역의 경우, 사용자들은 Nominatim(이 역시 PostGIS를 백엔드로 사용)과 같은 제3자 도구나 상용 서비스에 의존해야 한다.94 하지만 TIGER 지오코더 자체는 데이터, 함수, 그리고 퍼지 문자열 매칭을 사용하여 데이터베이스 내에서 전적으로 복잡한 애플리케이션을 구축하는 강력한 사례를 보여준다.
본 장에서는 하드웨어부터 데이터 모델링, 질의 구성에 이르기까지 전체 스택에 걸쳐 PostGIS 성능을 극대화하기 위한 실행 가능한 전략을 제공한다.
PostgreSQL 성능 튜닝은 PostGIS 최적화의 첫걸음이다. postgresql.conf 파일의 핵심 파라미터는 다음과 같다.
shared_buffers: 데이터 캐싱을 위한 메모리. 시스템 RAM의 25-40%를 할당하는 것이 일반적인 권장 사항이다.95work_mem: 정렬, 해시, 조인 작업에 사용되는 메모리. 복잡한 분석 질의(OLAP)에는 더 높은 값이 필요하다.96maintenance_work_mem: VACUUM 및 CREATE INDEX에 사용되는 메모리. 이 작업들의 속도를 높이기 위해 넉넉하게 설정해야 한다.96max_parallel_workers: 다중 코어 CPU를 활용하여 병렬 질의를 수행하기 위한 설정이다.96하드웨어 또한 성능에 큰 영향을 미친다. 복잡한 계산을 위한 빠른 CPU, 캐싱을 늘리고 디스크 I/O를 줄이기 위한 충분한 RAM, 그리고 빠른 디스크 I/O(SSD 선호, RAID 10 종종 권장)가 필수적이다.95 튜닝은 모든 상황에 맞는 단일 해법이 없으며, 작업 부하(예: 읽기 중심의 OLAP 대 쓰기 중심의 OLTP)에 맞춰 조정되어야 한다.96 변경 사항을 벤치마킹하는 것은 매우 중요하며, 측정 없는 튜닝은 추측에 불과하다.96
CLUSTER: 인덱스 순서와 일치하도록 테이블을 디스크 상에서 물리적으로 재정렬한다. 이는 관련 데이터를 물리적으로 인접하게 저장하여, 범위 스캔 시 무작위 I/O를 극적으로 줄여 성능을 크게 향상시킬 수 있다.20NOT NULL 제약 조건을 추가하여 계획기를 돕는 것이다.20이러한 전략들은 PostGIS 성능이 단순히 설정 파라미터뿐만 아니라 데이터의 물리적, 논리적 구조에도 민감하다는 점을 보여준다. 표준적인 데이터베이스 튜닝이 메모리, CPU, 설정에 초점을 맞추는 반면, CLUSTER나 무작위 삽입 순서와 같은 개념은 데이터의 물리적 레이아웃과 논리적 순서와 관련이 있다. 이는 공간 데이터의 고유한 지역성(locality) 때문에, 디스크 상에서 데이터의 물리적 근접성이 중요한 성능 요소임을 시사한다. 삽입 순서에 대한 민감성은 R-Tree/GiST 알고리즘의 미묘한 특성, 즉 그 최종 “품질”이 이력에 의존하는 동적 구조라는 점을 드러낸다. 따라서 PostGIS 성능 전문가는 단순한 DBA를 넘어, 데이터의 구조와 순서 자체가 인덱싱 알고리즘과 상호 작용하여 성능에 어떤 영향을 미치는지 이해하는 데이터 아키텍트여야 한다. 이는 단순히 shared_buffers를 조정하는 것보다 더 깊은 수준의 최적화이다.
ST_Simplify를 사용하여 주어진 허용 오차 내에서 지오메트리의 정점 수를 줄이면, 특히 시각화 목적에서 렌더링 및 분석 속도를 높일 수 있다.48이러한 기법들은 최적의 성능을 위해 종종 저장 공간이나 어느 정도의 상세 수준을 질의 속도와 맞바꾸는 것을 보여준다. 이는 공간 도메인에 적용된 고전적인 데이터 엔지니어링의 트레이드오프이다.
AWS RDS, Azure, GCP와 같은 주요 클라우드 제공업체들은 PostGIS를 확장 기능으로 포함한 관리형 PostgreSQL 서비스를 제공한다.14 이는 설치, 유지보수, 백업 및 확장을 단순화한다.104
클라우드 환경에서의 모범 사례는 다음과 같다.
postgis_raster의 out-db 기능을 사용하여 S3와 같은 객체 저장소에 저장된 클라우드 최적화 GeoTIFF(COG)를 활용한다. 이는 클라우드 저장소의 확장성과 PostGIS의 질의 능력을 결합하여, 대용량 래스터 파일을 데이터베이스 자체에 저장할 필요성을 없앤다.84클라우드 환경은 서버 관리의 초점을 저수준의 관리에서 고수준의 구성, 보안 및 비용 관리로 이동시킨다. 관리형 서비스는 PostGIS 사용의 진입 장벽을 낮추지만, 클라우드 보안 및 아키텍처와 관련된 새로운 기술을 요구한다.
| 분류 | 전략 | 설명 및 근거 | 관련 자료 |
|---|---|---|---|
| 하드웨어 | CPU, RAM, 디스크 I/O, 네트워크 | 빠른 CPU는 복잡한 연산에, 충분한 RAM은 캐싱 증대 및 디스크 I/O 감소에, 빠른 SSD는 데이터 접근 속도에 필수적이다. | 95 |
| PostgreSQL 설정 | shared_buffers, work_mem, maintenance_work_mem, autovacuum 설정 |
각 파라미터의 목적을 이해하고 작업 부하(OLTP/OLAP)에 맞게 조정해야 한다. shared_buffers는 RAM의 25-40%, maintenance_work_mem은 인덱스 생성 속도를 위해 크게 설정한다. |
96 |
| 인덱싱 | CREATE INDEX... USING GIST, CLUSTER, VACUUM ANALYZE |
GiST 인덱스는 필수적이다. CLUSTER는 디스크의 물리적 순서를 인덱스와 일치시켜 I/O를 최적화하며, VACUUM ANALYZE는 질의 계획기를 위한 통계 정보를 최신 상태로 유지한다. |
19 |
| 데이터 모델링 | 단순화(ST_Simplify), 폴리곤 세분화, 파티셔닝 |
복잡한 지오메트리를 단순화하거나 큰 폴리곤을 작은 조각으로 나누면 MBR의 효율이 높아져 인덱스 성능이 향상된다. 대용량 테이블은 파티셔닝하여 질의 범위를 좁힌다. | 48 |
| 질의 설계 | 인덱스 활용 함수 사용(ST_DWithin), WHERE 절에서 비싼 함수 회피, 구체화된 뷰 |
ST_DWithin은 인덱스를 사용하지만 ST_Distance는 그렇지 않다. 복잡한 조인 결과는 구체화된 뷰로 미리 계산하여 질의 계획기의 부담을 줄인다. |
56 |
본 장에서는 PostGIS를 더 넓은 지리 공간 기술 환경 내에 위치시키고, 동료 기술들과 비교하며, 실제 사례 연구를 통해 그 영향력을 보여준다.
PostGIS는 종종 Oracle Locator보다 기능이 풍부하고 Oracle Spatial과 경쟁할 만한 수준으로 평가된다.107 일부 벤치마크에서는, 특히 기본 설정에서 PostGIS가 Oracle을 능가하는 성능을 보였지만, 튜닝 및 운영체제와 같은 환경 변수가 결과를 좌우할 수 있다.110 Oracle은 역사적으로 더 강력한 측지 지원과 다른 사용자/스키마 모델을 가지고 있었다.111 PostGIS는 특히 집계 합집합(aggregate union) 기능의 성능 면에서 높은 평가를 받는다.108 선택은 종종 비용(PostGIS는 무료, Oracle은 고가)과 기존 기업의 기술 스택에 따라 결정된다. 오픈소스 중심 환경에서는 PostGIS가 명백한 선택지이며, Oracle 중심의 기업에서는 라이선스 비용과 통합 및 직원 교육 비용을 저울질하게 된다.
PostGIS는 훨씬 더 많은 공간 함수(300개 이상 대 약 70-100개)와 GeoJSON과 같은 개방형 표준에 대한 더 나은 지원을 제공한다.43 SQL Server의 공간 인덱싱은 정적 그리드를 사용하는 쿼드트리(Quadtree) 기반으로, 데이터 밀도가 불균일한 데이터셋에서 성능이 저하될 수 있는 반면, PostGIS의 R-Tree는 더 적응력이 뛰어나다.113 그러나 SQL Server는 SharePoint 등 마이크로소프트 생태계와의 긴밀한 통합이라는 강점을 가진다.108 순수한 공간 기능과 유연성 면에서는 PostGIS가 명확한 이점을 가지며, 성능 비교에서도 더 정교한 공간 인덱스 덕분에 PostGIS가 종종 우위를 보인다.113
vs. SpatiaLite / GeoPackage
SpatiaLite와 GeoPackage는 SQLite 기반의 파일 기반 데이터베이스이다.115 이들은 단일 사용자, 로컬 또는 모바일 워크플로우에 탁월하며 단일 파일로 쉽게 공유할 수 있다.115 반면 PostGIS는 다중 사용자, 동시성 접근, 그리고 파일 기반 시스템에서는 느리거나 불가능한 매우 큰 데이터셋을 처리하도록 설계된 클라이언트-서버 데이터베이스이다.3 이는 직접적인 경쟁이라기보다는 작업에 적합한 도구를 선택하는 문제이다. 개인 개발자나 모바일 앱에는 GeoPackage/SpatiaLite이 더 간단하고 나은 선택일 수 있다. 그러나 기업 시스템, 웹 서비스 백엔드, 또는 다중 사용자 환경에서는 확장성, 보안, 동시성 때문에 PostGIS가 필수적인 솔루션이다.
도시 계획 및 개발: 토지 이용 계획, 인프라 관리, 부지 선정, 건물/도로/공원 간의 공간 관계 분석에 사용된다.31 위성 이미지를 통합하여 건설 진행 상황을 모니터링하고 도시 열섬 효과와 같은 환경 위험을 평가하는 사례도 있다.82 PostGIS는 단순한 지도 제작을 넘어 도시 동역학의 복잡한 모델링과 시뮬레이션을 위한 분석 엔진을 제공한다.
환경 과학 및 보존: 토지 이용 변화 추적, 생태계 건강 모니터링, 서식지 매핑, 보호 구역 관리, 그리고 기후 변화 연구를 위한 센서 및 위성 데이터 분석에 활용된다.119 PostGIS의 벡터 및 래스터 데이터 동시 처리 능력은 환경 모델링을 위한 강력하고 통일된 플랫폼을 제공한다.
물류 및 경로 최적화: 차량 경로 문제(VRP), 라스트 마일 배송, 차량 관리에 핵심 구성 요소로 사용된다.90 비용, 시간 및 기타 제약 조건에 따라 최적 경로를 계산하기 위해 종종 pgRouting 확장과 함께 사용된다.90 PostGIS와 pgRouting의 조합은 물류 산업을 위한 강력한 오픈소스 스택을 형성한다.
공공 안전 및 재난 관리: 범죄 분석(사건의 시공간적 모니터링), 위험 평가(홍수, 지진에 취약한 지역 식별), 그리고 비상 대응 조정에 사용된다.119 빠른 공간 질의와 다양한 데이터셋 통합 능력은 시간에 민감한 공공 안전 애플리케이션에 매우 중요하다.
부동산: 편의 시설과의 근접성 분석, 시장 동향 분석, 부지 선정을 통한 부동산 가치 평가에 사용된다.119 CartoDB(현 CARTO)와 같은 회사는 전체 위치 인텔리전스 플랫폼을 PostGIS 위에 구축하여 부동산 및 소매 고객에게 서비스를 제공했다.127 PostGIS는 부동산 분석의 근간이 되는 “어디에”라는 질문에 답하는 힘을 제공한다.
PostGIS는 크고 활발한 오픈소스 커뮤니티를 보유하고 있다.129
이러한 자료들은 PostGIS 커뮤니티가 단순한 지원 채널을 넘어, 제품의 핵심 기능이자 전략적 자산임을 보여준다. 특히 오픈소스 기술에서 생태계의 질은 코드의 질만큼이나 중요하다. 문서나 커뮤니티가 없는 강력한 도구는 무용지물이다. PostGIS의 생태계는 예외적으로 강력하다. PostGIS in Action과 같은 서적의 존재, GIS Stack Exchange의 깊이, 그리고 공식 워크숍 등은 학습 곡선을 낮추고, 많은 상용 제품에서 제공하는 것과 필적하거나 그 이상의 강력한 지원 네트워크를 제공한다. 따라서 조직이 PostGIS를 채택할 때, 그들은 이 방대한 공유 지식 저장소도 함께 채택하는 것이다. 이는 교육 비용을 절감하고, 개발을 가속화하며, 문제 해결에 대한 위험을 완화한다. 이는 상용 대안과 비교할 때 PostGIS의 가치 제안에서 중요하지만 눈에 보이지 않는 부분이다.
본 장에서는 보고서의 분석 결과를 종합하고, 새로운 기술 동향 속에서 PostGIS의 미래를 전망한다.
pgRouting, MobilityDB 등 풍부한 확장 기능 생태계를 활용한다.13커뮤니티: 강력한 커뮤니티 지원과 훌륭한 문서를 갖추고 있다.43
geography 타입의 한계: geography 타입은 지원하는 함수가 더 적고 geometry 타입보다 느릴 수 있다.32PostGIS 개발은 지속적으로 이루어지며 PostgreSQL의 릴리스 주기에 맞춰 진행된다.153 최신 알파 릴리스(예: 3.6.0alpha1)는 곧 출시될 PostgreSQL 18 및 최신 GEOS/PROJ 버전에 대한 의존성을 보여주며, 이는 최신 기술을 유지하려는 노력을 나타낸다.15 미래 지향적인 발표와 개발 동향은 다음 영역에 초점을 맞추고 있다.
PostGIS의 미래는 세 가지 핵심 영역에 집중될 것으로 보인다. 첫째, 병렬 처리 및 JIT 컴파일과 같은 새로운 기능을 활용하기 위한 PostgreSQL 코어와의 더 깊은 통합. 둘째, 단순 피처를 넘어 궤적(MobilityDB), 3D 솔리드(SFCGAL), 위상적 커버리지와 같은 더 풍부한 데이터 모델 지원. 셋째, 데이터베이스와 프론트엔드 간의 간극을 메우고 웹 서비스 및 애플리케이션 구축 프로세스를 단순화하는 더 쉬운 애플리케이션 개발 환경 제공.
이러한 발전은 PostGIS가 단순한 공간 데이터베이스에서 시공간 및 다차원 분석을 위한 포괄적인 플랫폼으로 진화하고 있음을 시사한다. 초기 PostGIS가 2D 벡터 데이터에 대한 OGC SFS 표준 구현에 중점을 두었다면, 이후의 개발은 래스터, 3D, 토폴로지 지원을 추가하며 데이터 처리 능력을 확장했다. MobilityDB와 같은 확장의 개발 및 궤적 분석을 위한 ZM 값에 대한 강조에서 볼 수 있듯이, 현재와 미래의 추세는 시간 차원을 공간 차원과 함께 일급 시민으로 통합하는 방향으로 명확히 나아가고 있다.155 이는 사물이 어디에 있는지뿐만 아니라 시간에 따라 어떻게 움직이고 변화하는지를 분석하는 더 넓은 산업 동향을 반영한다. 따라서 PostGIS는 더 이상 ‘공간’ 데이터베이스에만 머무르지 않는다. 사물 인터넷(IoT), 물류, 자율 시스템과 같은 분야에 필수적인 차세대 시공간 분석을 위한 기초적인 오픈소스 플랫폼으로 자리매김하고 있다. PostGIS의 미래는 더 나은 지오메트리 처리에만 있는 것이 아니라, 복잡하고 다차원적인 현실 세계의 현상을 분석하는 도구를 제공하는 데 있다.
| Optimizing Geospatial Data Storage with PostgreSQL and PostGIS | by Lyron Foster, accessed July 14, 2025, https://medium.com/@lfoster49203/optimizing-geospatial-data-storage-with-postgresql-and-postgis-dd6aee7df005 |
| Waiting for PostGIS 3.1: GEOS 3.9 | Crunchy Data Blog, accessed July 14, 2025, https://www.crunchydata.com/blog/waiting-for-postgis-3.1-geos-3.9 |
| Connecting QGIS to Postgres and PostGIS | Crunchy Data Blog, accessed July 14, 2025, https://www.crunchydata.com/blog/connecting-qgis-to-postgres-and-postgis |
| PostGIS and the Geography Type | Crunchy Data Blog, accessed July 14, 2025, https://www.crunchydata.com/blog/postgis-and-the-geography-type |
| Boosting PostGIS Performance | by Branislav Stojkovic | Medium | symphonyis, accessed July 14, 2025, https://medium.com/symphonyis/boosting-postgis-performance-c68a478daa0a |
| Contains/Covers/Intersects/Within? | by Michael Entin - Medium, accessed July 14, 2025, https://mentin.medium.com/contains-covers-intersects-within-cb608b470471 |
| Spatial Relationship and Measurement Functions | GEOG 868 - Dutton Institute - Penn State, accessed July 14, 2025, https://www.e-education.psu.edu/spatialdb/node/1974 |
| A Beginner’s Guide to Spatial Queries with PostgreSQL and PostGIS | by Felipe Limeira, accessed July 14, 2025, https://medium.com/@limeira.felipe94/a-beginners-guide-to-spatial-queries-with-postgresql-and-postgis-8128392f7bb6 |
| A Guide to PostGIS: Basic Geospatial Data Query Examples | LearnSQL.com, accessed July 14, 2025, https://learnsql.com/blog/postgis-basic-queries/ |
| PostGIS Function of the Week | Episode #3 | st_union - YouTube, accessed July 14, 2025, https://www.youtube.com/watch?v=jxZIThPlJWQ |
| Integrating Satellite Image Analysis into Urban Planning GIS | by Chris Williams | Medium, accessed July 14, 2025, https://medium.com/@c.r.williams0109/integrating-satellite-image-analysis-into-urban-planning-gis-5f0cc885429c |
| Using Cloud Rasters with PostGIS | Crunchy Data Blog, accessed July 14, 2025, https://www.crunchydata.com/blog/using-cloud-rasters-with-postgis |
| Vehicle Routing with PostGIS and Overture Data | Crunchy Data Blog, accessed July 14, 2025, https://www.crunchydata.com/blog/vehicle-routing-with-postgis-and-overture-data |
| Understanding the PostgreSQL Architecture | Severalnines, accessed July 14, 2025, https://severalnines.com/blog/understanding-postgresql-architecture/ |
| Tricks for Faster Spatial Indexes | Crunchy Data Blog, accessed July 14, 2025, https://www.crunchydata.com/blog/tricks-for-faster-spatial-indexes |
| Boosting Performance in PostGIS: Top Strategies for Optimizing Your Geographic Database | by Felipe Limeira | Medium, accessed July 14, 2025, https://medium.com/@limeira.felipe94/boosting-performance-in-postgis-top-strategies-for-optimizing-your-geographic-database-167ff203768f |
| PostGIS Reviews 2025: Details, Pricing, & Features | G2, accessed July 14, 2025, https://www.g2.com/products/postgis/reviews |
| International Journal of Research Publication and Reviews Geospatial Data Warehousing: A Case Study on PostGIS, QGIS, and Apache Solr Integration | Request PDF - ResearchGate, accessed July 14, 2025, https://www.researchgate.net/publication/380847764_International_Journal_of_Research_Publication_and_Reviews_Geospatial_Data_Warehousing_A_Case_Study_on_PostGIS_QGIS_and_Apache_Solr_Integration |
| Optimizing Delivery Routes: Historical and Real-Time Data | by Merve Gamze Cinar, accessed July 14, 2025, https://medium.com/@mervegamzenar/optimizing-delivery-routes-historical-and-real-time-data-f365d6b717be |
| Web Forums | PostGIS, accessed July 14, 2025, https://postgis.net/community/web/ |
| PostGIS in Action | Book by Regina Obe, Leo Hsu - Simon & Schuster, accessed July 14, 2025, https://www.simonandschuster.com/books/PostGIS-in-Action/Regina-Obe/9781935182269 |
| PostGIS in Action, Third Edition | Paperback - Barnes & Noble, accessed July 14, 2025, https://www.barnesandnoble.com/w/postgis-in-action-third-edition-leo-s-hsu/1136806452 |
| Basics of PostGIS | Tutorials - Crunchy Data, accessed July 14, 2025, https://www.crunchydata.com/developers/playground/basics-of-postgis |
| Introduction to PostGIS | Center for Geographic Analysis, accessed July 14, 2025, https://gis.harvard.edu/introduction-postgis |