폴리곤에 높이를 줘 표현하기

폴리곤에 높이를 줘서 입체적으로 표현하는 방법을 소개합니다. 일단 주어진 폴리곤 데이터는 아래와 같다고 가정을 합니다. 실제 적용된 결과는 높이값을 가진 폴리곤 데이터의 입체화 를 살펴보시길 바랍니다.

이 폴리곤에 일정한 높이값을 주어 아래처럼 표현하는 예를 통해 설명하겠습니다.

높이값을 주어 위의 그림처럼 표현하기 위해 옆면과 윗면을 높이값을 이용해 그려준 것 뿐입니다. 매우 간단하지요.. 끝?

하지만 이렇게 매우 단순하지 않습니다. 처음 폴리곤은 4각형이므로 옆면이 모두 4개인데, 이 4개의 옆면을 우리가 바라보는 시선 거리 중 긴것 순서대로 그려줘야 입체적으로 보입니다. 하지만 이것도 문제가 있습니다. 즉, 4개의 면이 모두 보이는게 아니고, 위의 경우는 딱 2개만 보입니다. 즉, 속도 효율성을 위해서 보이는 옆면만을 그리되, 그리는 순서는 시선의 거리가 긴것을 먼저 그려야 합니다. 시선의 거리가 길다라는 의미는 쉽게 말해.. 멀리 있는 옆면을 먼저 그려야한다는 것입니다.

결국 절차는 아래와 같습니다.

  1. 폴리곤을 구성하는 옆면들 중에 보이는 옆면만을 골라 낸다.
  2. 골라낸 옆면 중에 멀리 있는 것부터 순서대로 그린다.
  3. 마지막으로 윗면을 그린다.

먼저 옆면중에서 보이는 면만을 골라 내는 방법은.. 일단 시선축이라는 것을 정의해야 합니다. 시선축은 폴리곤을 구성하는 좌표 중에서 가장 작은 y값을 가진 좌표를 지나는 x축과 평행한 선분입니다.

위의 예 같은 경우는 아래의 그림처럼 시선축(빨간색 선)을 정의할 수 있습니다.

이제 다음으로 폴리곤을 구성하는 각 선분(위의 예는 4개의 선분)에 대해 그 선분의 중점과 시선축과 수직선을 그려 봅니다. 이 수직선을 시선방향선이라고 하겠습니다. 아래의 그림이 폴리곤을 구성하는 하나의 선분(빨간색)의 중심점에서 시선축으로 시선방향선을 그려본 것인데.. 폴리곤을 구성하는 4개의 선분 중에서 2개와 교차하는 것을 알 수 있습니다.

하지만 여기서 중요한 예외 사항이 있는데.. 그것은 처음 기준이 되는 폴리곤을 구성하는 선분과의 중점과 시선축과의 거리(SL)이 선분을 구성하는 시작점이나 끝점과 시선축과의 거리보다 작다면 시선방향선과 교차하지 않는다고 가정을 합니다. 결과적으로 위의 경우는 시선방향선이 2개의 선분과 만나지만 1개만 만나는 것이 됩니다.

아래는 나머지 3개의 선분에 대한 시선 방향선을 표시한 그림들입니다.

시선방향선과 만나는 선분이 2개인 경우
시선방향선과 만나는 선분이 2개인 경우
시선방향선과 만나는 선분이 1개인 경우(예외로 인해 1개의 교차점은 제외)

이를 토대로, 유추를 해보면.. 교점의 수가 홀수인 경우가 보이는 옆면이고 짝수인 경우는 않보이는 옆면이라는 것을 알 수 있습니다.

이제 보이는 옆면을 고르는 것은 끝났고, 두번째 절차인 골라낸 옆면 중에 멀리는 있는 것부터 그리는 것은 골라낸 옆면에 대해 거리값, 위의 설명에서 SL의 값을 이용해 내림차순으로 정렬하여 정렬된 순서대로 옆면을 그리면 됩니다.

그리고 마지막 세번째 절차는 단순히 기존의 폴리곤을 y축으로 높이 값만큼 올려 그려주기만 하면 됩니다.

이해가 되셨는지 모르겠습니다. 이해가 되지 않는 부분에 대해서는 댓글을 통해 물어보시길 바랍니다.

