'kml'에 해당되는 글 3건

  1. 2010.10.28 KML 경로를 따라 이동하는 카메라 영상을 임베딩해보세요
  2. 2009.08.18 GeoWeb Standard ... 현시점에서의 문제들
  3. 2009.08.17 GeoWeb Standard... 데이터와 서비스
2010.10.28 21:36

KML 경로를 따라 이동하는 카메라 영상을 임베딩해보세요


괜찮은 서비스가 있어서 소개합니다. 자신이 만든 KML 파일을 업로드해서 경로를 따라 이동하는 카메라 영상을 자신의 웹 페이지에 임베딩할 수 있게 해주는 서비스입니다. 요즘 스마트폰 많이들 쓰시니 여행같은 장소 이동시 GPS를 켜시고 이동 경로 로그를 저장하여 활용하시면 되겠습니다.

GPSFly.org 라는 서비스를 이용하시면 됩니다. GE Plugin in 포럼에 작년 이맘때에 이걸 어떻게 구현하느냐고 질문 올렸던 사람이 근 1년만에 손수 구현했다면서 링크를 올려놨길래 알게 되었습니다. GE 데스크탑에서는 그냥 로딩하고 Tour 버튼만 누르면 되는데 웹 상에서 구현하기에는 좀 까다라운 면이 있는 거 같습니다.

아래는 지난 7월 구글어스 5.2 의 <gx:track> 지원 이라는 글에 첨부했던 kmz 파일을 GPSFly.org 에 업로드하고 여기에 임베딩한 것입니다. KMZ 파일 내의 모델까지는 지원해 주지 않는군요. 아래 Fly 버튼을 누르시면 됩니다. GE Plugin in 이 임베딩 된 이후에 Fly 버튼 우측의 버튼들을 이용하면 속도를 조절할 수 있습니다. 

Trackback 0 Comment 0
2009.08.18 14:44

GeoWeb Standard ... 현시점에서의 문제들

앞서 정리했던 GeoWeb Standard에 대한 내용을 마저 정리한다. 이글을 세번째 파트 GeoWeb Standard - currnet problems 이다. 간략히 정리했으니 자세한 내용을 보고 싶으신 분은 원문을 참고하면 되겠다.


GeoWeb Standard ... 현시점에서의 문제들

GeoRSS, KML, GeoJSON은 geodata 포맷이 되기 위한 열망을 숨기지 않고 있다.
- Sean Gillies


앞서 언급한 여러가지 데이터 포맷들은 다양한 필요와 상황에서 활용되고 있으나 GeoWeb 환경에서는 몇가지 문제점들을 안고 있다.

1. 적절한 웹 타입 디스크립션의 부재
  • 가장 보편적이며 일반적인 문제로 웹 환경에서 사용되는 데이터에 대한 MIME 타입 부재로 인해 클라이언트가 데이터를 어떻게 표현해야 할 지 알수 없는 상황
  • Atom, JSON, HTML, SQLite는 MIME-Type 이 제공되긴 하지만 이러한 데이터 포맷에 지리공간적 정보다 담겨있음을 알릴 수 있는 방법이 부재
  • KML이 유일하게 MIME-Type을 가지고 있고 OGC 표준으로 채택되었지만 KML의 MIME-Type는 여전히 특정 기업에 특화된 application/vnd.google-earth.kml+xml 이며 압축 포맷인 KMZ에 대해서도 MIME-Type 지원되며 이는 vnd.google-earth.kmz

2. 파일 크기
  • 파일 크기가 작을 수록 웹 환경에 유리
  • 사이즈 비교를 위해 GeoCommon의 특정 데이터를 다양한 포맷으로 익스포트 했을 때의 파일 크기와 압축했을 시의 파일 크기 비교 테이블
 포맷 Size Zipped
 CSV 1.3 KB
 
 Shapefile 5.4 MB
 3.6 MB
 GeoRSS 3.3 MB 1.1 MB
 KML 7.3 MB 2.4 MB
 Spatialite 5.4 MB 3.6 MB
 JSON 7.9 MB 2.3 MB
  • JSON이 상당히 크다는 것이 이례적. 안타깝게도 폴리곤 데이터 표현을 위한 문법적 구조로 인해 복잡한 데이터에 대해서는 파일 크기가 증가함

3. 링크기능/자료연속성/검색가능성 있어야
  • 웹 기반의 데이터가 웹 특성을 살릴 수 있기 위해 기본적으로 지녀야 할 특성: Linability, Durability, Discoverability
  • CSV, Shapefile, SQLite : 데이터 있으나 링크는 불가능
  • Atom, GML, KML : 링크 기능 지원하나 geo적 특성에서 효율적이지 못함
  • JSON : 링크 담을 수 있으나 스키마 없으면 인식 어려움

