1. 서 론

정보의 시각화에 대한 사람들의 눈높이가 점점 더 높아지면서 대표적인 영상 가시화 장비인 가정용 TV는 3D TV가 기본이 되었고, 영화관에서는 3D를 넘어서 4D영화와 보다 큰 대형스크린에서 현장감을 느낄 수 있는 IMAX(Image Maximum) 4D영화가 상영되고 있다. 이러한 기술발전과 더불어 기존에는 텍스트로 표현했던 많은 정보들에 대해 위치기반으로의 표현이 요구되면서 지도가 다양한 속성정보들을 표현하기 위한 플랫폼으로 자리 잡았다(Kim et al., 2009).

또한 개방형 서비스를 원칙으로 웹2.0 환경의 정착에 따라 지도플랫폼 또한 OpenAPI를 통해 새로운 서비스를 개발할 수 있도록 지원하게 되며 대중화되었다(Kim and Jin, 2011; Bang and Yang, 2011). 이러한 지도플랫폼 기반의 웹 서비스들에서 활용되는 다양한 컨텐츠들은 국제표준화기구인 OGC(Open Geospatial Consortium)에서 표준으로 제정한 KML(Keyhole Markup Language)포맷과 같은 형태로 관리된다(Kim and Kang, 2014).

현재 지리교육, 환경, 관광, 부동산, 고고학, 관광 등 여러분야에서 KML형태의 컨텐츠들을 활용하고 있다. 다양한 분야에서 KML포맷이 사용되면서 대부분의 지도서비스와 GIS분야의 응용프로그램에서 KML파일을 지원하게 되었다. 이렇게 다양한 응용프로그램에서 KML포맷을 지원하면서 기존에 있는 KML에 대한 문법적 검증 이외에 각 응용프로그램에 대한 호환성 검증이 필요하게 되었다.

일반적으로 KML검증은 XML의 기본문법 준수여부를 검사하는 기본 검증(well-formed validation)과 기본 스키마 준수여부를 검사하는 스키마 검증(schema validation), 그리고 KML을 지원하는 응용프로그램들이 필요에 따라 정해 놓은 부분을 검사하는 명세서 검증(specification validation)으로 구분할 수 있다(Mathews, 2011). 기존에 KML검증을 위한 도구인 jEdit(Google jEdit Tutorial, 2014)나 Galdos의 KML Validator(2014)는 기본 검증이나 스키마 검증은 어느 정도 지원하고 있지만 명세서 검증과 응용프로그램에 대한 호환성을 검증해주지 못한다.

따라서 본 연구에서는 대표적인 KML 저작도구인 Google Earth(이하 구글 어스)4)와 VWorld 3D Desktop(브이월드 3D 데스크톱, 이하 3D 데스크톱)5)에서 지원하는 KML의 기본사양과 OGC KML2.2의 사양을 비교하고, 구글 어스와 3D 데스크톱에서의 실제 KML 처리방식을 분석하여 호환성 검증방안을 마련하고자 한다. 더불어 분석된 내용을 바탕으로 호환성 검증 도구 개발방안을 제안하는 것을 목적으로 한다.

2. KML 사양의 다양성

Keyhole Markup Language의 줄임말인 KML은 구글 어스와 구글 맵스의 공간정보를 저장하고 표현, 공유하기 위해 개발한 XML 기반의 마크업 언어이다. KML은 범용성을 인정받아 공간정보 분야의 국제표준화 기구인 OGC에서 표준으로 채택하고 있다. 국제표준의 자격을 갖춘 만큼 KML을 사용하는 응용프로그램은 매우 다양하다. 예를 들어 ArcGIS 익스플로러, 플리커(flickr)와 같은 외산 서비스뿐 아니라 브이월드에서도 KML을 사용한다(Wikipedia, 2014). 이때 응용프로그램에 따라 OGC KML 표준 사양에 새로운 기능을 추가하거나 개별 응용프로그램에서 이미 지원하는 기능을 삭제하여 다양한 KML 사양이 존재할 수 있다.

이번 장에서는 OGC KML 2.2버전의 사양과 OGC KML에 gx 확장 네임스페이스를 추가하여 정의한 구글 어스의 KML 사양, 그리고 대체가능한 기능에 대해 삭제한 브이월드 KML 사양를 비교하여 응용프로그램 별 KML 사양의 다양성을 파악하고자 한다.

2.1. OGC KML Version 2.2 사양

