postgis 확장 모듈 만들기

postgis 확장 모듈

PostgreSQL 데이터베이스를 쓰는 이유 가운데 꽤나 큰 부분을 차지하는 확장 모듈입니다. 물론 postgis 가 사용 목적이 되는 경우는 거의 없죠. 대부분 지리 정보 응용 프로그램에서 다루는 자료를 저장하고, 찾고 하는데, 그 응용 프로그램이 PostgreSQL + postgis 구성을 필요로 하기에 그 응용 프로그램에서 하라는 대로 설치하고 사용할 뿐이죠. 아마 대부분의 사용자가 그럴 것입니다.

postgis는 공간 정보를 geometry, geography 두 자료형에 담고, 그것을 처리하기 위한 각종 함수들을 제공하는 확장 모듈입니다.

CentOS에서 postgis 쓰기

postgis 모듈을 사용하려면, 먼저 PostgreSQL 데이터베이스 서버가 운영 중이여야합니다.

yum 패키지 관리자 사용하기

일반적으로 간단하게, PostgreSQL Global Development Group에서 제공하는 yum 저장소를 이용해서 rpm 패키지로 PostgreSQL 데이터베이스를 설치한 경우라면, 같은 저장소에서 원하는 postgis 패키지를 설치해서 사용하면 됩니다. (참고로 postgis 같이 복잡한 패키지는 EPEL (Extra Packages for Enterprise Linux) 저장소(패키지 이름: epel-release.noarch) 등록을 먼저 해야지 번거로움이 줍니다.)

CentOS 7.X 인 경우를 예로 들면,

# yum search postgis

윗 명령을 실행하면 엄청난 패키지들이 나옵니다.

postgis30_12.x86_64 이런 형태로 앞의 30은 postgis 버전, 뒤에 12는 PostgreSQL 버전입니다.

사용할 수 있는 postgis + PostgreSQL 조합에 대해서는

https://trac.osgeo.org/postgis/wiki/UsersWikiPostgreSQLPostGIS

페이지에서 소개하고 있습니다.

아주 중요한 페이지입니다. 잘 읽어보시고, 적절한 조합을 찾으셔야합니다.

이 글에서는 윗 페이지에서 소개하고 있는 권장 버전 조합으로 진행하려고 합니다.

이 글을 쓰는 시점에 조합은 postgis 3.0.0, PostgreSQL 12.1 입니다. yum 패키지 검색을 다시 합니다.

# yum search postgis30 | grep '_12'
postgis30_12-debuginfo.x86_64 : Debug information for package postgis30_12
postgis30_12.x86_64 : Geographic Information Systems Extensions to PostgreSQL
postgis30_12-client.x86_64 : Client tools and their libraries of PostGIS
postgis30_12-devel.x86_64 : Development headers and libraries for PostGIS
postgis30_12-docs.x86_64 : Extra documentation for PostGIS
postgis30_12-gui.x86_64 : GUI for PostGIS
postgis30_12-utils.x86_64 : The utils for PostGIS

설치할 패키지들입니다.

yum 패키지 관리자의 의존 패키지 함께 설치하는 기능 덕분에 postgis 설치는 참 쉽죠.

yum install postgis30_12

CentOS 최소설치 환경에서는 이 작업에 약 백여개의 패치지가 한꺼번에 설치되네요.

소스 직접 컴파일 설치

postgis는 PostgreSQL 소스 컴파일보다 훨씬 복잡합니다. 정신 건강을 위해서 그냥 공식 배포처에서 배포하는 패키지를 사용하는 것이 좋기는 합니다. 하지만, 기업 환경 내에서, 특히나 OS 호스트 관리자와 PostgreSQL 서버 관리자가 분리되어 있는 상황이고, 전사 소프트웨어 관리를 하고 있는 곳에서는 부득이 그 기업 환경에 맞게 PostgreSQL 서버 소스를 직접 컴파일 해서 사용합니다. 이런 경우에, postgis 도 함께 써야하는 상황이면, 결국 postgis도 직접 컴파일 해서 사용해야 합니다.