4. 복잡성을 최소화 해야
  • 3번 기능이 필요하지만 복잡성이 증가하기 때문에 데이터 포맷 활용 방해
  • 개발자나 사용자도 쉽게 이해하고 사용할 수 있는 단순함이 요구됨
  • KML처럼 태그 이름에 카멜 표기법의 규칙성이 떨어지거나 GeoRSS처럼 비슷한 유형의 다수 태그를 지원하여 명확성이 떨어지게 해서는 안됨

5. 도구
  • 이러한 데이터 작업을 도와주거나 데이터간 변환을 위한 도구 부족
  • KML이 특정 업체 애플리케이션 포맷에서 범용 데이터 포맷으로 급부상한 이유에는 사용자의 기본적 니즈 충족과 kML 생성을 도와주는 도구(Google Earth)가 있음

6. 적정수준의 기능을 제공하는 포맷 부재
  • 복잡함과 단순함 어느 한쪽에 치우치지 않는 데이터 포맷 필요


Trackback 0 Comment 0
2009.08.17 18:02

GeoWeb Standard... 데이터와 서비스

Introduction to NeoGeography 의 저자인 Andrew Turner 가 Geoweb 2009 행사를 맞아 자신의 블로그에 GeoWeb Standard 에 대한 시리즈 글을 올렸다. GeoWeb 2009에서 GeoWeb Standards: How far they’ve come, How far they need to go 발표를 했는데 그 발표 내용의 원본이랄 수 있는 내용인 거 같다. 두번째 파트인  GeoWeb Standards-Where we are 내용이 정리해 둘 필요가 있는 거 같아 작업한 결과를 옮겨본다. FritiousOne에서 CIO로 일하고 있는 Andrew Turner는 GeoCommon 의 GeoIQ 개발을 주도한 것으로 알고 있으며 이 분야 여러 컨퍼런스에서 주된 발표자로서 유명하다.

===================================================================
이 글에서는 일반적인 GeoSpatial Data Format이 아니라 웹에서 활용되기 편한 데이터 표준에 대한 언급을 하고자 한다. (첫번째 Shapefile 는 예외)

GeoWeb Data

Shapefiles

2D 기반의 지리정보를 대상으로 하는, 역사가 오랜 데이터 포맷,
현재까지도 가장 널리 사용되고 있음
웹에서 활용하기에는 부적합
  - 포터블 데이터베이스와 같은 역할을 하지만 실제로는 다수 파일로 구성됨
    . dbf: 속성데이터 저장
    . shp: 지오메트리 저장
    . shx: 데이터와 지오메트리 조인
    . prj: 프로젝션 정의(옵션)
데스크톱 GIS 소프트웨어의 바이너리 스토리지 목적이어서 웹 환경에서 사용은 부적합
  - 속성 이름에 12개 글자까지 허용, 한글 안됨
    . single Geometry 한계(라인, 포인트, 폴리곤 믹싱 불가능)
  - 다수 파일을 다루어야 함
  - Mime-Type 미지원
  - 웹 문서의 기본인 Linking 기능 미지원


Microformat-Geo & Adr

마이크로포맷은 일반 HTML 마크업 내부에 데이터를 임베딩하려는 기초적인 시도
GeoSpatial 포맷으로는 2D 좌표를 담는 geo와 주소를 담는 adr 이 있음
지리공간분야 비전문가도 쉽게 지리공간정보를 직접 또는 툴을 이용해서 추가할 수 있는 장점 있음
Google과 Yahoo와 같은 기업도 검색 용이성 향상과 API를 통한 데이터 조작의 편의성 증진을 위해 마이크로포맷을 지원하고 있음
단점들
  - geo: 고도 정보를 담을 수 없음
  - 외부 지오메트리 정보에 대한 링크 기능이 없음(비슷한 데이터 포맷의 공통적인 단점)
  - Microformat 정보가 담긴 문서 내의 컨텍스트에 대한 연계 기능이 없음(예를 들어 백악관에 대한 주소 마크업은 가능하지만 프레스 컨퍼런스 위치인지 대통령의 위치인지 등에 대한 정보인지 알 수 없음)


GeoRSS