OGC KML 2.2의 사양은 Fig. 1(a)와 같다. 그림에서 Feature(Overlay, Container), Geometry, StyleSelector, TimePrimitive, AbstractView, Substyle(ColorStyle)와 같이 상자 안에 들어 있는 요소들은 추상 클래스이며, 다이어그램을 통해 클래스 관계와 요소들 간의 포함 관계를 쉽게 파악할 수 있다. Object는 id를 각 요소들에 부여하고, 그 id는 KML파일 수정 및 스타일을 공유하기 위해 사용된다. 또한 KML에서 기하 표현은 Point, LineString, LinearRing, Polygon, MultiGeometry, Model로 나타난다. KML은 경위도를 기준으로 Placemark를 위한 장소 표시를 하며, 이미지 · 폴리곤 · 3차원 모델은 tilt, heading, altitude 등의 정의를 통해 특정위치에서 보일 수 있다. KML의 모든 태그들은 케이스 기반이며, KML에 정의되어 요소들의 태그 이름을 정확히 참조해야 한다(Kang et al., 2011).

2.2. 구글 어스 KML 2.2 사양

Fig. 1(a)에서 gx 접두어가 붙은 태그는 확장 개념으로 구글 어스에서 기존 OGC KML 표준에 새로운 기능을 추가하기 위해 정의한 것으로 구글 어스만을 위한 전용 태그이다(Google Developers KML Reference, 2014). 구글 어스 KML에서의 기하 표현은 Point, LineString, LinearRing, Polygon, MultiGeometry, Model, gx:Track, gx:MultiTrack으로 나타난다. OGC KML 명세서와 비교하여 gx:Track과 gx:MultiTrack이 추가되었다. 구글에서는 다수의 객체와 그 객체의 발생 시간을 연계한 트랙(track) 데이터의 중요성을 염두에 두고 이와 같은 기능을 확장하였다. 즉 트랙은 객체가 주어진 시간동안 어떻게 움직였는지를 설명할 수 있다. 예를 들어 GPS 등을 이용하여 생성된 트랙 데이터로 인해 사용자가 자전거를 타고 이동한 거리 및 장소 등을 파악하고, 다른 사용자들과 공유한다면 매우 유용할 것이다. 이를 위해 Geometry 요소에 포함되어 있는 gx:Track 및 gx:MultiTrack 요소들을 활용한다. 여기서 gx:MultiTrack은 휴식 등에 의한 시간 간격이 생기는 것을 고려하여 여러 트랙이 생성될 경우 이를 하나로 묶을 수 있는 역할을 한다.

2.3. 브이월드 KML 2.2 사양

2014년 7월 현재 브이월드의 KML 2.2 사양은 Fig. 1(b)와 같다. 브이월드에서 지원 가능한 요소는 Feature(PlaceMark, Container), Geometry(Point, LineString, Polygon, MulitGeometry), StyleSelector, SubStyle(ColorStyle)이다. Fig. 1(a)에서 gx 접두어가 붙은 요소는 구글 어스 전용태그이므로 지원하지 않는다. 또한 Overlay(PhotoOverlay, ScreenOverlay, GroundOverlay), AbstractView(Camera, Lookat), SubStyle(BalloonStyle)은 브이월드 기능으로 대체 가능한 KML 사양이므로 지원하지 않는다.

Fig. 1.Variety of KML 2.2 schema

3. 구글 어스와 3D 데스크톱의 KML 비교분석

명세서 검증의 목적은 표준을 준수한 KML파일에 대해 각 응용프로그램이 정의한 사양들을 검사함으로써 실제해당 응용프로그램에서 활용 시 가지고 있는 정보를 제대로 표현가능한지를 사전에 알기 위함이다. 만약 이 부분이 제대로 수행된다면 기존에 문법적 오류를 찾아내는 검증에서 한 발 더 나아가 임의의 KML파일을 어떤 응용프로그램에서 사용하는 것이 적합한지 제안할 수 있을 것이다. 이와 같은 수준의 명세서 검증을 수행하기 위해서는 앞 장에 살펴본 각자 다른 사양의 KML을 사용하는 응용프로그램들이 실제 KML파일을 어떻게 사용하는지 알아야 한다. 이를 위해 구글 어스와 3D 데스크톱에서 점 · 선 · 면에 대한 도형을 생성 후, 해당 구문을 분석해 특이사항을 도출했다. Fig. 2는 분석을 위해 사용한 구글 어스와 3D 데스크톱의 기본화면이고 각각 버전 7.1.2.2041과 버전 1.0.0.26의 프로그램을 사용했다.

Fig. 2.Initial screen of Google Earth and 3D Desktop

3.1. 포인트 데이터 분석