먼저 postgis 의존성 패키지들 가운데, 어디까지 OS 쪽에 맡겨, yum 명령어로 패키지를 설치하고, 나머지는 직접 소스를 구해서 설치할 지를 결정해야 합니다.

postgis를 컴파일 하기 위해서는 다음 패키지들이 필요합니다.

geos (Geometry Engine - Open Source)
proj (generic coordinate transformation software)
- 6.3 부터 sqlite 3.11 이상을 필요로 함. CentOS 7 배포판의 sqlite는 3.7
gdal (translator library for raster and vector geospatial data)
- proj, jasper, openjpeg, curl, xml2, pcre, json-c, openssl ...
- 그 외 다 나열하기 힘든 그래픽 관련 라이브러리들
sfcgal (Computational Geometry Algorithms Library c++ wrapper)
- cgal

이 많은 것들을 모두 소스를 찾고 컴파일 할 수는 없기에, 여기는 "CentOS 공식 배포판에서 제공하는 패키지들은 그것을 사용하고(base, updates repo만 사용), 그 외 나머지는 모두 직접 소스 컴파일 해서 사용한다" 는 정책으로 작업을 하려고 합니다.

윗 버전 정보를 맞춰 정리하면,

postgis 3.0.0
PostgreSQL 12.1
geos 3.8.0
proj 6.2.1
gdal 3.0.2
sfcgal 1.3.7 + cgal 4.14.2

여기까지가 직접 소스를 구해서 컴파일하고 설치하며, 이들을 컴파일 하기 위해서 필요한 패키지들은 OS 배포판에서 yum 으로 설치할 예정입니다.

./configure --prefix

직접 소스를 컴파일해서 설치하는 경우, OS 배포판의 설치 경로와 분리하는 것이 중요합니다. 그래서, 이번 설치에서는 다음과 같이 각 패키지들의 설치 경로를 지정했습니다.

/postgres/12 : PostgreSQL 데이터베이스 서버
/postgres/12/geos
/postgres/12/proj
/postgres/12/gdal
/postgres/12/cgal
/postgres/12/sfcgal

이렇게 사용하는 이유가 postgis는 PostgreSQL 서버 메이져 버전과 관계됩니다. 11버전에서 사용했던 postgis 모듈을 12버전에서도 사용하려면, 새로 컴파일 해야 하기에 이왕 컴파일 할 것, 이 때 postgis 버전도 바꾸고 싶다면, postgis 빌드를 위한 관계되는 다른 패키지들도 줄줄이 버전을 바꿔 컴파일을 하는 일이 벌어지기 때문에, 차라리, 이 gdal 라이브러리는 PostgreSQL 12버전의 postgis에서 사용하는 것, 이렇게 해 버리는 것이 좀 더 깔끔합니다.

이렇게 사용하게 되면 각 패키지에서 제공하는 공유 라이브러리 위치가 모두 제각각이 되기 때문에, 이 공유 라이브러리를 잘 사용하는 세심한 주의가 필요해집니다.

geos, proj, gdal 이런 패키지들은 대표적인 오픈소스 공간 정보 클라이언트 도구인 qgis 에서 사용하는 라이브러리들 입니다. 그래서, 만일 qgis를 yum으로 설치한 경우라면, 이미 이런 라이브러리들이 설치되어 있을 것입니다. 게다가 이들은 지금 설치하려고 하는 버전보다 오래된 버전일 가능성이 큽니다.

그래서, ldd 명령을 통해서 각 라이브러리, 실행 파일들이 정말 새롭게 설치한 라이브러리를 잘 참조하는지 꼼꼼히 살펴보아야합니다.

흔히 LD_LIBRARY_PATH OS 환경 변수를 지정해서 잘 사용하면 되겠지 이렇게 생각하고는 신경을 안쓰는데, 장애는 이 LD_LIBRARY_PATH 설정이 안되어있거나, 잘못되어있어 생기는 경우가 많습니다.

