Cosmic Background Noise

OSM 작업을 하면서 가장 불편한 것은 한글과 영문 이름 병기다. POI 마다 한글명과 영문명 태깅을 하는 것보다는 일단 한글명만 적어두고 나중에 한꺼번에 바꾸는 것이 효율적일 것이다.

한글의 romanize는 node 또는 way에 name:en 태그가 없고, name 태그에 괄호 '('가 없을 때만 로마자 변환을 한다. 괄호가 있는 것은 괄호 속에 영문 표기를 했다고 가정하므로 변환 대상이 아니다.

두번째로 작업중에 실수로, 또는, 삭제하다가 프로그램이 다운 되는 등, 부지불식 간에 생긴 orphan node을 삭제한다. orphan node란 아무런 tag가 지정되어 있지 않고 way의 맴버가 아닌 node를 말한다. 이때 tag중 created_by는 별 의미가 없으므로 무시한다. tag가 지정되어 있는 node는 그게 무엇이라도 삭제하지 않는다.

고아 node의 예. 태그를 가지고 있지 않음. way에 소속되어 있지 않음. 위의 경우 way 삭제 중 사고로 way는 지워졌지만 way의 맴버였던 node가 삭제되지 않은 경우다. 가끔 이런 사고가 발생한다. 이걸 손으로 지우는게 많이 귀찮다.

일단 두 가지 작업을 위해서 남한 OSM 파일을 얻어야 하는데, cloudmade.com에서 매주 제공하는 남한 OSM 파일은 완전한 것이 아니라서(남한의 일부 영역이 잘렸다) planet.osm 파일을 직접 다뤄야 한다. cloudmade.com에는 내가 만든 south_korea.poly 파일을 보내줬다. 그들이 그걸 사용해서 남한 OSM과 IMG를 만들어주면 좋겠다. 그렇게되면 한국의 GPS 사용자들이 변환 등의 거추장 스러운 작업 없이 Garmin용 IMG 파일을 거저 다운받을 수 있게 된다.

매일 커지기만 하는 6GB 용량의 planet.osm을 작업할 때마다 매번 다운받을 수도 없는 노릇이다. 2009/7/24일 평균 1Mbps의 전송속도로 2시간 가량 걸렸다. OSM 역시 그것을 염두에 두고 있어서 일주일에 한 번씩 planet.osm을 덤프하고 다음 7일 동안 매일 또는 매 시간 단위로 이전 일시부터의 변경 내용만 덤프한다. planet.osm의 대표적인 mirror site에 이런 변경 내용이 매 시간 단위로 업로드된다.

즉,  planet.osm을 한 번만 다운 받고 매일의 변경 내용을 다운받아 패치하면(일일 약 20MB 가량) 최신 버전 파일을 유지할 수 있다. 전 세계 데이터가 다 필요한 것은 아니므로 한국만 계속 업데이트 하면 될 것이다. 처음에 작업할 때는 planet.osm 원본 파일을 사용하여 한국 지역만 들어내고 changeset을 적용한다. 7월 22일 받은 planet.osm.bz2와 22-23일 변경분, 23-24일 변경분으로 작업하는 과정:

bzcat planet-090722.osm.bz2 | osmosis.bat --rxc file="20090722-20090723.osc" --rx file=- --ac --bp file=skorea.poly.txt --wx file="korea-090723.osm"

그 다음부터는 이렇게 해서 만든 korea-*.osm에 changeset을 적용한다.

osmosis.bat --rxc file="20090723-20090724.osc" --rx file="korea-090723.osm" --ac --bp file=skorea.poly.txt --wx file="korea-090724.osm"

orphan node 제거 및 이름 변경용 어플리케이션으로 삭제할 노드 리스트가 담긴 osm 파일과 이름이 추가된 osm 파일을 생성한다.

생성된 두 파일을 가지고, JOSM을 이용하던가 python으로 짠 delete 프로그램과 modify 프로그램으로 각각 OSM에 적용한다.

주의: JOSM은 way의 이름만 변경하더라도 way가 참조하는 모든 node가 기술된 'complete OSM file'만 적법하다고 인정하므로 modify된 way 태그를 업로드할 수 없다.