포인트 데이터의 OGC KML의 기본 태그는 를 사용한다. 태그의 요소는 , , 를 가질 수 있고 그 의미는 Table 1과 같다(OGC, 2012).

Table 1.Sub-element of the point in KML(Wilson, 2008)

구글 어스와 3D 데스크톱에서는 각각 아이콘추가와 장소추가 기능을 통해 포인트 데이터를 생성할 수 있다. 해당 데이터를 생성 후 파일을 텍스트편집기를 통해 열어보면 Fig. 3과 같다.

구글 어스의 KML 네임스페이스는 Fig. 3(a)와 같이 OGC KML의 기본 네임스페이스 이외에 gx라 불리는 식별자가 추가되고 브이월드는 Fig. 3(b)와 같이 표준 식별자와 gx식별자 이외에 추가로 vx라는 식별자가 붙는다. 그리고 포인트 데이터의 아이콘, 라벨 색상 등을 정의하는 스타일 태그는 둘 다 동일한 구조로 사용한다.

Fig. 3.Comparing the point KML description of Google Earth and 3D Desktop

두 KML의 차이 중 하나인 태그는 화면의 시점에 대한 정보를 가진 태그이다. 구글 어스에서는 이를 통해 해당 포인트의 위치를 어떤 시점에서 보여줄지 결정하지만 3D 데스크톱은 해당태그를 사용하지 않고 엔진에서 최적 시점을 결정해 사용자에게 해당 위치를 보여준다. 따라서 태그가 있는 포인트 파일을 3D 데스크톱에서 열 때, 오류를 발생하지는 않지만 해당 값을 사용하지는 않는다.

또 다른 차이는 , 태그의 존재여부인데, 3D 데스크톱에서는 해당태그를 정의하고 구글 어스에서는 정의하지는 않는다. 3D 데스크톱에서의 각 태그의 값 0과 clampToGround로 기본 값에 해당한다. 구글 어스는 해당 태그가 생략 시 기본 값으로 읽기 때문에 구글 어스에서 생성한 KML파일에서는 두 태그를 생략하게 된다. 실제 태그의 값을 relativeToGround와 같이 설정하고 KML파일을 생성하면 해당 태그를 정의한 것을 확인할 수 있다.

구글 어스를 통해 포인트 생성 시 고유의 식별자인 gx를 사용한 가 존재한다. 이 태그는 오버레이의 우선순위 정의하는 태그로 낮은 숫자일수록 상위에 그리게 되고 기본 값은 1로 정의된다. 태그는 구글에서 정의한 태그이기 때문에 오류를 발생시키진 않지만 3D 데스크톱에서 해당 정보를 반영하지는 않는다.

3D 데스크톱을 통해 포인트 생성 시에도 고유의 식별자인 vx를 사용한 태그가 존재한다. 이 태그는 3D 데스크톱에서 장소를 추가하거나 해당 장소를 수정한 최종 날짜와 시간을 의미한다. 이 또한 표준태그가 아니고 3D 데스크톱에서 내부적으로 사용하는 정보이기 때문에 구글어스에서 오류를 발생시키지도 사용하지도 않는다.

3.2 라인 데이터 분석

라인 데이터의 OGC KML의 기본 태그는 을 사용한다. 태그의 기본요소는 , , , 가 있다. , , 는 앞서 포인트에서 설명한 의미와 동일하다(OGC, 2012).

는 라인을 표현 시 지면에 붙여서(drape) 표현할지 아니면 양 끝 점을 직선으로 연결해 표현할 지에 대한 여부를 결정하는 값이다. boolean형의 데이터 값을 갖고 기본 값은 0(false)이다. 따라서 지면을 따라 라인을 표현하고 싶다면 해당 태그를 선언하고 1의 값을 부여해야 한다. 를 사용하기 위해서는 의 값이 clampToGround여야 한다. 만약, 의 값이 clampToGround가 아니라면 라인을 구성하는 연속된 점 사이를 직선으로 표현한다. 와 의 값에 따른 보간 방법을 정리하면 Table 2와 같다.

Table 2.Interpolation scheme for (Wilson, 2008)

구글 어스와 3D 데스크톱에서는 라인 데이터에 동일하게 경로추가 기능을 생성한다. 해당 데이터를 생성 후 파일을 텍스트편집기를 통해 열어보면 아래 Fig. 4와 같다.

Fig. 4.Comparing the line KML description of Google Earth and 3D Desktop

