지오해시 인코더 및 디코더
개인정보 보호 설계 — 브라우저에서 모두 처리됩니다
인코딩 모드에서는 위도와 경도를 정밀도 슬라이더와 함께 입력해 지오해시 문자열을 얻고, 디코딩 모드에서는 해시를 붙여 넣어 중심 좌표와 셀의 남서/북동 경계를 확인할 수 있습니다. 공간 인덱스, 근접 검색, 위치 데이터의 가명화 저장에 유용합니다.
지오해시가 실제로 인코딩하는 것
지오해시는 위도와 경도의 비트를 번갈아 끼워 넣고, 그 결과를 0~9 와 a/i/l/o 를 제외한 b~z 로 구성된 사용자 정의 알파벳으로 base32 인코딩합니다. 한 문자는 5 비트의 정밀도를 가지고 위도와 경도를 번갈아 정교화합니다. 결과 문자열은 짧고 URL 안전하며, 접두사 관계가 곧 공간 포함 관계로 이어집니다. 즉, "dr5ru" 로 시작하는 모든 지오해시는 dr5ru 셀 안에 위치합니다.
정밀도와 셀 크기
정밀도 1 에서는 지구가 약 5,000 km 너비의 32 개 셀로 나뉩니다. 정밀도 5 (적도 부근 약 4.9 km) 는 동네 수준의 그룹화에 적합하며, 정밀도 9 (약 5 m) 는 건물 단위에 맞습니다. 정밀도 12 는 약 4 cm 까지 좁혀지지만 측량 작업이 아니면 거의 쓰지 않습니다. 극에 가까워질수록 셀은 줄어듭니다.
지오해시를 쓰는 이유
문자열 접두사는 PostgreSQL, Redis, DynamoDB, SQLite 모두에서 잘 인덱싱됩니다. 어떤 지점에서 5 km 안의 점을 찾으려면 그 지점의 정밀도 5 지오해시를 계산하고 접두사 매칭으로 검색하면 됩니다 — 대권 거리 쿼리보다 훨씬 저렴합니다. 셀 경계 에지 케이스가 실제로 존재하므로 운영 파이프라인은 대상 해시와 인접 8 개 셀을 함께 조회합니다. 지오해시는 S2 와 H3 보다 단순하고 오래되었지만 핫 경로의 근접 워크로드에서는 여전히 가장 가벼운 선택지입니다.
자주 묻는 질문
- 정밀도 5 가 왜 도시 한 곳을 덮나요?
- 문자 하나가 5 비트이므로 정밀도 5 는 25 비트, 적도 부근에서 약 4.9 km × 4.9 km 셀을 만듭니다. 몇 km 너비의 도시는 셀 하나에 들어가기 때문에 차량 호출, 배달 앱은 빠른 매칭을 위해 운전자나 주문을 정밀도 5 지오해시로 묶곤 합니다.
- 근접한 두 지점이 다른 지오해시를 가지는 게 버그인가요?
- 버그가 아니라 그리드의 특성입니다. 셀 경계 양쪽에 있는 두 지점은 1 m 떨어져 있어도 공통 접두사가 없을 수 있습니다. 운영 환경에서는 대상 해시와 함께 인접 8 개 셀 (3×3 링) 을 같이 조회합니다.
- 지오해시는 어떤 알파벳을 사용하나요?
- 0~9 와 a, i, l, o 를 제외한 b~z, 총 32 글자입니다. 이 글자들을 제외해 저대비 폰트에서 0/1 과 헷갈리는 일을 막습니다. RFC 4648 base32 와는 다른, 이 사용자 정의 알파벳의 base32 입니다.
- S2 나 H3 와 비교하면 어떤가요?
- 지오해시는 셋 중 가장 단순하고 오래되었습니다. S2 (구체에 투영한 큐브) 와 H3 (육각 그리드) 는 극의 왜곡을 더 잘 다루지만 코드가 많이 필요합니다. 앱 수준의 근접 워크로드에는 지오해시면 충분하고, 지구 규모의 내비게이션·라우팅에는 S2/H3 가 유리합니다.
- PostgreSQL 에 지오해시를 안전하게 인덱싱할 수 있나요?
- 가능합니다. 해시를 text 컬럼에 두고 btree 인덱스를 걸면 접두사 검색 (LIKE 'dr5ru%') 이 매우 빨라집니다. 공간 쿼리가 필요하다면 PostGIS 를 함께 쓰면 좋습니다. 대부분의 경우 접두사 매칭만으로 충분합니다.
- Toova 는 인코딩한 좌표를 기록하나요?
- 아니요. 인코딩과 디코딩은 이 페이지의 JavaScript 내에서 모두 처리되며, 좌표와 결과 해시는 Toova 서버에 도달하지 않습니다.