여기서 언급한 라이브러리들은 서로 의존성이 있어, 아래와 같이 순서 대로 설치되어야 정상적으로 설치할 수 있습니다.

(geos와 proj는 순서가 바뀌어도 괜찮습니다.)

geos

geos 패키지는 stdc++ 라이브러리 외 다른 라이브러리 의존성이 없어, PostgreSQL 서버를 컴파일하는 환경이면 따로 신경 쓸 것 없이 잘 만들어집니다.

$ ./configure --prefix=/postgres/12/geos && make all && make install

이 작업이 잘 안된다면, 빌드 환경이 갖춰져 있지 않은 경우입니다. 필요한 패키지들을 yum 명령을 통해 설치하셔야합니다.

proj

proj 패키지는 설치할 때 sqlite 패키지 충돌에 주의하셔야합니다.

현재 proj 버전은 6.3.0 입니다. 이 버전은 sqlite 3.11 이상을 필요로 하는데, CentOS 7 에서 제공하는 것은 3.7 입니다.

쉽게 생각하면, sqlite 버전을 바꾸면 되겠지하겠지만, 이렇게 하면, OS에 깔린 수 많은 응용프로그램들이 이 sqlite 라이브러리를 사용하고, 그것들은 모두 OS에서 기본 제공하는 sqlite 3.7 버전에 맞춰져있습니다. 그래서, 3.7을 3.11 이상으로 바꿀 때 어떤 다른 문제가 발생하지 아무도 모르는 상황입니다.

그래서, proj 6.3 버전을 사용하겠다면, sqlite 라이브러리부터 독립적으로 설치하고, proj 에서 사용하는 sqlite 라이브러리는 그것을 사용하게 해야합니다. 번거로운 일입니다.

다행이 postgis 3.0 버전에 proj 6.2.1 버전을 권장함으로 이 문제는 피해갈 수 있었습니다.

$ ./configure --prefix=/postgres/12/proj && make all && make install

잘 설치되었다면, 확인 삼아 sqlite 라이브러리를 잘 사용하고 있는지 확인해 봅니다.

$ ldd /postgres/12/proj/bin/proj
	linux-vdso.so.1 =>  (0x00007ffc83bfb000)
	libproj.so.15 => /postgres/12/proj/lib/libproj.so.15 (0x00007f7cac92c000)
	libsqlite3.so.0 => /lib64/libsqlite3.so.0 (0x00007f7cac677000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7cac45b000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f7cac154000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f7cabe52000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f7cabc3c000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f7cab86e000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f7cab66a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f7cacdb8000)

proj 실행 파일은 libproj.so 와, libsqlite3.so 동적 라이브러리를 사용하는데, libproj.so 는 새로 설치한 것을 사용하고, libsqlite3.so 는 OS 배포판에서 제공하는 것을 사용하는 것으로 확인되었습니다.

이 때, libproj.so 를 못찾거나, 설치한 곳이 아닌 다른 곳의 것을 쓸 것으로 확인되면 설치가 잘못된 것입니다.

sfcgal & cgal

제일 골치 아팠던 부분이었습니다.

sfcgal 은 cgal의 c++ 랩퍼입니다. cgal은 2d, 3d 이미지 처리용 라이브러리로, 다음에 소개할 gdal에서 사용하면 좀 gdal의 각종 이미지 처리가 좀 더 효율적일 수 있어, 가능하면 사용하면 좋겠죠.

그런데, sfcgal을 빌드하기 위해서도 OS 배포판의 여러 라이브러리들이 필요 합니다. 다음에 소개할 gdal도 그 외 또 여러 라이브러리가 필요해서, sfcgal까지 포함한 postgis 모듈은 정말 어마어마한 라이브러리 의존성을 가지게 됩니다.