두 KML파일의 네임스페이스 구조와 스타일 태그는 앞서 설명한 포인트 데이터에 대한 KML파일들과 동일한 구조를 가진다. 그리고 3D 데스크톱에서만 포인트 데이터와 같이 고유한 식별자를 사용해 해당 파일의 생성 혹은 수정한 최종일시를 에 기록했다. 포인트 데이터와 동일하게 해당 태그는 구글 어스에서 오류를 발생시키지 않는다.

라인 KML의 경우 구글 어스에서 생성한 파일을 3D 데스크톱에서 로딩 시 오류를 발생시킨다. 두 어플리케이션 모두 지오메트리 태그 내에서 스타일태그를 링크시켜 사용하는데, 구글 어스 KML의 의 값인 ‘pushpin’에서 유추할 수 있듯이 포인트 스타일에 사용하는 를 사용해 를 구성했다. 이로 인해 구글 어스에서는 해당 KML을 기본 스타일 값을 부여해 오류 없이 읽지만, 3D 데스크톱에서는 오류가 발생해 표현되지 않는다. 구글어스의 경우 라인 데이터를 생성하고 스타일 값을 사용자가 임의의 값으로 설정하고 저장해야 라인 스타일에 사용하는 태그를 정의 한다. 구글 어스에서 생성한 KML을 3D 데스크톱에서 사용하기 원한다면 태그를 삭제하고 사용하면 된다.

또한, 태그, 태그, 태그의 쓰임에 중요한 차이가 있다. 구글 어스의 KML은 포인트의 경우와 동일하게 기본 값으로 라인을 만들 경우 와 를 생략하고 의 경우 구글 어스에서 그리는 기본 형태가 지형에 결합된 형태이기 때문에 1의 값을 갖는다. 따라서 해당 KML은 3D 데스크톱에서 잘 열리고, 3D 데스크톱에서 생성한 KML 역시 구글 어스에서 문제없이 사용 가능하다. 하지만 구글 어스에서 의 relativeToGround나 absolute로 설정하고 3D 데스크톱에서 열어보면 의 고도 값 때문에 보이지 않는다. 이는 OGC 표준에서 정표고(orthometric height)로 정의해 놓은 의 고도(altitude) 값이 구글 어스에서는 0으로 일괄 작성되었기 때문이다. 가 clampToGround라면 라인을 이루는 점들이 지면에 결합되기 때문에 고도 값의 영향을 받지 않지만 relativeToGround나 absolute의 경우 구글 어스에서는 자체적으로 해당 값을 처리하지만 3D 데스크톱에서는 표준에 근거하여 처리하기 때문에 고도 값을 제대로 처리할 수 없다.

3.3 폴리곤 데이터 분석

폴리곤 데이터의 OGC KML의 기본 태그는 을 사용한다. 태그의 기본요소는 extrude, tessellate, altitudeMode, outerBoundary, innerBoundary가 있다. , , 는 라인에서의 의미와 동일하다(OGC, 2012).

와 는 각각 폴리곤의 외곽 경계와 구멍 난 형태의 내부 경계를 의미하는 요소로 이 폐합된 형태인 에 의해 정의된다. 은 앞서 설명한 과 가 최소 4개의 포인트가 정의되어야하고 첫 번째 포인트와 네 번째 포인트가 동일해야 한다는 규칙만을 제외하고 동일하다.

구글 어스와 3D 데스크톱에서는 폴리곤 데이터를 동일하게 다각형추가 메뉴를 이용해 생성한다. 해당 데이터를 생성후 파일을 텍스트편집기를 통해 열어보면 Fig. 5와 같다.

Fig. 5.Comparing the polygon KML description of Google Earth and 3D Desktop

기본적인 사항은 앞서 설명한 포인트와 라인의 경우와 동일하고 폴리곤 역시 라인에서와 동일하게 구글 어스에서 스타일을 지정하지 않는다면 을 로 을 정의하기 때문에 삭제해야 3D 데스크톱에서 열 수 있다. 의 표준요소는 , , , , , 로 구성되고 폴리곤에서는 로 스타일을 정의해야 한다. 하지만 구글 어스에서 폴리곤을 생성하고 설정을 통해 스타일 값을 변경하지 않으면 포인트, 라인, 폴리곤 모두 포인트의 과 동일한 값으로 KML을 생성한다.

4. 비전문가를 위한 KML검증 시스템 개발

구글 어스와 3D 데스크톱의 기본 사양과 각 응용프로그램에서 KML을 사용하는 특징을 분석한 결과를 기반으로 공간정보 데이터에 익숙하지 않은 비전문가들이 KML파일을 활용할 수 있는 최적의 도구를 추천하기 위한 프로세스를 제안하고, 이를 구현한 웹 기반 검증도구의 예시화면을 소개하고자 한다.