개발중인 맵 엔진의 지도 서비스 서버의 구조

잠시 정리하는 차원에서 그려본 현재 개발중인 맵 엔진의 서버측의 구조입니다. 아직 DataSource를 감시하는 Controller Service의 구현이 아직 않된 것과 각 DBMS별로 DB API가 구현되지 않은 것을 빼고 말입니다. 현재는 MySQL에 대한 DB API만 구현되어져 있습니다.  하지만 곧, 아래의 구조대로 구현되리라 봅니다.

요즘 드는 생각이… 개발중인 맵 엔진이 점차 완성되 가는 중간 단계에서 혼자 서는 하기 벅차다는 생각이 자주 듭니다. 개발중인 맵 엔진의 많은 부분이 분리가 되어져 있어져 있서 함께 분담해서 개발했으면 하는 바램과 아래의 경우처럼 각 DBMS 별로 DB API 개발을 누군가 같이 했으면 하는 바램도 무척 큽니다. 또한 XGE가 어느 정도 완성이 되면 분석기능과 같은개발중인 맵 엔진 단에 붙일수있는 확장 기능의 개발이 이뤄져야 하는데, 그때 과연 저 혼자 개발하여 정해진 시간안에 완전한 지원이 가능할까… 하는 걱정이 커져갑니다. 그래서.. http://www.gisdeveloper.co.kr/400 를 보시고 많은 지원을 해주시길..

  • XGE WebService는 XGE Web Server(IIS)에 별도의 스레드로 동작함
  • XGE DataSource는 XGE WebService의 요청에 대한 데이터를 수집해 전달함
  • XGE WebService는 XGE DataSource와 통신하기 위해 IPC 방법 중 PIPE를 사용함
  • XGE DataSource는 추상화된 DB API를 가짐
  • DB API의 기능은 DBMS 연결, 데이터의 읽기/쓰기임
  • 각 DBMS에 대한 DB API는 DB API에서 제공하는 스펙을 따라야하며, 스펙을 만족할 경우 어떠한 DBMS 든지 쉽게 활용할 수 있음
  • XGE DataSource Controller Service는 주기적으로 XGE DataSource의 상태를 점검함
  • 만약 XGE DataSource가 다운되었을 경우, Controller Service는DataSource를 재기동함

이미지 기반과 벡터 기반 지도 서비스의 적용 범위

이 글은 지도 서비스 방법으로 이미지 방식과 벡터 방식에 대한 장단점과 이런 장단점으로 인해 각각의 적당한 적용분야에 대한 개인적인 생각을 써본 글입니다.

초기 지도 서비스는 서버에서 클라이언트로 데이터를 전송해줄 때 좌표를 던져줌으로써 이 좌표를 이용해 지도를 화면상에 그려냈습니다. GIS의 초창기에는 이런 벡터 방식이 주류를 이루었으나, 지금은  이미 만들어 준비된 지도 이미지를 서버가 클라이언트에게 던져주고, 클라이언트는 이 이미지를 화면에 뿌려주는 방식이 대세가 되었습니다. 구글맵이 그렇고.. 콩나물, 네이버, 다음, 야후, MS 등등, 모두가 이미지 방식입니다. 그렇다면 이유는 무엇일까요?

  1. 속도가 빠르다.
  2. 클라이언트 개발이 간편하다.
  3. 클라이언트에 별도의 프록그램 설치(특히 말도 탈도 많다는 ActiveX)가 필요없다.
  4. Web2.0(특히 AJAX 기술)의 트렌드를 충족시킨다.

가장 중요한 것이… 이미지 기반은 벡터 기반에 비해 속도가 빠릅니다. 속도라 함은 클라이언트가 보고자 하는 지역의 좌표(MBR)를 넘겨주면 서버가 해당 지역에 대한 데이터를 찾아 전송해주고 클라이언트가 화면상에 그려주는데까지 얼마나 빨리 처리할 수 있느냐입니다. 벡터 기반의 경우 이런 처리에 대한 전체 흐름은 다음과 같습니다.

  1. 클라이언트는 원하는 지역의 좌표와 지역의 크기(이를 MBR이라 함)를 서버로 전송한다.
  2. 서버는 해당 지역의 데이터를 수집하는데, 데이터는 복잡한 공간검색(R-Tree나 Grid-File과 같은 공간검색 알고리즘 이용)을 사용하며 이 검색 방식은 많은 시간이 소모된다.
  3. 서버는 수집한 데이터를 클라이언트로 빠르게 전송하기 위해 데이터의 크기를 줄일 목적으로 데이터를 압축한다.
  4. 서버가 보낸 데이터가 압축되었다면 클라이언트는 받은 데이터를 압축해제 한다.
  5. 클라이언트는 받은 데이터(좌표, 속성 등)를 이용하고 지도 이미지를 직접 만들어 그린다.
  6. 클라이언트 측의 사용자는 자신이 요청했던 지도를 본다.

