DuraMap-Xr에 대한 공간 편집 기능 문의가 있어 간단하게 만들어 본 동영상을 공유해 봅니다. SHP 파일에 대한 편집 내용으로.. 크게 새로운 공간 데이터 추가와 기존 데이터의 편집 기능을 소개하고 편집 기능에서 매우 활용도가 큰 정점(Vertex)와 선분(Edge)에 대한 스냅(Snap) 기능과 편집된 이력에 대한 Undo/Redo에 대한 시연 내용으로 구성되어 있습니다.

공간 데이터를 처리하는 DBMS는 포인트, 폴리라인, 폴리곤과 같은 공간 좌표 데이터를 효율적으로 저장하기 위해 BLOB 타입으로써 WKB라는 형태로 저장합니다. 개발하고 있는 지도 렌더러를 위한 맵엔진(코드명: Xr)에서 사용할 수치지도 데이터 포맷에 대해 고민하던 차에... GIS 데이터 표현의 범용 표준 중에 하나인 WKB에 대한 자료를 정리해 보았습니다.

WKB, 즉 Well-known Binary는 OpenGIS 스펙에 의해 정의된 지오메트리 값을 표현하기 위해 사용됩니다. KWB는 지오메트리 WKB 정보를 담고 있는 BLOB 타입의 값으로 표현되는 바이너리 스트림으로써 지오메트리 데이터를 상호간에 교환하기 위해 사용됩니다. WKB는 1바이트의 부호없는 정수와 4바이트의 부호없는 정수 그리고 8바이트의 배정밀 소수(IEEE 754)를 사용합니다. 여기서 1바이트는 8비트입니다.

예를 들면... WKT인 POINT(1 1)을 동일한 WKB로 변환해 본다면... 다음과 같은 총 21개로 구성된 연속된 바이트입니다.

0101000000000000000000F03F000000000000F03F앞의 연속된 바이트를 해석 해보면... 다음과 같습니다.

즉, 첫번째 1바이트의 값이 1이면 바이트 정렬이 Little-Endian이며 0이면 Big-Endian이라는 의미입니다. 그리고 다음 2바이트는 지오메트리 타입으로써 현재까지 제안된 타입은 총 7개로써 Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon 그리고 GemetryCollection입니다. 끝으로 포인트의 좌표인 X와 Y 값이 각각 8바이트씩 오게됩니다.

앞의 예는 Point 타입에 대한 예이며 다른 지오메트리 타입에 대해서, 보다 직관적이고 효율적으로 파악하기 위해 C언어의 구조체 형식으로 보면 다음과 같습니다.

// Basic Type definitions // byte : 1 byte // uint32 : 32 bit unsigned integer  (4 bytes) // double : double precision number (8 bytes) // Building Blocks : Point, LinearRing   Point {     double x;     double y; }; LinearRing   {     uint32 numPoints;     Point points[numPoints]; }; enum wkbGeometryType {     wkbPoint = 1,     wkbLineString = 2,     wkbPolygon = 3,     wkbMultiPoint = 4,     wkbMultiLineString = 5,     wkbMultiPolygon = 6 }; enum wkbByteOrder {     wkbXDR = 0, // Big Endian     wkbNDR = 1 // Little Endian }; WKBPoint {     byte byteOrder;     uint32 wkbType; // 1=wkbPoint     Point point; }; WKBLineString {   byte byteOrder;   uint32 wkbType; // 2=wkbLineString   uint32 numPoints;   Point points[numPoints]; };   WKBPolygon {   byte byteOrder;   uint32 wkbType; // 3=wkbPolygon   uint32 numRings;   LinearRing rings[numRings]; }; WKBMultiPoint {   byte byteOrder;   uint32 wkbType; // 4=wkbMultipoint   uint32 num_wkbPoints;   WKBPoint WKBPoints[num_wkbPoints]; }; WKBMultiLineString {   byte byteOrder;   uint32 wkbType; // 5=wkbMultiLineString   uint32 num_wkbLineStrings;   WKBLineString WKBLineStrings[num_wkbLineStrings]; };   wkbMultiPolygon {   byte byteOrder;   uint32 wkbType; // 6=wkbMultiPolygon   uint32 num_wkbPolygons;   WKBPolygon wkbPolygons[num_wkbPolygons]; };   WKBGeometry  {   union {     WKBPoint point;     WKBLineString linestring;     WKBPolygon polygon;     WKBMultiPoint mpoint;     WKBMultiLineString mlinestring;     WKBMultiPolygon mpolygon;   } }; 바이너리는 크기면에서 데이터를 매우 최적화된 형태로 저장할 수 있는 포맷입니다. GIS 엔진을 설계하고 개발할때 자체 엔진에 특화된 데이터 구조를 설계하는 것 대신에 이러한 표준을 수용할 경우 얻을 수 있는 이점은 매우 크다고 할 수 있겠습니다.

이 글의 일부는 다음 URL에서 참고하였습니다.
http://dev.mysql.com/doc/refman/5.0/en/gis-wkb-format.html