이런 의존성 관리가 부담스럽다면, sfcgl을 생략해도 괜찮습니다. 일반적인 postgis 사용에서는 크게 문제가 되지는 않습니다.

그래도 설치하면,

일단 cgal 부터 설치해야하는데, 현재 버전은 5.0.1 인데, 이 버전은 CentOS 7 epel cmake3로는 빌드가 되질 않습니다.

cgal과 sfcgal 빌드는 일반적인 오픈 소스 빌드 방법이 아닌, cmake를 이용해서 빌드합니다. 게다가 CentOS 7 기본 패키지인 cmake 2.8 로는 빌드할 수도 없습니다. epel 저장소를 활성화 해서, cmake3 패키지를 설치해서 진행해야합니다.

# yum -y install epel-release
# yum -y install cmake3

위와 같이 cmake3를 준비하고, cgal-4.14.2 소스를 내려 받아 압축을 풀고

$ make build
$ cd build
$ cmake3 -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/postgres/12/cgal  .. 
$ make all && make install

작업으로 설치를 하고, sfcgal 설치도 같은 방법으로 합니다. sfcgal은 postgis에서 권고하는 1.3.7 버전으로 진행합니다. 이 때는 build 디렉터리를 만들어 진행하지 않고, 압축 파일을 푼 소스 최상위 디렉터리에서 진행합니다.

$ cd ...src/SFCGAL-1.3.7
$ CGAL_DIR=/postgres/12/cgal cmake3 -DCMAKE_INSTALL_PREFIX=/postgres/12/sfcgal -DCMAKE_BUILD_TYPE=Release .
$ LD_RUN_PATH=/postgres/12/cgal/lib64 make all && make install

여기서 신경 써야 할 부분은 cgal 설치 경로 지정은 OS 환경 변수고, 설치 prefix 값은 cmake 옵션입니다.

또한 make 작업에서 cgal 라이브러리를 참조할 수 있도록 만들어질 sfcgal 라이브러리의 rpath (동적 라이브러리를 찾는 경로) 지정할 필요가 있습니다.

OS 배포판에 설치된 c++ 컴파일 환경에서는 빌드 과정에서 nullptr 오류가 발생할 수 있습니다. 이 부분은 CMakeFiles/3.14.6/CMakeCXXCompiler.cmake 파일에,

set(CMAKE_CXX_STANDARD "11")

줄도 하나 추가해 주어야 합니다.

별 문제 없이 설치가 끝났다면, sfcgal 라이브러리가 참조하는 동적 라이브러리를 살펴봅니다.

$ ldd /postgres/12/sfcgal/lib64/libSFCGAL.so.1.3.7 
	linux-vdso.so.1 =>  (0x00007fffa5ded000)
	libCGAL_Core.so.13 => /postgres/12/cgal/lib64/libCGAL_Core.so.13 (0x00007fb162ceb000)
	libboost_thread-mt.so.1.53.0 => /lib64/libboost_thread-mt.so.1.53.0 (0x00007fb162ad4000)
	libboost_system-mt.so.1.53.0 => /lib64/libboost_system-mt.so.1.53.0 (0x00007fb1628d0000)
	libboost_serialization-mt.so.1.53.0 => /lib64/libboost_serialization-mt.so.1.53.0 (0x00007fb162664000)
	libboost_chrono-mt.so.1.53.0 => /lib64/libboost_chrono-mt.so.1.53.0 (0x00007fb16245c000)
	libboost_date_time-mt.so.1.53.0 => /lib64/libboost_date_time-mt.so.1.53.0 (0x00007fb16224b000)
	libboost_atomic-mt.so.1.53.0 => /lib64/libboost_atomic-mt.so.1.53.0 (0x00007fb162049000)
	libCGAL.so.13 => /postgres/12/cgal/lib64/libCGAL.so.13 (0x00007fb161e2f000)
	libmpfr.so.4 => /lib64/libmpfr.so.4 (0x00007fb161bd4000)
	libgmp.so.10 => /lib64/libgmp.so.10 (0x00007fb16195c000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb161740000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb161439000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fb161137000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb160f21000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fb160b53000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fb163a4c000)
	librt.so.1 => /lib64/librt.so.1 (0x00007fb16094b000)