다음으로 이미지 기반의 처리 과정을 살펴보면 다음과 같습니다.

  1. 클라이언트는 원하는 지역의 좌표와 지역의 크기(이를 MBR이라 함)를 서버로 전송한다.
  2. 서버는 해당 지역에 대한 이미지를 찾는데, 해당되는 지역에 대한 파일의 찾기는 매우 단순하며 빠른다.
  3. 서버는 이미지를 바로 클라이언트로 전송한다.
  4. 클라이언트는 받은 이미지를 바로 그린다.
  5. 클라이언트 측의 사용자는 자신이 요청했던 지도를 본다.

처리 과정만을 살펴보더라도 벡터 기반에 비해 이미지 기반의 지도 서비스가 당연히 빠를 수 밖에 없다는 것을 알수 있지요.

그렇다면 이처럼 성능 좋은 이미지 기반의 지도 서비스가 아닌 벡터 기반의 서비스가 할 수 있는 기능은 무엇일까요..? 즉, 이미지 기반의 지도 서비스에서는 불가능한, 아니 매우 어려운 기능은 무엇일까요?

  1. 새로운 건물이 생겼을 때나 형태가 변경되었을 경우, 클라이언트에서 지도 편집
  2. 화면상에 표시된 지도에서 원하는 건물을 찍어 그 건물의 상세 내용을 살펴보는 기능
  3. 플롯터와 같은 출력기를 통해 큰 용지(A4 이상)에서 높은 품질의 지도 출력하기
  4. 건물을 제외하고 도로만을 화면상에 보는 것과 같은 원하는 지도 스타일 만들기.
  5. 건물 전용면적이 200평방 이상인 건물만을 화면상에 표시하여 지도 보기.
  6. 지도의 특정 주제를 가지는 요소 그룹을 사용자가 원하는 색상이나 형태로 표시하는 기능.
  7. 등등…

위의 기능이 왜 이미지 기반에서는 거의 불가능하고 벡터 기반에서는 가능한 이유는 무엇일까요? 그것은 단지 현재 보이는 지도에 대한 정보를 이미지 기반은 “이미지”로써만 가지고 있기 때문입니다. 이에 반해 벡터 기반은 지도에 대한 실제 정보로써 “지도 좌표”를 가지고 있다는 점입니다.

이러한 이미지 기반과 벡터 기반의 서로간의 장단점을 놓고 볼때.. 이미지 기반은 클라이언트 PC에 별도의 프로그램 설치 없이 원하는 지역을 빠르게 보여주는 서비스에 적당하며, 벡터 기반은 사용자가 원하는 지역에 대해서 좀더 다양한 기능, 즉 이미지 기반이 제공할 수 없는 기능, 좀더 전문적으로 말해 지도를 좀더 높은 수준에서 활용하고 응용하는 영역, GIS에 적당하다고 할 수 있습니다.

공간검색 알고리즘 문서

예전에 찾아서 한번(?) 읽어본 공간검색에 관련된 알고리즘 문서입니다. 깨끗하게 출판된 알고리즘 서적에 나와 있는 것보다 훨씬 더 나은, 더 정확한 정보를 얻을 수 있을 겁니다.

알고리즘은 다음과 같습니다.

  • R*-Tree
  • R-Tree
  • X-Tree

필요하신분은 한번 꼭 살펴보시길 바랍니다. 대부분… 이 알고리즘을 그대로 사용하지 않고 나름대로 약간 변형/응용하여 활용합니다. 참고로 살펴보시고 힌트로써 활용하여 자기 나름대로 적용을 하시길 바랍니다.