Cosmic Background Noise

약 1년여 동안 수집한 POI와 개선된 등고선 지도를 포함한 새 버전의 KOTM을 만들었다. 버전은 3.5. 동호회에만 올리고 깜빡, 바빠서 작업 노트 올리는 걸 잊고 있었다. 누구 보라고 쓰는 글은 아니지만 나중에 내가 한 작업을 정리해 두지 않으면 어김없이 길을 잃을 것이다.

KOTM 3.0을 올린 후 Garmin Mobile XT에서 한글이 깨진다는 댓글을 보고 문제를 열심히 찾아 보았다. 내 경우엔 한글이 깨지다가 안 깨지다가 제멋대로였고 Mobile XT를 사용하지 않아 별로 신경을 안 썼지만 이왕 올린 것, 문제점을 알았으면 수정해서 올려야 겠다고 생각했다. 직원에서 블루투스 GPS를 빌려 Garmin Mobile XT를 하루 정도 테스트했다.

원인을 찾았다. mapset 중 하나라도 코드페이지가 949가 아니면 한글이 깨진다. 꽤 희안한 버그라서 사실 좀 믿기지가 않지만 뭐 현상이 그런 걸 어쩌겠나. 하루 종일 틈만 나면 지도를 빌드하면서 원인을 찾은 것. 일단 문제는 찾았지만 압축을 풀면 1GB가 넘는 데이터를 올리면서 고작 그런 버그 하나 때문에 여러 사람들 불편하게 한 것이 미안해서 원래 KOTM 3.5에 적용하려던 것들 몇 가지를 3.1에 급히 쓸어 담았다. 대표적으로, Makefile로 지도를 빌드하게 해 놓았다. 그리고 스타일(*.TYP)을 전면 적용. map feature의 아이콘을 대폭 수정했다. 그 두 가지는 혹시나 있을지도 모를 지도 작업자들을 위해 기본적인 작업 환경을 제공한다는데 의미가 있는 것들이라 일반적으로 지도를 사용하기만 하는 사람들에겐 별 의미가 없는 것들이지만.

mkgmap r1177 버전 이후로 topo map이 일부 깨지는 현상을 목격했다. 리비전 간의 차이를 알아내기 위해 꽤 삽질해서 밝혀낸 것이다. 다음 GPSGIS 카페에 올린 KOTMv3 소개

OSM 한국 매퍼가 조금씩 늘고 있다. 지도의 크기는 연초에 비해 무려 17배가 늘었다. OSM 작업 방식, 예를 들면 potlatch나 JOSM 등의 프로그램 사용법 등을 매뉴얼로 만들까 하다가 번번이 그만 두었다. 동영상 강의가 있으니 그거 보면 쉽게 알만한 것이라 따로 설명한다는게 좀... 하지만 OSM 저변을 확대하기 위해 뭔가 하면 좋을 것 같긴 하다.

120개의 시군에 지도 제작자가 각각 한 명씩 있고 그들이 GPS로 트랙로그를 만들어 지도를 그리는 작업을 한다고 가정하면 대략 8개월이면 한국 지도의 상당 부분이 완성될 것 같다. 나 혼자 작업하더라도 GPS 들고 자전거 타고 샅샅이 돌아다니면 시가지 면적 60km^2 정도의 왠만한 중소 도시의 매핑에 한 달이 안 걸릴 것 같다(1주일에 하루 실측을 위해 돌아다니고, 하루 매핑한다고 가정하면 약 4일간 도심에서 400km를 이동). 조만간 한 번 해 볼 것이다. 독일 매퍼들처럼 어느 날 한 도시를 완전히 매핑했노라고 자신만만하게 선언해 보고 싶긴 한데,  한국처럼 역동적인 곳에서 완전한 매핑이란게 말처럼 쉬운 것이 아니다.

OSM 한국 지도를 정기적으로 다운 받아(XAPI 서버가 드디어 복구되었다!) 한글 로마자 변환과 고아 노드를 삭제하고 있다. 깨끗한 지도가 되었지만 남들 작업해 놓은 것을 괜히 임의로 수정한다고 여기지 않을까? 선의로 하는 것이니 부디 그렇게 생각하지 않았으면 좋겠다.  항의가 들어오면 즉각 중단할 것이다.
 