libCGAL_Core, libCGAL 이 두 라이브러리가 소스를 컴파일해서 설치한 위치의 라이브러리를 참조해야합니다.

gdal

gdal 패키지는 위에서 다룬 세 라이브러리와는 차원이 다르게 거대 패키지입니다.

postgis에서는 래스터 자료(픽셀기반 이미지 자료)를 처리하기 위해서 이 gdal 라이브러리를 사용합니다. 여기서 알 수 있듯이 각종 변환 - 백터에서 래스터로, 그 반대로, 래스터 자료를 jpg, png 등 각종 이미지로, 각종 데이터베이스에 접속해서 자료를 뽑아서 각종 자료형식으로, 등등 수 많은 것을 할 수 있습니다. 이렇기에, gdal 라이브러리 자체가 온갖 라이브러리를 사용합니다.

gdal에서 제공하는 수 많은 기능을 사용하기 위해서는 결국 수 많은 라이브러리를 설치해야하는데, postgis에서 기본적인 래스터작업만 한다면, 일단은 가장 단순하게 설치하고, 추가로 더 필요한 것이 있을 때 gdal 패키지를 다시 빌드해서 쓰기로 하겠습니다.

gdal 패키지를 빌드하는 최소 옵션은

$ ./configure \
--prefix=/postgres/12/gdal \
--with-proj=/postgres/12/proj \
--with-geos=/postgres/12/geos/bin/geos-config \
--with-sfcgal=/postgres/12/sfcgal/bin/sfcgal-config

sfcgal 패키지 설치가 번거로워 만들지 않았다면, 빼도 상관 없습니다.

gdal 빌드 환경 설정 작업은 OS 배포판으로 설치된 패키지들이 있다면 위와 같이 특별히 옵션을 지정하지 않아도 추가 가능한 환경이면 자동으로 추가합니다.

이 빌드 환경 설정이 끝나면, gdal 빌드 요약 정보를 쭉 보여줍니다. 여기서 꼭 필요한 드라이버나 기능들이 있다면, 그 관련 라이브러리와 헤더를 설치하고, 다시 configure 작업을 하면 됩니다.

예를 들어, configure 요약 화면에,

LIBPNG support:            no

이렇게 보이는데, png 이미지 변환이 필요하다면, libpng, libpng-devel 패키지를 yum 명령으로 설치하고 다시 configure 작업을 하면 됩니다.

다음 make 하기 전, sfcgal 라이브러리를 사용한다면, 이 라이브러리에 대해서는 rpath 설정이 잘 안됩니다. 그래서, GNUmakefile 파일을 좀 수정할 필요가 있습니다. -R 옵션으로 sfcgal 라이브러리가 있는 경로를 지정해줍니다.

$(LIBGDAL):     $(GDAL_OBJ:.o=.lo)
        $(LD) $(LDFLAGS) $(LIBS) -o $@ $(sort $(wildcard $(GDAL_OBJ:.o=.lo))) \
            -rpath $(INST_LIB) \
            -R /postgres/12/sfcgal/lib64 \
            -no-undefined \
            -version-info $(LIBGDAL_CURRENT):$(LIBGDAL_REVISION):$(LIBGDAL_AGE)

make all && make install 작업이 무사히 끝났다면, /postgres/12/gdal/bin 디렉터리 안에 있는 실행 파일들의 동적라이브러리 의존성과, lib 디렉터리안에 있는 gdal 라이브러리 의존성도 함께 확인해 보면서, 의도하지 않게 OS 배포판 라이브러리를 사용하지는 않는지 확인이 필요합니다.

이제 대망의 postgis

postgis