블로그나 뉴스 소식을 전하는 RSS 또는 Atom 피드 사용이 증가하면서 여기에 위치정보를 추가시키고자 하는 필요에 의해 등장
Geo 커뮤니티 외부에서 등장하여 사실상의 표준으로 자리잡았다는 면에서 Microformat과 유사하며 둘다 Bottom-Up 접근 방식의 성공 사례
지도와 지리공간 데이터를 사용하는 다수 웹사이트(예: 구글맵, 야후맵, MS Bing맵, 로이터, 알자지라)에서 보편적으로 활용
보편적 활용에도 불구하고 개발 과정에서 기인한 복잡성 존재
9개 유형의 GeoRSS가 존재
  - RSS에 기본적으로 RDF, RSS, Atom 이라는 3가지 각기 다른 포맷이 상존
  - GeoRSS 자체에도 3가지 피드 포맷이 존재 : W3C, Simple, GML
    . W3C의 스펙은 폐기되었음에도 활용되고 있어 개발에 혼란을 가중
    . GeoRSS가 기존 피드의 간단한 확장임에도 불구하고 확산이 광범하지 않은 이유중 하나다수 위치 지원, 타임스팬, 외부 지오메트리, 피처 아이덴티피케이션 등에 대한 요구와 다수 토론이 있으나 기능 확장이 이루어지고 있지 않은 상황


KML

Keyhole Markup Language(KML)는 Google Earth(예전 이름:Keyhole Earth)의 성공과 함께 사실상의 표준이 되어 3D 지오브라우저를 통한 지리정보 데이터의 생산과 공유에 활용되고 있음
개체의 위치, 속성, 비주얼 스타일, 3D 모델, 주소, Atom 링크에 이르기까지 다양한 마크업 지원
OGC 표준으로 채택되어 발전중
단점
  - Google Earth라는 특정 애플리케이션 중심의 데이터 표현을 위한 포맷
  - 스타일 기능은 초보적이어서 캐스캐이딩 지원과 속성과 클래스 스타일링 기능 미흡
  - Google은 여전히 벤더 중심의 gx: 네임스페이스 기반의 KML 스펙을 주도하고 있는 상황이며 이러한 문제점에도 불구하고 Geo 커뮤니티 내에서 이러한 스펙의 문제점을 지적하고 있지 못함


GeoJSON

가장 최신의 표준이랄 수 있는 GeoJSON은 JSON 포맷에 지리적 마크업을 단순히 추가한 것이다.
클라이언트와 서버 사이의 커뮤니케이션이 주 목적이며 작은 데이터 크기와 JSON 데이터를 즉시 evalute 할 수 있는 장점이 있다.
GeoJSON은 명목상으로는 GeoRSS를 따르고 있어 GeoRSS의 장점을 그대로 활용 가능하다
단점
  - JOSN 자체에는 어떠한 포맷 스펙이나 스키마 정의가 정해진 것이 없기 때문에 클라이언트 입장에서 임의적으로 활용해야 한다(기반 스키마 표준이 없다)
  - 다수 서비스가 3rd 파티 개발자들이 API를 통해 GeoJSON을 사용하게끔 확산될 수록 문제가 커질 것이다


GML

XML의 지리정보 응용 형태로서 GML은 개발되었으며 지오그래픽 스키마와 특정 도메인에 적합한 데이터를 생산할 수 있는, 문법적으로 엄격하면서도 풍부한 기능을 가진 메카니즘을 제공한다
OGC의 WFS와 같이 정교한 데이터 교환에 사용되며 1D - 4D 지오메트리, 다수 도메인, 맞춤 프로파일, 버전 등 개발자 필요에 부응할 수 있는 기능들을 제공한다.
이러한 강력함에는 복잡함도 뒤따르는데 개발자는 필요에 따라 적절한 스키마를 고안하고 이에 따라 GML을 사용해야 한다.
복잡도가 크기 때문에 웹 개발자 입장에서는 오직 GML의 간단한 지리적 기능만을 추가하고자 하게 된다. 이러한 복잡성으로 인해 광범위한 확상이 저해되고 있다.


다른 포맷들

Spatialite : 공개 포터블 데이터베이스 Sqlite에 지리공간 기능 부여를 위한 확장. Sqlite는 파일 기반의 관계형 데이터베이스로 주로 클라이언트 쪽의 데이터베이스 기능 지원과 온라인과 오프라인을 구별하지 않는 서비스 제공을 위한 기반 인프라로 활용되는 추세