KOTM v2.5 버전을 만들었다.  다음 GPSGIS 동호회에 올린 글로 대체:
http://cafe.daum.net/GPSGIS/BT6Y/862

KOTMv3 이후엔 딱히 더 할 일이 없을 것 같다. 딱 1년 목표로 프로젝트를 시작했는데, 10월이면 프로젝트가 완료되고 따라서 이 작업노트 역시 종료된다.

DDoS 공격 진원지로 몇몇 언론이 북한을 집더라. 입에 게거품을 물고 시장주의를 찬미하던 어떤 언론은 포이즌 필을 옹호하기도 했다. 콧방귀를 뀌었다. 마이클 잭슨이 사망했을 즈음에는 그런 언론더러, 'you are not 언론' 이라고 말하더라.

planet.osm 파일이 워낙 커서 보통 배포되는 형태인 planet-090702.osm.bz2 파일을 압축을 풀지 않고 그대로 작업한다. osmosis의 위키 페이지에는 이런 식으로 명령을 지정하라고 적어 놓았다.

bzcat planet-090701.osm.bz2 | osmosis.bat --read-xml file=- --bounding-polygon file=skorea.poly.txt --write-xml file=skorea.osm

OSM 작업자가 슬슬 늘어나고 있는 것 같다. 아쉽게도 지금까지 지도 작업 때문에 컨택해 온 사람들은 모두 외국인이다. 한국인도 있을 테지만 조용히 작업해서인지(나도 마찬가지고) 서로 연락이 없다. 오히려 그 편이 좋을지도.

지도를 만들다 보니 한강이 이상하게 꼬여 있어 무슨 일인가 싶어 확인했다. 한강이 망가져 있다. 어떤 작업자가 한강을 수정하다가 날려 먹은 것 같다. 이번에는 좀 심각하다. 사실 그 작업자의 잘못은 아니고, 4월에 API가 0.6으로 업그레이드 되면서 way 하나당 node 수를 2000개 미만으로 제한해 놓아서, 한 번 수정했다가 저장하는 도중에 way 연결과 relation이 날아간 것 같다. 한강은 거의 5천 여개의 노드로 이루어져 있었다.

OSM에서는 아마도 DB 부담을 줄이려고 2000개란 제한을 둔 것 같은데 안 그래도 그것 때문에 커다란 폴리곤을 분할하는 작업이 필요해서 골치가 좀 아팠다.

한강 복구하다가 나도 날려먹었다. Potlatch가 API 0.6에 맞춰 1.00으로 업그레이드 한 후 화면에 node와 way가 좀 많다 싶으면 다운되기 일쑤다. Potlatch에서 작업한 내용이 업로드 중에 프로그램이 다운되면서 node중 일부만 전송되고 나머지가 전송되지 않아 그 동안 애써 복구한 한강 라인이 가볍게 날아가버렸다. 애당초 가벼운 작업에나 쓰는 Potlatch로 작업한 내 불찰이다. 속이 쓰리다.

JOSM으로 작업하려다가... JOSM도 그리 편한 프로그램이라고 여길 수 없다.  적어도 죽지는 않지만 java 프로그램이라서 그런지 자료가 좀 많다 싶으면(10MB 이상, 서울시만 현재 32MB) 작업이 거의 불가능해진다.

혹시나 하는 마음에 Mercaator 새 버전이 나왔나 살펴봤다. 이전 버전은 API 0.6과 호환되지 않고 자주 죽어서 작업하기가 힘들었다. 새 버전이 나왔다. 메르카토르로 한강을 다시 그렸다. 간신히 업로드하니 어언 4시간이 흘렀다.

메르카토르에서는 multipolygon 작업(relation 작업)이 좀 이상하게 되는 것 같다. multipolygon은 강 위에 떠 있는 섬 따위가 강과 relation을 가지고 있는 것들을 말한다. 강은 outer polygon이 되고 inner polygon으로 섬을 포함하는 것이다. 쉽게 말해 다각형 안에 다각형을 포함하고 그 관계를 지정하는 것.

한강의 노들섬 따위는 인간이 주거하지 않기 때문에 island 대신 islet 태그를 사용하는 것이 정석이다. islet이 공식 태그가 되었는지 아직 잘 모르겠다. 평소처럼 natural=land(육지)로 태그를 지정했다. 그렇게 해도 섬은 섬이다.