임의의 KML 최적의 도구를 추천하기 위해서는 즉, 앞서 언급한대로 명세서 검증을 수행하기 위해서는 XML 기본문법에 대한 검증과 OGC KML2.2기준의 스키마 검증을 마친 것을 전제로 한다. 우선 KML의 네임스페이스 검사를 통해 gx나 vx식별자가 사용된 경우 해당 도구로 사용되었으므로 해당 프로그램을 우선순위에 둔다. 그리고 해당 프로그램에서 요구하는 특정한 사용들에 대해 검사를 수행한다.

gx식별자가 있는 KML을 3D 데스크탑에서 열고자할 때는 스타일 태그에 의해 발생할 수 있는 문제, 높이 값에 의해 발생할 수 있는 문제, 레이어 우선순위를 명확히 표현 못할 수 있는 문제 등을 사용자에게 알려 줄 수 있다. 또한 vx식별자가 있는 KML을 구글 어스에서 사용하고자 할 때는 해당 파일의 최종 수정 일을 사용하고자 하지 않는다면 문제없이 사용할 수 있다. 하지만 해당 파일이 고도 값을 사용한다면 3장에 언급한대로 다르게 사용하는 부분이 있기 때문에 기존 정보와 다르게 표현될 수 있다는 경고를 사용자에게 알려줘야 한다. 이를 기반으로 구현한 시스템의 UI와 예시화면은 Fig. 6과 같다.

Fig. 6.Example of the recommended validation tool

5. 결 론

다양한 분야의 사람들이 구글 어스와 같은 지도서비스를 기반으로 KML파일을 활용해 보유한 컨텐츠들을 공유하거나 연구에 활용하고 있다. 이와 더불어 여러 응용프로그램들이 KML을 지원하면서 저작도구에 따라 다양한 버전의 KML파일이 생산되었다.

본 연구는 KML내부 구문에 대해 알지 못하는 일반사용자들에게 보유한 KML파일을 사용하기 위한 최적의 지도서비스를 제안하는 고도화된 검증도구를 제안하기 위해 국내외 대표적인 저작도구를 분석하였다. 기본적인 차이를 도출하기 위해 OGC KML2.2 사양을 기준으로 구글 어스와 3D 데스크톱의 KML사양을 분석하였고, 각 프로그램의 필요에 의해 일부 사양을 추가하거나 기본 기능으로 대체하기 위해 단순화 시킨 구조를 확인했다. 그리고 해당 사양을 기준으로 실제 어떻게 KML을 생성하고 사용하는지 분석한 결과 구글 어스와 3D 데스크톱 각각 고유한 특징들을 확인했다. 구글 어스의 경우 다양한 버전의 KML을 문제없이 사용할 수 있었지만, KML을 생성 시 구문을 단순화하기 위해 생략하는 부분이 있었고 타 프로그램과의 호환성을 저해할 수 있는 요소들이 발견되었다. 3D 데스크톱의 경우 예외에 대한 처리가 미흡하여 다양한 버전의 KML을 가시화할 수는 없지만, KML을 생성하는데 있어서는 표준을 잘 준용하고 있었다.

이렇게 분석된 결과를 이용해 기존 검증도구를 고도화해 구글 어스나 3D 데스크톱에서의 사용가능여부와 발생할 수 있는 문제들을 사용자에게 알려줄 수 있는 시스템을 설계했다. 사용자가 검증도구를 통해 검증이 완료되면 KML의 정보를 지도기반으로 간단히 표현하고 구글 어스와 3D 데스크톱 중 적합한 프로그램을 초기화면으로 보여주고 중요 사항을 알려준다. 만약 적당한 프로그램이 없거나 다른 프로그램을 선택한다면 해당 프로그램 사용 시 발생할 수 있는 문제들을 사용자에게 알려준다.

제안한 시스템은 KML파일 사용자에게 보다 나은 사용 환경을 제안하기 위해 호환 가능한 프로그램을 추천하고 예상 가능한 문제를 알리는 것을 목표로 하였다. 본 논문에서 분석된 점, 선, 면의 단순한 구조를 기반으로 복잡한 형태의 다각형 구조나 지오메트리 이외의 스타일, 네트워크 링크 등에 대한 추가적인 분석과 검증 프로세스 구조화를 통해 향후 임의의 KML파일을 사용하고자하는 프로그램에 적합한 형태의 KML로 변환해 줄 수 있는 시스템을 개발할 것이다.