On Spatial: Clipping Contest 후기

약 한달전 FOSS4G 분야를 뜨겁게 달구었던 이슈가 하나 있었다.
바로 대용량 데이터 Clipping Contest!

다양한 상업 및 오픈소스 GIS 프로그램들이 참여(?)했으며, 수많은 댓글이 달렸다.
자세한 내용은 아래 참조 사이트들을 방문해 보면 된다.

ESRI의 경우 이에 이의(?)를 제기하고 10.1 버전에 반영하겠다고도 하니 집단 지성의 힘은 참으로 대단하다.

▣ 샘플 데이타 개요
- Contours20Ft : 52,521개로 구성된 등고선 라인 데이터
- StudyArea1MileBuffer : 938개의 버텍스로 구성된 단일 폴리곤 데이터

▣ 정리
- GIS엔진에서 Clip 성능에 영향을 주는 요인들
: Spatial Indexing
: Geometry Engine & Robustness
: Spatial Data I/O
: Clip 전략 및 방법

- 주요 Geometry(Topology) Engine들
: Open Source Java 계열: JTS Topology Suite(GeoTools/uDig/gvSIG...)
: Open Source C 계열: GEOS, 자체(GRASS 등)
: 상용: ESRI(ArcGIS Topology Engine), 기타 자체 엔진

- JTS Topology Suite/GEOS는 이미 충분히 검증됨

- Clip function에 대한 이해
: 다음과 같이 1개 이상 피쳐로 구성된 원본데이터(위 샘플데이터에 의하면 등고선), 여러개의 폴리곤 피쳐로 구성된 클립 영역 데이터가 있다고 가정하자.
: ArcGIS의 경우에는 아래 그림의 왼쪽과 같이 한 개의 라인이 생성
: 몇몇 GIS 프로그램에서는 아래 그림의 오른쪽과 같이 한개 이상의 라인이 생성
: 판단은 각자가 알아서 하시길.

▣ 그렇다면 망고시스템의 GXT Engine은?

- GXT Engine 시 JTS/GeoTools 기반하에 운영되므로 위 jgrasstools & uDig 벤치마킹과 크게 다르지 않다. 또한, 위 [Clip function에 대한 이해]의 그림으로 본다면 ArcGIS 방식을 따른다. 데이터 로딩 시간 약 1분, Clipping 시간 2(1:50 +- 10)분 소요되며, 실제 Clip된 데이터의 사이즈는 약 346MB 이다.

GXT의 경우 Shapefile을 쓸 때, GeoTools(대용량의 데이터를 저장하는 경우 문제가 있음)를 확장하여 사용한다.

* Hardware