GeoJSON은 커지면 브라우저 탭을 잡아먹고, GeoPackage는 웹으로 스트리밍이 안 됐다. FlatGeobuf는 바이너리 안에 공간 인덱스를 통째로 심어, 12GB 파일을 정적 저장소에 올려두고도 HTTP Range 요청으로 화면에 보이는 피처만 뜯어온다. GeoJSON의 진짜 후계자를 만난다.
확장자만 .gpkg일 뿐, 정체는 SQLite 데이터베이스 파일이다. 새 포맷을 발명하는 대신 세상에서 가장 많이 깔린 DB를 지도 컨테이너로 재활용한 발상의 전환 — 벡터·타일·좌표계·인덱스가 파일 하나에 다 들어가는 Shapefile의 공식 후계자를 만난다.
Shapefile은 파일 다섯 개가 한 묶음이었다. GeoJSON은 메모장으로 열면 사람이 그냥 읽는다. 웹 표준이 된 이 포맷의 구조(FeatureCollection), 좌표가 왜 하필 [경도, 위도]인지, 그리고 파일이 커지는 순간 무너지는 한계까지.
.shp 하나만 받으면 지도가 안 열린다. 속성은 텅 비고, 데이터는 아프리카 앞바다로 가고, 한글은 물음표가 된다. Shapefile이 애초에 파일 하나가 아니기 때문이다. 30년째 죽지 않는 사실상 표준의 정체와, 그 화석 같은 제약들.
구글맵 도로는 확대해도 칼같이 선명한데 위성사진은 픽셀로 깨진다. 같은 화면 안의 이 차이가 바로 벡터와 래스터다. 점·선·면과 격자 셀, 각자 잘하는 일, 그리고 언제 무엇을 쓸지 판단하는 기준까지.
5179로 받은 데이터를 4326으로. 코드 한 줄이면 되는데 왜 서울이 지도 밖으로 날아갈까. 좌표 변환이 실제로 하는 일과, proj4js·PostGIS·GDAL에서 사람들이 가장 자주 빠지는 네 가지 함정.
같은 127, 37.5도 좌표계가 다르면 다른 곳이다. 측지계와 투영을 숫자 하나로 묶은 EPSG 코드, 4326·3857·5179·5186의 차이, 그리고 한국 좌표계가 이렇게 많은 이유.
둥근 지구를 평평한 화면에 펴는 순간, 무언가는 반드시 거짓말이 된다. 그것도 수학적으로 증명된 불가능. 정각·정적·정거, 원통·원뿔·평면, 그리고 한국이 자기만의 좌표계를 쓰는 이유까지.
![GeoJSON 구조 완전정리 — 좌표가 [경도, 위도]인 이유 포스트 대표 이미지](/_next/image?url=https%3A%2F%2Fstorage.googleapis.com%2Fleehyeonjun.com%2Fgis%2F11%2Fgeojson-size.png&w=3840&q=75)