앞에 모든 작업은 postgis 확장 모듈을 컴파일 하기 위한 준비 작업이었습니다. 앞에 작업에 아무런 문제가 없었다면, postgis 확장 모듈용 라이브러리 만들기는 비교적 쉽습니다.

약간 주의할 부분은 먼저 protobuf-c, json-c 이 두 라이브러리는 OS 배포판에서 공식 배포하기 때문에 yum으로 빌드에 필요한 패키지들을 미리 설치해두어야합니다.

# yum -y install json-c-devel protobuf-c-devel

또한 proj 패키지는 pkg-config를 이용한 빌드 환경 정보를 제공하기 때문에, configure 작업이 약간 다릅니다.

$  PKG_CONFIG_PATH=/postgres/12/proj/lib/pkgconfig:/usr/lib64/pkgconfig \
LDFLAGS="-Wl,-rpath,/postgres/12/geos/lib:/postgres/12/proj/lib:/postgres/12/sfcgal/lib64:/postgres/12/gdal/lib -Wl,--enable-new-dtags" \
./configure \
  --with-pgconfig=/postgres/12/bin/pg_config \
  --with-geosconfig=/postgres/12/geos/bin/geos-config \
  --with-gdalconfig=/postgres/12/gdal/bin/gdal-config \
  --with-sfcgal=/postgres/12/sfcgal/bin/sfcgal-config

PKG_CONFIG_PATH, LDFLAGS 환경 변수값이 추가되었습니다. postgis 모듈은 rpath 관련 설정이 따로 없기 때문에, 위와 같이 저수준으로 필요한 경로들을 임의로 지정했습니다.

또한 postgis는 PostgreSQL 설치경로에 필요한 파일들이 추가 되는 형태이기 때문에, prefix 설정 대신에 pg_config 설정을 합니다.

나머지는 다른 패키지 설치하는 것과 같습니다. make all && make install

설치된 실행 파일과 동적 라이브러리 파일의 라이브러리 의존성도 의도한 대로 잘 되었는지 확인해 봅니다.

postgis 모듈을 데이터베이스에서 사용하기

CREATE EXTENSION postgis

postgis 모듈이 잘 설치 되었다면, 데이터베이스 서버에서 CREATE EXTENSION 명령으로 해당 모듈을 등록해서 사용하면 됩니다.

$ psql
psql (12.1)
Type "help" for help.

postgres=# CREATE EXTENSION postgis;
CREATE EXTENSION

이 작업에서 정상적으로 모듈이 등록되지 않는다면, postgis 모듈을 정상적으로 설치하지 않았거나, 해당 모듈 라이브러리의 관련 동적 라이브러리를 불러 올 수 없는 경우입니다. 또는 불러오는 과정 속에서 엉뚱한 라이브러리를 불러오면서 특정 함수가 없다거나, 있는데, 로딩을 못하겠다는 경우가 생길 수도 있습니다.

이 CREATE EXTENSION 작업 실패를 푸는 방법은 ldd 가 푸는 열쇠입니다.

gdal 드라이버

래스터 자료를 다루기 위해, gdal 라이브러리를 포함해서 postgis 모듈을 만들었다면, (기본값) 이미지 변환 관련 작업을 gdal 라이브러리를 이용해서 할 수 있습니다. 이 때 사용할 각 이미지 처리용 드라이버를 지정할 수 있는데, 이것은 postgis.gdal_enabled_drivers 데이터베이스 서버 환경 변수로 지정할 수 있습니다. 즉 postgresql.conf 파일에 지정하거나, SET 명령으로 데이터베이스별, 세션별로 지정할 수 있습니다.

기본 값이 모든 드라이버를 사용하지 않음으로 되어 있기 때문에, 이미지 변환 관련 작업을 gdal 라이브러리를 통해서 하려면, 사용 가능한 드라이버들을 지정해 주어야합니다.

postgres=# SELECT * FROM st_gdaldrivers();
오류:  st_gdaldrivers() 이름의 함수가 없음
줄 1: SELECT * FROM st_gdaldrivers();
                    ^