오늘 급작스레 구현해 본 기능인데... 어떤 공간 위에 여러가지 데이터를 가지고 분석한 결과를 표출할때... 배경이 되는 지도와 분석 결과가 뒤섞여... 분석 결과가 한눈에 들어오지 않는 경우가 있는 듯합니다.

그래서 배경이 되는지도의 색상을 빼고, 분석 결과만 색상을 적용하도록 했습니다. 물론.. 사용자가 원하는 시점에서 배경 지도의 색상을 적용하고 뺄 수 있도록 한 것이구요. 매우 단순한 아이디어지만... 사용자에게는 매우 좋은 기능으로 생각됩니다..

위의 이미지는 배경지도위에 어떤 주제를 가지는 밀도 분석 결과를 함께 표현한 것입니다. 지도 엔진은 오픈메이트의 지도 엔진인 XGE를 이용해서 밀도 분석은 XGE에 플러그인할 수 있는 확장 기능으로 수행했습니다.

참고로... 위의 이미지에 해당하는 프로그램인 Clone은 XGE를 이용해 만든 간단한 C/S 프로그램입니다. 여러가지 공간분석기능을 기본도 위에서 수행할 수 있는 GIS 분석용 프로그램입니다. 언제 시간이 되면... XGE를 이용해 만든 여느 프로그램처럼... 소스를 공개할 예정입니다.

개발 맵 엔진의 확장 기능 중에 밀도 분석에 대한 기능이 있습니다. 지도 엔진을 설계할 당시에 파일럿 성격으로 만들고, 이를 별다른 고민이나 개선없이 확장 기능 단으로 수용을 해서인지... 여러가지로 문제가 있었나 봅니다. 문제가 꽤 되는데.... 그 중에 2가지만 언급한다면...

• 적은 포인트의 개수에 대해 밀도 그림으로써 의미가 없는 결과를 냄
• 기존에 존재 하는 GIS 밀도 분석 기능(ArcGIS)에 비해 속도가 매우 느림

먼저 첫번째에 대해서는 이런 저런 고민으로 절충안을 내어 개선을 했습니다. 실제로 이전의 개발 맵 엔진의 밀도분석에 대한 확장 기능으로 포인트 수가 10개정도 되는 공간을 대상으로 수행해 보면, 전혀 엉뚱한 결과가 도출되었습니다. 아래는 개선되기 이전의 결과 입니다.

2009년 2월 11일 변경된 구글지도서버의 내용을 반영해, 정상적으로 작동하도록 하였습니다. 소중한 정보를 제공해준 이사돌이님께 감사를 드립니다. E-Mail이나 블로그 링크를 공개하지 않으셔서 이 자리를 통해 감사의 말씀을 드립니다. 또한 소스까지 공개합니다. 아무쪼록 필요하신 분에게 도움이 되시길 바랍니다.

구글에서 제공하는 구글맵 OpenAPI에 대한 관심이 저를 제외하고 매우 뜨거웠던 모양입니다. 관심을 갖게된 배경은 회사에서 개발하고 있는 엔진에 다른 회사에서 제공하는 OpenAPI를 통해 제공하고 있는 지도를 적용해보면 어떨까 하는 생각에서 접근을 하게 되었습니다. 구글맵을 통해 OpenAPI를 접해보는 순간... 머리속에 하얗게 되는것을 느꼈습니다. 웹이라면 단순이 html 정도와 자바스크립트 그리고 근사한 이미지나 플래시로 치장하는게 전부라고 생각했기 때문입니다. OpenAPI는 많은 사람들에게 공개된 API인지라 사용하기가 매우 쉬웠습니다만, 개발자로써 내부적으로 어떻게 구현했느냐를 모르니 참... 우울해지더군요. 바로 자바스크립트 관련 책을 주문하고 OpenAPI와 AJAX와 같은 흐름을 대표하는 Web2.0에 찬찬히... 개발자로써 접근을 시도해 보고자 다짐하게 되었습니다.

뭐 여튼... 처음으로 돌아가, 원래의 목적을 완수하고 위해.. 구글맵을 엔진단에 통합하는 방법을 연구하던 중에, 그 중간 결과로 만든 것을 소개해 드릴겸해서 글을 작성합니다. 구글맵은 경도와 위도값을 주게 되면 그 지점에 대한 이미지를 던져주는데, 이 이미지의 크기는 256 x 256 입니다. 이 이미지를 타일이라고 합니다. 구글맵에는 해상도 레벨에 대한 개념이 있습니다. 1~18 단계로 되어 있고 1단계는 하나의 타일에 전세계가 보입니다. 18단계는 최대로 확대한 타일이미지로 18단계에 해당되는 타일의 개수는 엄청나겠지요. 이런 구글맵에서 제공하는 지도를 활용하기 위해서는 원하는 지점에 대한 타일을 얻는 것이 시발점이 됩니다. 그런데 문제는 이 원하는 지점을 어떤식으로 접근할 것이냐인데... 우리 나라 GIS계에서 사용하는 좌표계는 카텍입니다. 원래 카텍은 CNS 분야에서 사용하는 좌표계인데 원점이 하나인지라... 직각좌표계에서 경위도로 변경할때 원점을 고민할 필요가 없습니다. 바로 이 카텍 좌표를 이용해서 구글이 사용하는 경위도 좌표로 변환하고, 이 변환된 경위도 좌표를 구글맵 서버에게 넘겨줘서 해당 지점의 타일을 받아오면 됩니다.

