"지아이에스엔진"을 누구나 이해할 수 있도록 정의하고 싶습니다. 가능할까요?

공공정보화사업 부문에 편중될 수 밖에 없는 공간정보산업의 영세함으로, 접하게 되는 고객의 대부분은 공공부문에 근무하고 계십니다. 프로젝트 관련하여 많이 받게되는 질문은 "GIS Engine은 어떤 것을 사용합니까?" 입니다. 수행해야 하는 프로젝트가 물품구매 형식의 GIS Package SW 납품이라면 쉽게 답할 수 있습니다. 그러나 보통 공간정보 분야 용역사업은 어떤 목적을 이루기 위한 개발 사업입니다.
필자는 "GIS Engine" 이 무엇이지 쉽게 설명하고 싶은데 사전에서 찾을 수 없습니다. 물론 Wikipedia에서도 찾을 수 없는 Local 정의어 입니다. 어떻게 표기를 해야할지도 모르겠습니다. 

인터넷 탐색으로 Arcgis Engine의 정의는 찾을 수 있습니다.
"ArcGIS Engine is a complete library of embeddable GIS components for developers to build custom applications"

전문보기 : What is ArcGIS Engine?

ArcGIS 엔진은 개발자가 GIS 응용 어플리케이션 개발을 할 수 있도록 지원하는 컴포넌트의 집합인 것 같습니다. 그렇다면 GIS엔진은 흔히 말하는 경로찾기, 지오코딩 등 수많은 서비스 또는 컴포넌트가 언어나 사용자 환경에 상관없이 호출되어 사용될 수 있도록 하는 어떤 것들의 집합이라고 정의할 수 있을까요? 어렵습니다. 여기에도 모순은 존재합니다.
안타깝게도 저에게 질문을 던진 고객은 공무원 이며 개발자가 아닙니다. 아무리 좋은 컴포넌트를 준다고 한 들 사용할 수 없습니다. 또한 프로젝트 결과물의 최종 사용자도 대부분 일반 사용자이거나 공공기관 업무용 SW로 공무원을 대상으로 합니다. 이 분들은 절대 개발을 하지 않습니다. 컴포넌트 집합이라고 정의하면 사용자가 너무 한정됩니다.

일반적으로 GIS SW 또는 공간정보 분야 서비스 어플리케이션은 아래와 같이 구성됩니다. 저는 사용자 UI를 가지고 GIS Data에 대한 CRUD가 발생하기 위해 대부분 3계층으로 구성합니다.

1. 데이터를 제공하는 "Data Provider 계층" ==> 서버영역
2. 데이터를 처리하는 "Process 계층" ==> 서버, 클라이언트 영역
3. 데이터를 보여주는 "Presentation 계층" ==> 클라이언트 영역

3계층으로 구성되는 배치 구성을 통해 GIS Engine을 정의할 수 있을까요? 위의 3가지가 유기적으로 연결되는 것은 특정 비즈니스 목적에 맞도록 어플리케이션이 제작되는 것입니다. 이는 주문형 SW로 특정 업무분야(재난, 교통, 통계,...)에 최적화되는 것으로 GIS엔진이라고 정의하기는 무리가 있습니다. 

"Data Provider" 계층은 파일시스템 또는 DBMS 영역으로 독립적 구성을 가집니다. 공간속성을 가지는 GIS Data는 "Data Provider"계층에서 수용해야하는 많은 종류의 데이터 중 단지 하나일 뿐입니다. 범용성, 활용성 등을 고려하면 오히려 GIS엔진보다 훨씬 넓은 영역입니다. 

"Process"계층은 어쩌면 GIS엔진이라고 정의할 수 있을 것 같습니다. 흔히 말하는 공간연산 등 굳이 공간정보를 다루는 특화된 기능이 적재될 수 있는 공간입니다. 여기에도 모호한 부분이 존재합니다. 공간정보를 다루는 기능의 구현형식이 XML Web Service, Restful Service,.. 무엇이 되든 결국은 개발자 또는 전문가를 대상으로 하고 단독으로는 존재할 수 없는 문제가 있습니다.

"Presentation"계층은 GIS엔진이라고 정의할 수 있을까요? 이 또한 어려워 보입니다. Presentation계층에서 가장 중요한 것은 Data 시각화 입니다. 최근의 정보화 추세는 Thin Client 방식의 구성을 선호합니다. 당연히 데이터 영역과 시각화 영역을 분리합니다.
업무 목적에 따라 같은 데이터라도 시각화 형식은 다를 수 있습니다. 시각화의 목적은 데이터를 통해 Insight를 얻는 것입니다. 이는 보통 "BI(Business Intelligence"라고 말하며 그 부분에 공간정보의 시각화도 포합됩니다.

일반적으로 말하는 GIS정의만으로 어떤 목적을 설명하기는 어렵습니다. 빅데이터가 생산되는 최근의 정보 환경에서 하나의 기술 또는 정의만으로 목표를 달성하기는 너무 어렵습니다. 실제 요즘 모든 분야에서 GIS 기술은 활용되고 있습니다.
최근 코로나 바이러스 상황에서 코로나 지도가 바로 인터넷에 공개되는 것은 GIS기술이 얼마나 빠르게 수요시점에 적용될 수 있는가를 말하고 있습니다. 이러한 수요란 공급자가 아닌 사용자가 결정하는 것으로 GIS 엔진의 필요성이나 기능은 사용자 환경에 따라 다를 수 있습니다.

확실한 한가지는 타 기술 분야와 융합될 수 있는 유연함이 GIS엔진이 가져야하는 조건입니다. 필자의 20년 경험으로 GIS엔진을 정의할 수 없네요.두서없이 길었지만 필자가 전하는 의견은 단 하나입니다.