힌트:  지정된 이름 및 인자 자료형과 일치하는 함수가 없습니다. 명시적 형변환자를 추가해야 할 수도 있습니다.
postgres=# CREATE EXTENSION postgis_raster;
CREATE EXTENSION
postgres=# SELECT * FROM st_gdaldrivers();
알림:  No GDAL drivers found
 idx | short_name | long_name | can_read | can_write | create_options
-----+------------+-----------+----------+-----------+----------------
(0 rows)

이런 상황에서는 st*gdal* 관련 함수가 정상 작동하지 않습니다. 그래서, 해당 서버는(또는 데이터베이스는, 또는 세션은) 사용할 수는 gdal 이미지 처리용 드라이브를 지정하는 작업을 해야합니다.

postgres=# SET postgis.gdal_enabled_drivers = 'ENABLE_ALL';
SET
postgres=# SELECT short_name FROM st_gdaldrivers();
     short_name
---------------------
 VRT
 DERIVED
 GTiff
 NITF
 RPFTOC
 ECRGTOC
 HFA
 SAR_CEOS
 CEOS
 JAXAPALSAR
 GFF
 ELAS
 AIG
 AAIGrid
 GRASSASCIIGrid
 ...
 ENVI
 EHdr
 ISCE
 HTTP
(141 rows)

이 set 작업은 postgresql.conf에 지정할 수 있고(reload로 반영 가능), 쉘에서 OS 환경 설정 값으로 지정할 수 있습니다.

export POSTGIS_GDAL_ENABLED_DRIVERS=ENABLE_ALL

이 설정은 반드시 데이터베이스 서버가 실행되는 쉘에 미리 지정되어야 있어야 서버가 시작되면서 이 설정값을 사용합니다.

postgis 버전 정보

이렇게 모든 것이 잘 설치되었다면, postgis 자신을 포함한 그 모듈이 사용하는 각종 라이브러리들의 버전 정보도 함께 살펴 볼 수 있습니다.

postgres=# \df postgis*version
                                  List of functions
 Schema |            Name             | Result data type | Argument data types | Type
--------+-----------------------------+------------------+---------------------+------
 public | postgis_full_version        | text             |                     | func
 public | postgis_gdal_version        | text             |                     | func
 public | postgis_geos_version        | text             |                     | func
 public | postgis_lib_version         | text             |                     | func
 public | postgis_libjson_version     | text             |                     | func
 public | postgis_liblwgeom_version   | text             |                     | func
 public | postgis_libprotobuf_version | text             |                     | func
 public | postgis_libxml_version      | text             |                     | func
 public | postgis_proj_version        | text             |                     | func
 public | postgis_raster_lib_version  | text             |                     | func
 public | postgis_svn_version         | text             |                     | func
 public | postgis_version             | text             |                     | func
 public | postgis_wagyu_version       | text             |                     | func
(13 rows)

이 글의 시작에서 권고한 각 라이브러리들의 버전들이 모두 원하는 것인지 확인해보세요.

마치며

일반적으로 postgis 이야기는 일단 postgis 깔렸다 치고, 자료를 어떻게 넣고, 조회하고, 지도를 어떻게 이미지로 만들고, qgis랑은 어떻게 만나서 사용하고, mapserver에서는 어떻게 쓰고, 등등의 이야기가 대부분입니다.

이 글에서는 그런 이야기 전에 망 분리된 폐쇄망 환경, yum 패키지 관리자를 이용하지 않는 환경에서 이렇게 복잡한 의존성을 가진 라이브러리를 어떻게 관리할 것인지에 대해서 다뤘습니다. 실무에서 이런 라이브러리 의존성이 꼬여서 생기는 장애는 참 자주 일어나거든요. 이 때 이 글이 조금이나마 도움이 되었으면 합니다.

작성일:2020-02-06 14:48, 수정일: 2020-02-12 22:27