먼저 구글맵은 WGS84 경위도 좌표계이고 우리나라에서 많이 사용하는 좌표계는 베셀 TM 직각좌표계의 원점을 하나로 한 카텍좌표계입니다. 먼저 경위도 좌표를 카텍과 같은 직각 좌표로 변환하는 방법과 그 반대로 변환하는 방법이 필요한데, 이 부분에 대한 방법은 gTrans라는 Visual Basic으로된 소스를 참고로 하여 작성을 하였습니다. 하지만 이 코드는 카텍좌표에 대한 언급이 전혀 없습니만... 타원체와 투영 그리고 변환공식 등에 대한 기본적인 내용을 숙지 하고 있다면 카텍 좌표계로의 변환은 그리 어렵지 않습니다. 비주얼 베이직으로 된것을 C++으 변환하는게 시간적으로 어려울 뿐이지요. 대학원때 GPS를 분석해보며 살펴봤던 좌표변환이 이제서야 큰 도움이 되더군요. 참고로 카텍 좌표계는 TM128이라고 하는데, 원래 우리나라에서 사용하는 TM 좌표계와 다른 점은 아래와 같고 다른 점은 모두 동일합니다.

central scale : 0.9998 or 0.9999

central meridian : E 128 00 00

Origin Latitude : N 38 00 00

False Easting (meters) : 400000

Falsle Northing (meters) : 600000

tstGoogle.exe 265630 88249 11 d:/제주도.jpg

tstGoogle.exe 541018 385821 5 d:/꼬리.jpg

bin_tstGoogle.zip

src_tstGoogle.zip

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

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

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

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

시선방향선과 만나는 선분이 2개인 경우

시선방향선과 만나는 선분이 2개인 경우

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

꽤 오래전부터 이 기능을 추가해야지 하고 벼르던 차에.. 회사에서 수주한 프로젝트에서 실제로 이 기능이 적용되어야 한다고 하여.. 이제서야 추가하게 되었습니다.

나름대로 만족스럽기는 하지만... 실제 프로젝트에 적용되었을 경우에 한가지 큰 개선이 필요합니다. 그 개선은... 높이값을 가진 폴리곤 레이어가 하나가 아닌 여러개의 레이어로 구성되었을때 여러개의 레이어들의 각 폴리곤들을 옳바른 순서대로 그려내도록 하는 것입니다. 물론 여러개의 레이어를 하나의 레이어로 합쳐 버리면 될 일이지만...

게다가 이 글을 포스팅 하려고 지도이미지를 캡쳐받았는데... 바로 버그가 눈에 띱니다.. =_=;

• 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

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

spatial_query-algorithms.zip

www.biz-gis.com 이라는 사이트에서 가보시면, GIS를 이용한 분석기법을 중심으로 해서.. 다양한 GIS 데이터와 GIS 툴에 대한 사용법 등에 대한 글들이 많아, 국내 GIS에 관심이 많은 분들에게 매우 인지도 높은 사이트입니다. 이곳에 전국에 대한 등고선 데이터 SHP를 손쉽게 다운로드 받을 수 있는데요. 그 데이터를 다운 받아 개발중인 맵 엔진에서 올려본 화면입니다. 등고선 데이터 용량이 대략 450메가 정도 됩니다.

밀도계산의 방식은 Simple 방식과 Kernel 방식이 있습니다. 이 두방식에 대해 ArcGIS에서 처리된 결과 이미지는 아래와 같습니다. 첫번째는 Kernel 방식이고 두번째가 Simple 방식입니다. Simple 방식은 Kernel 방식에 비해 처리 속도가 매우 빠르지만 그 결과는 Kernel에 비해  떨어집니다. 물론 분석 대상이 되는 Point나 Polyline의 개수가 증가할 수록 그 결과의 차이는 줄어들것으로 생각됩니다. XGE에서 밀도계산 기능을 확장단위로 개발하기에 앞서 비교 기준이 되는 결과를 ArcMap에서 살펴봅니다.

• 측정값이 들어가 있는 포인트나 폴리라인 벡터 데이터(여기서는 포인트에 관심을 둠)
• 측값값이 저장된 속성 데이터에 대한 필드명
• 밀도 분석 방법(Kernel과 Simple 방법이 있음)
• 검색 반경
• 셀의 크기

6월 13일부터 15일까지 양재동의 AT센터에서 GIS Korea 2007이 열렸습니다. 회사 연구소에서 GIS Korean 2007에서 발표했던 제품중 새로운 제품 두개가 있는데, 그 중에 하나가 바로 제가 담당한 GeoGraph입니다. 웹에서 작동하는 방식으로 시연을 했고 회사 부사장님의 강력한 추진력으로 시연 당일 아침에 터치스크린 장치에서 시연해 시연 효과를 높였습니다. 아래는 대회에서 일반 대중에게 처음으로 공개되어져 시연된 GeoGraph를 이용해 만든 데모의 스크린샷입니다.