무얼 만들지, 누구를 위해 만들지가 중요한 것 같습니다. GIS엔진의 모호한 정의는 자칫 프로젝트를 어렵게 할 수 있습니다. 애매모호한 요청에는 두리뭉실한 답변이 갈 수 밖에 없습니다. 굳이 공공정보화사업이라면 GIS엔진을 말하기보다는 이루고자하는 가치를 명확히 하는 것이 중요합니다.
GIS엔진(?)은 그 다음에 고민하는 것이 맞을 것 같습니다. 공간분석이라는 그 들만의 리그에서 벗어나야 하지 않을까하는 소견을 밝히며 마무리합니다.

개요

필자는 흔히 현장에서 GIS엔진이라고 말하는 미들웨어의 도입을 강력히 반대하는 입장입니다. 대부분의 2D GIS 사이트에서 GIS엔진은 성능을 떨어뜨리는 원인이기 때문입니다.
정보시스템은 정보저장 및 조회의 편의를 위하여 DBMS와 함께 동작합니다.(일부 예외는 존재합니다) 꽤 오래전부터 DBMS는 SDE(Spatial Data Extension)를 통해 공간데이터에 특화된 기능 및 함수를 제공합니다. SDE은 강력한 공간분석도구 입니다. 이의 활용을 통해 별도 미들웨어 없이 SQL만으로 Geo Processing을 수행할 수 있고 수행결과는 DBMS에 테이블 형식으로 정의함으로써 데이터 저장구조를 전체 시스템 수준에서 동일하게 가져갈 수 있는 장점이 있습니다.

공개SW인 PostGIS를 이용하여 경계분할을 진행합니다. 별도의 솔루션이 아닌 오직 DBMS가 지원하는 함수만을 이용합니다. 과정별 생성되는 데이터는 Qgis에서 확인했습니다.

본 글에서는 "보로노이다이어그램"을 이용하여 경계를 나누어 각각이 동일 면적에 근접하도록 분할하는 기법을 설명합니다. 이해를 위해 "보로노이 다이어그램"을 이해하셔야 합니다.

> 보로노이다이어그램 1 : 위키피디아
> 보로노이다이어그램 2 : 네이버캐스트

또한 K-Means 알고리즘에 대한 기반 지식 또한 요구됩니다.

> K-평균 알고리즘 : 위키피디아
> K-평균 군집화 : 티스토리(untitledblog)

이하 기술되는 SQL의 실행을 위하여 PostGIS의 GEOS 버전이 2.3.0 이상 이어야 합니다. 아래의 질의를 통해 PostGIS의 버전을 확인하고, 만일 기준을 충족하지 않을 경우 PostGIS를 업그레이드 하십시오. 간단한 설치 명령어만으로 쉽게 업그레이드 할 수 있습니다. 별도 설명하지 않겠습니다.

본문

본 게시글에서 사용하는 PostGIS 함수는 다음과 같습니다. 상세 설명은 공식 사이트의 도큐먼트를 참조하십시오.(필독)

경계 분할 시행

1. 경계준비 : 시도경계 테이블에서 서울시 경계만을 추출한 별도 테이블 생성 (생략가능 과정)
CREATE TABLE seoul AS
    SELECT * FROM ngii_cdm_4326 WHERE bjcd = '1100000000';

2. 서울 경계 내에 존재하는 랜덤 포인트 셋 생성 : 포인트 개수가 많을 수록 최종 생성되는 분할 경계의 면적은 동일 값에 수렴
CREATE TABLE seoul_pts AS
    SELECT (ST_Dump(ST_GeneratePoints(geom, 10000))).geom AS geom FROM seoul WHERE bjcd = '1100000000';

3. K-Means 알고리즘을 이용한 군집화
CREATE TABLE seoul_pts_clustered AS
    SELECT ST_ClusterKMeans(geom, 10) over () AS cluster_id, geom FROM seoul_pts;

4. 클러스터 별 중심점 생성
CREATE TABLE seoul_pts_clustered_center AS
    SELECT cluster_id, ST_Centroid(ST_collect(geom)) AS geom FROM seoul_pts_clustered
    GROUP BY cluster_id;

5. 중심점을 기준으로 보로노이 다각형 생성
CREATE TABLE seoul_voronoi AS
    SELECT (ST_Dump(ST_VoronoiPolygons(ST_collect(geom)))).geom AS geom FROM seoul_pts_clustered_center;

6. 서울 경계와 보로노이 경계의 폐합 폴리곤 경계 생성
CREATE TABLE seoul_divided_result AS
    SELECT ST_Intersection(a.geom, b.geom) AS geom FROM seoul a
    CROSS JOIN seoul_voronoi b;

마치며

본 블로그의 카테고리 중 "꿀팁-PostGIS"가 상대적으로 빈약했습니다. 카테고리의 빈부격차를 줄이고자 임의의 시나리오를 만들어 게시글을 작성했습니다. 하지만 전하고자하는 메시지는 명확합니다.

공개SW가 보여주는 기능 및 성능은 필자를 많이 놀라게 합니다. 본 게시글에서 설명한 류의 Geo-Processing을 수행해야 한다면 저는 Shell Script를 만들어서 이를 호출하는 것으로 개발 코드를 많이 줄일 것 같습니다. 기능을 이행하는 수단은 한가지가 아니겠지만 가장 좋은 것은 이미 존재하여 검증된 것을 잘쓰는 것입니다. PostGIS는 이미 시장에서 검증되어 기술성숙도가 높은 공개SW입니다.

GIS엔진, 오라클이라는 굴레만 벗어난다면 가성비 좋은 아주 훌륭한 앱을 제작할 수 있습니다.