GeoPDF : 오픈 포맷이 되기 위해 노력중. 미국 FGDC에서의 온라인으로 무료 제공중인 지도 데이터 포맷. Georegistration embeding을 위한 OGC 채택을 기다리고 있으며 Adobe는 ISO 32000 스펙에 벡터그래픽과 지오그래픽 드로잉 지원 기능을 추가하기 위해 노력중. 하지만 기본적인 환경이 기존의 GIS와 이질적이어서 지리정보 데이터 통합보다는 단절시킬 우려가 있음

CAP(Common Alreting Protocol) : 긴급뉴스, 지진, 행정적 신호와 같은 경고성 데이터를 실시간 공유하는데 초점을 둔 포맷으로 전송과 타임라인에 대한 실실적 구현은 아직 미흡. 또한 Atom과 같은 기존 포맷에 비해 어떠한 장점이 있는지 명확치 않음

그외 CSV / OSM(OpenStreetMap) / RDF / OWL  ...


서비스

데이터 포맷과 함께 다수의 GeoWeb 서비스(또는 인터페이스) 표준들이 있는데 OGC가 이 영역을 주도하며 WFS, WMS, 기타 카탈로그와 LBS 인터페이스 와 같은 다양한 쿼리 스펙들을 만들어왔다.

WFS와 WMS 모두 충분한 기능 제공하여 왔으나 그 인터페이스 패러다임이 매우 낡은 것이다. 다행히도 SOAP를 따르지는 않았으나 바운딩박스, 레이어, 포맷, 프로젝션 등 매우 간단한 쿼리 파라미터에 기반하고 있다. 더 큰 문제는 서비스 정보가 서비스 그 자체의 마지막 부분에 포함되어 있으며 서버측에서 문서와 에러에 대해 잘못된 MIME 타입을 사용하는 경우가 있다는 것이다.
최근에는 W3C와 같은 일반 웹 표준 기구에서 지리공간적 정보 추가를 위한 브라우저 DOM geolocation, HTTP 위치 정보 등을 시도하고 있다는 점이다. ISO와 OASIS에서는 OpenSearch-Geo를 밀고 있다.
OpenSearch-Geo는 GeoJSON, GeoRSS과 개념이 유사하며 널리 쓰이고 있는 인터페이스에 지리공간적 요소를 추가하는 방식으로 간단히 확장시킨 것이다. 또한 스펙의 템플릿만으로도 Flickr, KML Network Links 등의 일반적 API에 적용 가능하다. WFS의 경우는 적절한 템플릿 마크업을 사용할 수 있다.
그러나 OpenSearch-Geo에 대한 관심이 높아지고 있긴 하지만 실제적 활용은 그다지 나타나고 있지 않다.


종합적인 관점

이렇게 현재 GeoWeb 데이퍼 표준들은 막 섞여 있지만 이러한 표준들이 주류가 될 것임은 의심할 여지가 없다. Mapufacture와 GeoCommons를 운영하면서 여러 인기있는 데이터 포맷들의 업로드, 다운로드, 링크 상황에서의 사용 빈도의 증가와 감소 현상을 볼 수 있었다. Mapufacture와 GeoCommons는 사용자가 직접 자료(자료 링크)를 올리고 등록하며 원하는 자료를 원하는 형식으로 다운로드 받을 수 있게 만든 서비스로 웹을 통한 지리공간 데이터 포맷의 사용 빈도에 대한 새로운 시각을 얻을 수 있었다.


위 차트는 GeoCommons, Mapufacture에 업로드된 geodata의 데이터 포맷 구성비, 링크된 데이터 구성비, 전체적인 구성비를 보여준다. 특이한 것은 다운로드의 경우 명확하게 경량의 표준 포맷 중심으로 이루어지는데 KML이 전체의 67.8%, CSV가 25.7%, Shapefile은 겨우 6.3% 밖에 안된다는 것이다. OGC표준이나, 래스터 데이터와 서비스 등과 같이 전체적인 요소가 아닌 작은 규모 단위에서의 시행 결과이기는 하지만 사용자 입장에서 GeoWeb 기반의 데이터 활용 빈도가 높다는 것을 보여준다. 다양한 포맷들이 활용되고 있기는 하지만 어떠한 상황에서 어떠한 데이터 포맷이 가장 효과적인지는 명확하지 못한 상황이다. 이러한 현실에서 애플리케이션은 다수 포맷을 지원해야 하며 사용자와 서비스 공급자 입장에서도 중복된 서비스와 포맷 사이에서 혼란이 생길 수 있다.

GeoWeb Standard 두번째 파트 끝.

(관심 있는 독자를 위한)세번째 파트에 대한 원문 링크 => GeoWeb Standard-Current Problem.
Trackback 0 Comment 0


티스토리 툴바