공간정보시스템 / 3차원 시각화 / 딥러닝 기반 기술 연구소 @지오서비스(GEOSERVICE)
www.biz-gis.com 이라는 사이트에서 가보시면, GIS를 이용한 분석기법을 중심으로 해서.. 다양한 GIS 데이터와 GIS 툴에 대한 사용법 등에 대한 글들이 많아, 국내 GIS에 관심이 많은 분들에게 매우 인지도 높은 사이트입니다. 이곳에 전국에 대한 등고선 데이터 SHP를 손쉽게 다운로드 받을 수 있는데요. 그 데이터를 다운 받아 개발중인 맵 엔진에서 올려본 화면입니다. 등고선 데이터 용량이 대략 450메가 정도 됩니다.
이미지를 클릭하시면, 원래 크기로 확대가 되는데, 그 상태로 보시길 바랍니다. 그냥, 기본값으로 Add Layer 했을 뿐인데, 참.. 이쁘게 잘 나온듯합니다~ ^^
개발하고 있는 GIS엔진인 XGE에 대한 웹서비스 개발 중간에 정리도 할겸, 글을 올려봅니다. 초반에 방향을 잘못잡아 헤매기는 했지만… 다른 방향을 선택해 개발에 박차를 가하고 있습니다.
윈도우즈 운영체제 기반의 XGE 웹서비스는 IIS를 웹서버로 하는 ISAPI Extension으로 개발 되었습니다. 참고로, 처음에 의도했던 바는 데이터 교환의 표준인 XML을 기반으로 하며 SOAP 프로토콜을 따르는 WebService을 기반으로 개발하려고 하였으나, 1메가 이상의 바이너리 데이터를 Base64 방식으로 XML로 인코딩하는데 소요되는 시간(6초 이상)이 문제가 되어 그 차선책으로 ISAPI를 선택하게 되었습니다.
ISAPI가 최신 기술인 WebService에 비교해 매우 과거의 기술이기는 하지만, 윈도우즈 운영체계에서 웹을 기반으로 하는 서비스 기술중에서는 가장 심플하고 빠른 기술이며, 윈도우즈의 WebService 역시 그 밑바닦은 ISAPI 기술을 이용해 구현되었고, .NET 기술중의 하나인 ASP.NET을 처리하는 모듈 역시 ISAPI로 구현되었습니다.
이러한 상황으로 미루어… 윈도우즈 운영체제 기반이라면, 웹서비스 모듈을 개발하는데 ISAPI를 선택해도 전혀 무리가 없다고 판단되었습니다. 여타 다른, 특히 유닉스 계열의 플렛폼을 지원하지 못한다는 최악의 시나라이오가 있기는 하지만 말입니다.
XGE 웹서비스를 개발할때 고려했던 점은 아래와 같습니다.
순서를 뒤집에 이야기 해보면, 요청에 빠르게 응답하기 위해 ISAPI를 선택했으며… XGE의 특성상 지도 데이터를 빠르게 쿼리하는 것이 중요해서, 이미 빠르게 필요한 지역에 대한 데이터를 수집할 수 있도록 개발되어 나름대로 요청에 대해 빠르게 응답(최악의 상황에서도 0.02초 이내)합니다.
그리고 어떤 상황에서도 죽지 않도록 하기 위해 작업 단위를 프로세스 기반으로 적절히 분배했습니다. 즉 ISAPI로 개발한 XGE 웹서비스는 클라이언트의 요청을 받고 이 요청에 대한 데이터 수집을 직접 하지 않고 DataSource라는 별도의 프로세스로 책임을 위임하고 이렇게 수집된 데이터를 다시 받아서 클라이언트로 전송해주는 역활만 합니다. 즉, ISAPI로 개발된 XGE 웹서비스는 다음과 같은 일만을 합니다.
요청을 받고.. 그 결과를 보내주는 것 자체는 ISAPI에 있어서 매우 기본적인 연산입니다. 즉, XGE 웹서비스는 매우 기본적인 연산만을 한다는 것이지요. 이렇게 하면 XGE 웹서비스가 어떤 연산으로 인해 다운되는 일은 거의 없다고 볼 수 있습니다. 별다른 연산은 모두 다른 프로세스에게 위임을 하니까 말입니다. 그리고 연산을 위임받은 DataSource 프로세스는 별도의 실행파일로 만들었습니다. 원한다면 서비스 방식으로 만들어도 되겠지요. 좀더 편리한 UI 제작을 위해 어플리케이션 형태의 실행파일로 만들었고, 이 DataSource가 하는 일은 XGE 웹서비스가 요청한 지도 데이터를 조회해서 바이너리 데이터 덩어리로 묶고(Pack) 다시 XGE 웹서비스로 보내줍니다. 지도 데이터를 조회하는 연산은 내부적으로 다소 복잡한데, 어떤 잘못된 연산으로 DataSource 프로세스가 다운될 수가 있습니다.
위의 그림에서는 언급되지 않았지만, 이럴때를 위해 Monitor 프로세스가 존재하며 이 XGE Monitor 프로세스가 하는 일은 DataSource 프로세스가 살아있는지를 일정한 시간 간격으로 검사하고 죽어있다면 다시 DataSource 프로세스를 살려주는 역활을 합니다. 역활에 따라 적절하게 프로세스로 분리한 이러한 구조로 어떤 상황에서도 죽지 않는다라는 이상적인 목표에 많이 접근할 수 있을 것으로 판단됩니다. 끝으로 XGE 웹서비스는 매우 구조가 간단합니다. 구조가 간단하기에 안정성과 빠른 응답성은 물론이고 확장성의 이점까지 두루 얻을 수있습니다. 일단 위의 그림 역시 매우 간단한 구조인데, 이 그림을 구성하고 있는 XGE 서비스와 DataSource 프로세스에 대한 구조에 대한 그림을 살펴보면, 얼마나 간단한지 알 수 있을겁니다.
위의 그림은 UML 중 Class Diagram입니다. 실제로 개발한 프로젝트에서 사용한 클래스의 모든 것입니다. 물론 기능 확장등으로 몇가지 더 추가되겠지만.. 요청과 그에 대한 처리라는 관점에서 봤을때 새로운 클래스를 추가하는 상황은 최대한 배제하도록 설계가 되었습니다. 이러한 설계의 단순함으로 인해 전체적으로 구조가 간단해졌으며, 앞서 언급한 안정성, 빠른 응답성, 확정성의 이점을 얻을 있겠지요. (참고로 위의 UML은 StarUML로 작성했습니다. 국산 공개 소프트웨어)
약 2주전쯤에 나온 결과물입니다. 아직은 만족스럽지 않은 결과인지라 올리지 않았는데요. 이번주부터 새로운 기능을 하게 되서 일단 정리차원에서 올립니다. 원본 이미지는 훨씬 큽니다. 클릭해 원본 크기로 봐주시길 바랍니다.
분위기는 밝은 파스텔 톤입니다. 이미지 심벌과 문자 라벨을 좀더 적절하게 적용하면 훨씬 나은 결과가 나오리라 기대해 봅니다. GDI+만을 사용했는데요. 처음엔 속도 문제가 걸려 일단 GDI+ 이전의 그리기 API인 GDI를 지원했습니다. 옵션에 따라 GDI+로 그릴때와 GDI로 그릴때로 구분해 줄 수 있습니다. 하지만 지금은 속도 문제보다는 느낌이 훨씬 더 나은 GDI+만을 사용하도록 되어 있습니다. 예전부터 느낀 것이지만 GDI+는 괜찬은 그리기 API라는 생각입니다. 위의 화면에 나타나지 않았는데… XGE의 그리기 기능 중에 하나인 복합심벌이 있습니다. 예를 들어서 단순한 라인인데.. 이 라인이 철도를 의미한다면 아래처럼 그려줄 수 있습니다.
XGE에 이번에 추가한 밀도계산 기능을 ArcGIS와 비교해 보았습니다. 아래는 ArcGIS의 Simple 방식의 밀도 분석입니다. 주제는 “교육”입니다. 학교의 분포이겠지요.
참고로 XGE는 국내 최고의 비지니스 GIS 솔루션 기술을 가진 GIS 전문 회사((주)오픈메이트)가 보유한 GIS 엔진의 차기 버전입니다. XGE는 현재 개발단계인지라.. Code Name이고, 추후 멋드러진 이름을 갖게 되겠지요~ ^^
아래는 동일한 데이터.. 즉, 위에 대한 XGE의 결과입니다.
밀도 계산중 심플 방식은 속도는 매우 빠르지만, 그 결과는 그리 Nice~ 하지 않습니다. 아래는 실제 밀도 계산에서 가장 많이 쓰이는 Kernel 방식이며 ArcGIS에서 얻은 결과입니다. 심플 방식에 비해 결과가 Nice~ 하지요..
아래는 위와 동일한 데이터와 밀도 계산을 위한 변수(셀해상도, 계산반경)에 대한 XGE의 결과입니다. 배경이 검정인 이유는 검색반경에 영향을 받지 않아 Null Value인 셀입니다. ArcGIS의 경우 이 Null Value인 셀에 대해서는 가장 낮은 값으로 할당한 색상으로 표현하고 있습니다.
아래는 서울 지역에 대한 은행분포를 나타낸 Kernel 방식의 밀도 계산이며 모두 XGE로 얻은 결과입니다. 감상(?) 해보시길 바랍니다. ^^ ArcGIS에서처럼 Null Value인 셀에 대해서도 최하위 단계의 색상으로 표현하고 있습니다.
보시면 은행이 중구에 가장 많이 밀집되어있고 그 다음에 강남구 쪽에 많이 밀집되어 있다는 것을 알 수 있습니다. 밀도 분석은 2차원에서 그 분포에 대한 가중치를 구해 다양한 분석에 활용될 수 있는 조건 계산법입니다.