아무래도 이 작업을 가끔씩이나마 하는 것이 좋을 것 같다. 이번에 몇몇 산들의 트래킹 코스를 작업하면서 일일이 영문으로 토달기가 귀찮아서 일을 벌인 셈이지만 주기적으로 이런 작업을 해주면 한국 지도가 깔끔해 질 것 같다.

아무래도 주말 중 하루는 종일 컴퓨터를 돌려야 할 것 같다. 뭐, 말로 적어 놓으면 쉽고 간단하지만 컴퓨터로는 CPU 부하율 100%로 하루 종일 뺑이치는 작업이다. 다운로드 2시간, planet.osm 뜯어내기 3시간, 2-3일 변경분 적용 1시간. 고아 노드 분리 10분. 노드 삭제 3시간. 노드 업데이트 1시간 가량 예상.

트래킹 코스는 다음 GPSGIS 카페에서 수집한 산행 트랙로그를 GPX로 변환한 다음 OSM 홈페이지에서 업로드하고 Potlatch로 일일이 라인을 그리고 POI를 손봤다. 상당히 시간이 많이 걸리는 작업이지만 GPS Trackmaker 프로그램에서 Tracklog를 reduce 해서 그대로 업로드하는 것보다 정밀하다. 왜냐하면 동일한 산행 코스 트랙로그를 여러개 겹쳐 그중 가장 그럴듯하고 올바르다 싶은 길을 라인으로 그리면서 따라가기 때문이다.

만일 그것을 프로그램으로 짜서 했다면 그들 트랙의 평균적인 길을 고르게 되는데, 산행 중 GPS의 오차가 거치 방법에 따라 현저하게 차이 나기 때문에 프로그램으로 판단하는 것은 오류가 클 여지가 있다. 뭐 잘 짜여진 룰베이스를 가지고 스스로 백그라운드 야후 위성 사진에 나타난 도로와 GPS 트랙로그의 오차를 보정하면서 좌충우돌 학습하는 인공지능 프로그램이라면 얘기가 다르겠지만 그런 프로그램은 짜기가 무척 어렵다. 그 프로그램 짜서 키울(?) 시간이면 한국의 100대 산 트래킹 코스를 완성하고도 남는다.

GPS 위성은 매우 고속으로 지구 궤도를 움직이고 있다. GPS 위성의 시계는 그래서 특수상대성이론에 따른 시간 지연이 발생한다. GPS 리시버에서 발생하는 트랙로그의 오차는... GPS의 매우 정밀한 클럭에 일정 정도의 노이즈를 넣어 시간 정밀도를 일부러 떨어뜨리는 SA(Selective Availability)에 의해서만 결정되는 것이 아니다. 보정 기술의 발달로 SA의 영향은 최근들어 상당히 작아졌다. 그러나 트랙로그가 기록될 때 GPS의 프로세서는 측정 시점과 기록 시점이 완전히 일치하지 않는다. 그리고 이전 측정 시점과 다음 측정 시점 사이의 시간 간격이 측정 정밀도에 영향을 끼친다. GPS 기기에 오차가 +-4m라고 표시되도 사실상의 오차는 +-20m 까지 감안해야 한다. 언급한 세 가지 이유 때문에 GPS의 트랙로그는 그렇게 믿음직 스럽지 않다.

능선이나 개활지에서 걸을 때, 즉, 저속일 때에는 여러 개의 트랙로그를 겹쳐놓아도 위치 오차가 크지 않지만,

하늘이 잘 보이지 않는 계곡에서는 위성 수신 불량으로 오차 폭이 대단히 커지고,

위성 수신 상태가 양호하더라도 고속으로 운행중인 자동차에서 같은 구간을 운행하더라도 그림에서 보는 것처럼 동위도에서 기록 오차가 발생하며, GPS의 측점 간 오차가 GPS에 표시된 오차보다 크게 나타난다.  

하여튼 데이타가 그다지 크지 않을 경우 사람이 트랙로그를 여러 차례 만들어 겹쳐 놓은 상태로 보고 '궁리'하며 그리는 것이 개발도 힘든 인공지능 프로그램을 짜는 것보다 낫다. 이쪽은 그래서 프로그래밍을 포기했다(누군가 하겠지).

트래킹 자료가 어느 정도 진전되면(한국의 100대 명산) KOTM 새 버전을 만들어볼 생각이다.  지금까지 서울 근교 5-6개의 유명 산행로를 '그렸다'. 북한산 및 도봉산 트래킹 코스