이 글은 지도 서비스 방법으로 이미지 방식과 벡터 방식에 대한 장단점과 이런 장단점으로 인해 각각의 적당한 적용분야에 대한 개인적인 생각을 써본 글입니다.
초기 지도 서비스는 서버에서 클라이언트로 데이터를 전송해줄 때 좌표를 던져줌으로써 이 좌표를 이용해 지도를 화면상에 그려냈습니다. GIS의 초창기에는 이런 벡터 방식이 주류를 이루었으나, 지금은 이미 만들어 준비된 지도 이미지를 서버가 클라이언트에게 던져주고, 클라이언트는 이 이미지를 화면에 뿌려주는 방식이 대세가 되었습니다. 구글맵이 그렇고.. 콩나물, 네이버, 다음, 야후, MS 등등, 모두가 이미지 방식입니다. 그렇다면 이유는 무엇일까요?
- 속도가 빠르다.
- 클라이언트 개발이 간편하다.
- 클라이언트에 별도의 프록그램 설치(특히 말도 탈도 많다는 ActiveX)가 필요없다.
- Web2.0(특히 AJAX 기술)의 트렌드를 충족시킨다.
가장 중요한 것이… 이미지 기반은 벡터 기반에 비해 속도가 빠릅니다. 속도라 함은 클라이언트가 보고자 하는 지역의 좌표(MBR)를 넘겨주면 서버가 해당 지역에 대한 데이터를 찾아 전송해주고 클라이언트가 화면상에 그려주는데까지 얼마나 빨리 처리할 수 있느냐입니다. 벡터 기반의 경우 이런 처리에 대한 전체 흐름은 다음과 같습니다.
- 클라이언트는 원하는 지역의 좌표와 지역의 크기(이를 MBR이라 함)를 서버로 전송한다.
- 서버는 해당 지역의 데이터를 수집하는데, 데이터는 복잡한 공간검색(R-Tree나 Grid-File과 같은 공간검색 알고리즘 이용)을 사용하며 이 검색 방식은 많은 시간이 소모된다.
- 서버는 수집한 데이터를 클라이언트로 빠르게 전송하기 위해 데이터의 크기를 줄일 목적으로 데이터를 압축한다.
- 서버가 보낸 데이터가 압축되었다면 클라이언트는 받은 데이터를 압축해제 한다.
- 클라이언트는 받은 데이터(좌표, 속성 등)를 이용하고 지도 이미지를 직접 만들어 그린다.
- 클라이언트 측의 사용자는 자신이 요청했던 지도를 본다.
다음으로 이미지 기반의 처리 과정을 살펴보면 다음과 같습니다.
- 클라이언트는 원하는 지역의 좌표와 지역의 크기(이를 MBR이라 함)를 서버로 전송한다.
- 서버는 해당 지역에 대한 이미지를 찾는데, 해당되는 지역에 대한 파일의 찾기는 매우 단순하며 빠른다.
- 서버는 이미지를 바로 클라이언트로 전송한다.
- 클라이언트는 받은 이미지를 바로 그린다.
- 클라이언트 측의 사용자는 자신이 요청했던 지도를 본다.
처리 과정만을 살펴보더라도 벡터 기반에 비해 이미지 기반의 지도 서비스가 당연히 빠를 수 밖에 없다는 것을 알수 있지요.
그렇다면 이처럼 성능 좋은 이미지 기반의 지도 서비스가 아닌 벡터 기반의 서비스가 할 수 있는 기능은 무엇일까요..? 즉, 이미지 기반의 지도 서비스에서는 불가능한, 아니 매우 어려운 기능은 무엇일까요?
- 새로운 건물이 생겼을 때나 형태가 변경되었을 경우, 클라이언트에서 지도 편집
- 화면상에 표시된 지도에서 원하는 건물을 찍어 그 건물의 상세 내용을 살펴보는 기능
- 플롯터와 같은 출력기를 통해 큰 용지(A4 이상)에서 높은 품질의 지도 출력하기
- 건물을 제외하고 도로만을 화면상에 보는 것과 같은 원하는 지도 스타일 만들기.
- 건물 전용면적이 200평방 이상인 건물만을 화면상에 표시하여 지도 보기.
- 지도의 특정 주제를 가지는 요소 그룹을 사용자가 원하는 색상이나 형태로 표시하는 기능.
- 등등…
위의 기능이 왜 이미지 기반에서는 거의 불가능하고 벡터 기반에서는 가능한 이유는 무엇일까요? 그것은 단지 현재 보이는 지도에 대한 정보를 이미지 기반은 “이미지”로써만 가지고 있기 때문입니다. 이에 반해 벡터 기반은 지도에 대한 실제 정보로써 “지도 좌표”를 가지고 있다는 점입니다.
이러한 이미지 기반과 벡터 기반의 서로간의 장단점을 놓고 볼때.. 이미지 기반은 클라이언트 PC에 별도의 프로그램 설치 없이 원하는 지역을 빠르게 보여주는 서비스에 적당하며, 벡터 기반은 사용자가 원하는 지역에 대해서 좀더 다양한 기능, 즉 이미지 기반이 제공할 수 없는 기능, 좀더 전문적으로 말해 지도를 좀더 높은 수준에서 활용하고 응용하는 영역, GIS에 적당하다고 할 수 있습니다.
http://mapapps.esri.com/serverdemos/mailinglist/index.html
중용도 있지요..
어떤 점에서 중용이라는 말씀이신지? ^^
WebService를 생각하고 있는데 벡터기반으로 해야할지 이미지 기반으로 해야할지 고민이 많았었는데 좋은 정보 감사드립니다. ^^ 흠.. 중용.. 도 생각해볼 문제군요 ^^
SOMA님두 GIS분야에서 활동하고 계시는군요? 반갑습니다~ 저는 여러가지 이유와 제 개인적인 생각때문에 벡터방식을 앞으로도 쭈욱… 밀고 나갈 생각입니다만, 요즘 이미지 방식이 대세인지라.. 특히 그 속도 때문이라면, 역시 이미지 방식을 아직은 따라올수가 없을듯합니다..
소마님은 어느 회사에서 무엇을 개발하고 계시나요? ^^ 궁금하네요,
중용이 뭔가요..?
지도는 이미지 컨텐츠는 벡터….이게 중용일듯? 아닌가요?
10년 전 글인데도, 참 주옥같은 글이네요.
브라우저마다 조금 달라지긴 하겠지만,
현재 googlemap이나 mapbox는 온전히 vector 렌더링이고,
네이버는 새로 개편하는게 중용의 렌더링 같네요. ^^
블로그에 항상 좋은 정보 얻고 갑니다.