한강처럼 큰 강은 waterway=river가 아니고 waterway=riverbank로 tag가 지정된다. multypolygon은 JOSM에서 작업한 내용을 불러와 다시 만들어 저장했다.
 
한강은 대충 되었고, 조만간 4대강 유역 정비사업(?)도 벌일 계획이다. 사실 하고 싶지 않다. 수계 데이터만 구할 수 있으면 자동으로 할텐데 말이다. 그래도 way당 node 2000개 제한 때문에 골치가 아프겠지만.

API 0.6 개정 이후 별별 문제가 다 생겼다. 무슨 작업을 하건 이전보다 3-4배 이상 시간이 걸렸다. 작업을 끝내고(API 로 upload 후) 작업한 내역을 확인할 때마다 XAPI로 해당 지역을 다운받아 확인해 보면 적용되어 있지 않았다. (매번 하는 실수지만) XAPI와 API 사이의 적용이 되는 시차 때문에(약 10~15분)  변경 내역을 확인하려면 일정 시간 기다려야 한다. 이건 아직은 어쩔 수 없어 보인다.

osm 파일 Uploader를 만들다가 이상하게 changeset이 업로드가 안되는 현상을 목격했다. 이전에 JOSM으로 10MB 짜리 파일을 업로드할 때도 같은 현상이 벌어졌다. 490KB 짜리 파일은 업로드에 실패하지 않았다. 업로드가 잘못되면 중복 데이터가 이중으로 들어갈 우려가 있어서 작업량이 두 배로 늘어나기 때문에 다른 사람들은 업로드를 어떻게 했는지 살펴 보았다.

미국에서 TIGER(Topologically Integrated Geographic Encoding and Referencing)와 NHD(National Hydrography Dataset)  자료를 OSM으로 변환하여 업로드하려는 시도가 있었다. 자세한 내용은 귀찮아서 검색하지 않았다. 하여튼 요점은 미국에서도 개별적으로 지도 제작을 하던 사람들이 많이 있었고, 국가가 만들어놓은 엄청난 양의 자료가 있어서 그것들을 import하는 와중에 작업자들 사이에서 말이 많았나 보다.

내가 지금 하는 작업처럼, 이미 누군가 도로 작업을 해 놓은 것을 다 엎어버리고 표준 도로 데이터랍시고 올리면 과연 누가 좋아할까? 그들이 한 작업이 모두 일순간 삽질이 될 수 있는데! 하지만 그럴만한 값어치가 있다면야... 그리고 실제로 한국 지도 만들면서 가장 많이 삽질한 사람은 나다. 다른 사람들은 나만큼 수개월에 걸쳐 이렇게 OSM에 집착하지 않았다. -_-

OSM의 bulk upload 프로그램이 perl용으로 있지만 API 0.6과는 호환되지 않았다. 누군가 bulk_upload.py라는 API 0.6과 호환되는 python 스크립트 파일을 올려놨는데 그것도 문제가 있었다. 역시 내가 작성했던 프로그램과 마찬가지로 어떤 상황에서는 timeout이 걸리고 중단된다.

웹질을 열심히 해보니 OSM 메일링 리스트에서 딱 한 건의 article과 그에 대한 응답(서버 문제인지 클라이언트 문제인지 알 수 없다)를 찾았다. 업로드 에러에 관한 알맞은 답변은 찾지 못했다.

OSM이 비영리단체다 보니 OSM에서 생기는, 서버의 안정성 따위 온갖 문제들로 머리가 아프다. 질문자가 수정한 파이썬 업로더 프로그램이 내가 짠 프로그램보다 훨씬 간단해서(파이썬이 이렇게 좋은 언어였나?) 이걸 사용해 자료를 업로드하기로 했다. 게다가 통신 에러로 업로드 중 죽어도(요즘 OSM 서버가 엄청나게 느리고 간혹 접속이 안되는 등 별별 에러가 다 난다) 이전 업로드된 내역을 기억하고 있다가 죽은 시점부터 다시 업로드를 하는 아주 쓸모있는 기능이 있다.

