• 지리 공간 데이터를 표현(인코딩)하기 위한 JSON 기반 포맷
• 단순 위치뿐 아니라, 공간값 + 메타데이터를 모두 표현할 수 있게 설계된 공간 객체 모델
• 공식 명세: RFC 7946

구조

기본적으로 Feature와 FeatureCollection, 그리고 Geometry 타입으로 구성

 {
       "type": "FeatureCollection",
       "features": [
	       {
	           "type": "Feature",
	           "geometry": {
	               "type": "Point",
	               "coordinates": [102.0, 0.5]
	           },
	           "properties": {
	               "prop0": "value0"
	           }
	       },
       ]
   }

1. Geometry (지리적 도형) 타입

가장 핵심적인 부분으로, 위치와 형태를 포함
6가지 데이터 타입 존재:

타입	설명	예시
Point	단일 점(좌표 [경도, 위도], WGS84만 허용)	[126.9779692, 37.566535]
LineString	선 (좌표(점)들의 배열)	[[126.9, 37.5], [127.0, 37.6]]
Polygon	다각형 (좌표 배열의 배열, 닫힌 경로 = 첫 점과 끝 점이 같음)	[[[x1,y1],[x2,y2],...[x1,y1]]]
MultiPoint	여러 점	[[x1,y1], [x2,y2]]
MultiLineString	여러 선	[[[x1,y1],[x2,y2]], [[x3,y3],[x4,y4]]]
MultiPolygon	여러 다각형	[[[[x,y],...]], [[[x,y],...]]]
GeometryCollection	다양한 Geometry를 묶는 컨테이너	{ "geometries": [ ... ] }

  "geometry": {
	    "type": "Point",
	    "coordinates": [126.9784, 37.5666]
  },

좌표

• WGS 84 좌표계만 허용 (항상 [longitude, latitude] 순서를 따름)
• EPSG:4326을 사용하며, 직사각 투영 방식임을 가정함
• 때문에 다른 좌표계 사용 불가하며, 좌표계를 임의로 지정하면 안됨
• 고도(z축) 정보가 있다면 [lon, lat, alt] 형식으로 사용

2. Feature 타입

• 하나의 Geometry + 속성 정보("properties")으로 구성된 단일 객체
• 실제 좌표 + 해당 대상에 대한 메타 데이터
• Feature는 항상 geometry 필드를 갖지만, 그 값은 null일 수 있다 (예: 속성만 있는 경우)

{
	  "type": "Feature",
	  "geometry": {
	    "type": "Point",
	    "coordinates": [126.9784, 37.5666]
	  },
	  "properties": {
	    "name": "서울시청",
	    "category": "government"
	  }
}

3. FeatureCollection 타입

• Feature 여러 개를 묶은 상위 구조체
• = 여러 객체를 하나로 묶어서 전송할 수 있다

{
	  "type": "FeatureCollection",
	  "features": [
	    {...}, {...}
	  ]
}

장단점

왜 사용할까?

장점

• JSON형식이기 때문에 구조가 직관적이며, REST API와도 잘 어울림 -> 프론트엔드에서 활용하기 적합
• 때문에 D3.js, Leaflet, Mapbox 등에서 바로 읽을 수 있음
• 속성 + 위치 같이 관리하기 때문에 공간 정보와 메타데이터를 함께 다룰 수 있음
  
  

단점

• 좌표계 한정 (WGS84(EPSG:4326)만 지원)
• 정의된 타입 외 추가 금지. 구조 임의 확장 불가
• 과도하게 정말한 좌표값 제공 금지. 불필요한 오차 및 용량을 증가하기 때문
  - -> 정밀한 공간 분석에는 부적합
  - 복잡한 공간 연산은 Shapefile, WKT + PostGIS 같은 형식이 적합
• JSON 스트리밍 지원 안 함 → 필요하면 RFC 8142 참조
• 대용량 데이터는 압축 없이 전달되므로 속도 이슈 있음
• Topological 정보 부재로 해당 관계를 표현할 수 없음
  - 즉, 공유 경계 (두 도형이 맞닿는다는 정보) 없음
  - 이런 GeoJSON의 구조적 한계를 해결한 상위 포맷으로 TopoJSON이 있음
  
  
  
  

---

TopoJSON

TopoJSON은 GeoJSON의 상위 개념으로, 공간 데이터를 더 압축하고 효율적으로 표현하기 위해 토폴로지(위상 정보)를 포함한 JSON 포맷

	GeoJSON	TopoJSON
기본 단위	Feature = 좌표들의 모음	Topology = 공유되는 경계(arc)를 참조
중복 제거	없음 (경계가 중복됨)	있음 (경계는 1회 정의 후 참조)
파일 크기	크다 (좌표 중복 많음)	작다 (좌표 중복 제거)
데이터 구조	직접 좌표 포함	경계를 별도 정의 (arcs), 그걸 참조함
호환성	대부분 라이브러리에서 직접 지원	일부 라이브러리는 변환 필요 (topojson-client)
좌표계	WGS84만 허용 (RFC 7946)	좌표계 자유도 있음

필요성

GeoJSON은 경계가 중복되기 때문에 다음 문제가 생김:

• 시/도 경계와 군/구 경계가 겹치는 경우 동일 좌표가 여러 Feature에 반복됨
• -> 파일 크기 증가 + 정밀도 손실 + 불필요한 계산 증가

TopoJSON 사용을 통해 공유되는 경계는 한 번만 정의할 수 있게 됨

• 각 Feature는 좌표 배열이 아니라 arc의 참조 인덱스를 가짐
• -> 데이터 중복 최소화 + 공간 연산 가능
  
  

구조

• arcs: 실제 경계 좌표들
• geometries: arcs 배열을 참조하여 폴리곤 등 정의
• 좌표는 “delta encoding” (상대 좌표) 방식으로 압축됨

{
	  "type": "Topology",
	  "arcs": [
	    [[0, 0], [10, 0], [0, 10]]
	  ],
	  "objects": {
	    "example": {
	      "type": "GeometryCollection",
	      "geometries": [
	        {
	          "type": "Polygon",
	          "arcs": [[0]]
	        }
	      ]
	    }
	  }
}

정리?

1. TopoJSON은 GeoJSON의 구조적 한계를 해결한 상위 포맷
2. 중복된 경계 제거 + 위상 정보 보존 + 파일 크기 감소
3. 기본적으로 GeoJSON으로 변환 후 사용하는 방식이 일반적
   
   

---

참고 자료

• GeoJSON - 위키백과, 우리 모두의 백과사전
• RFC 7946 - The GeoJSON Format

• GitHub - topojson/topojson: An extension of GeoJSON that encodes topology! 🌐
• Difference between GeoJSON and TopoJSON | stackoverflow
• What is topojson and how is it different than geojson?

더 알아보기

• topojson 레포지토리 매직 코드 뜯어보기

관련 문서

• d3-geo
• 투영(Projection)