파이썬 3.0.1에서는 스크립트가 실행되지 않아 2.6.2 버전을 Windows XP 머신에 설치하고 httplib2 파이썬 라이브러리를 설치했다. hashlib는 버전이 낮은지, 뭔가 문제가 있어 설치가 되지 않았지만 bulk_upload.py 작동에는 지장이 없었다.  python용 모듈은 mingw32나 Visual Studio 2008 버전에서만 제대로 컴파일 된다고 하는 기사를 봤는데 그거 설치하려면 또 세월이라 작동하는 정도면 굳이 모듈을 셋업하지 않았다. win32에서만 생기는 문제인 것으로 짐작되는 버그가 있어 소스를 조금 수정했다. 이 김에 python을 배워볼까?

개정된 업로드 스크립트는 changeset당 element 갯수를 5000개로 제한해 놓았고, 그 마저도 서버에 부담을 줄까봐 300개씩 끊어서 엘리먼트를 전송한 후 랜덤 딜레이를 30~90초 사이 준 다음 하나의 changeset을 전송한 다음, 다른 changeset으로 전환해서 진행하는 형태다.

최근에 서버를 바꿨다고는 하지만, OSM 서버가 어찌나 느리고 문제가 많은지 이 양반도 이런 식으로 밖에 업로드할 방법이 없었던 모양이다. 하긴 예전에 OSM 파일을 전송하는 프로그램을 짜서 돌릴 때도 엘리먼트가 초당 고작 1개씩 올라가는 꼴을 업무시간 내내 지켜보다가(스레드 10개가 동시 작업하고 있는 데도), 집에 퇴근했다가 다시 출근해서야 작업이 끝났다. 몇 시간 걸렸는지는 기억나지 않는다. 여기 블로그 어딘가 적어놓긴 했을텐데...

사무실 컴에 업로드를 걸어놓고 퇴근했다. 저수지 및 호수 데이터와 6만여개의 행정구역 데이터다. 집에서 새벽 1시쯤 원격 접속해 확인해 보니  업로드중 죽었다. 역시. 다시 실행했다. 다음날 아침 와보니 업로드가 끝나 있었다. 업로드한 파일 크기는 30MB 가량.

내가 OSM 작업을 처음 시작할 당시(올 3월 무렵) 남한 데이터 파일 크기는 8MB 였다. 남한은 안동과 대전, 서울 일부 지역을 제외하고 황무지나 다름없었다. 지금은(6월 현재) 230MB 가량으로 대폭 늘어났다. 이제 도로 작업이 남았다. 아무 생각하지 말고 그냥 확 올려버릴까? 도로 데이터가 350MB다. 올리는 것도 문제지만, 파일을 업로드하기 전에 좀 더 생각해 봐야겠다.

업로드가 끝나면 얼마나 후련해질까? 그동안의 삽질이 눈물젖은 과거가 되는 걸까? 1년에 한번씩 업데이트 되는 그놈에 '표준 도로'를 내년에 또 업데이트할 일이 생길까? 문화관광부 장관은 OSM 지도 보고 한국도 갈만한 깡촌이란 걸 깨달은 웨스터너들이 왕창 생기면 나한테  포상금을 쥐어주며 고마워할까? -- 사실 그런걸 바라고 OSM 작업을 하는 것은 아니다. 노무현 전대통령처럼 기록과 자료와 전승의 소중함을 안다. 그것이 아마도 내가 서양 문화에서 받은 가장 큰 영향일 것이다.

srtm2osm.exe 로 울릉도, 독도만 따로 변환했다. srtm2osm 프로그램은 더이상 업데이트가 이루어지지 않는다. 요즘은 groundtruth를 사용하는 듯 한데, groundtruth의 dem topo map은 작업중 프로그램이 죽어버리는 데다 생성된 osm 파일이 이해가 안 갈 정도로 이상해서 쓸모가 없다. 그래서 하는 수 없이 srtm2osm으로 작업했다.

작업노트#7에서 언급한 지도 작업은 약 2주쯤 지연되었다.

작업 영역이 전방위적이라 정신 사나워서 중간 정리의 필요성을 느꼈다. 사실상 OSM 작업의 분수령을 이루는 시점이기도 하다.

• WideCharToMultiByte(CP_UTF8, ...)

• MultiByteToWideChar(CP_UTF8, ...)