'GPS' 카테고리의 글 목록

'GPS'에 해당되는 글 26건

2011.03.18 GPS, 자전거 주행, 칼로리 계산 4
2010.08.18 KOTM v3.5 10
2010.06.24 5800 GPS 안테나 개조 7
2010.02.22 지도 제작 작업 메모
2009.10.26 KOTM v3,1 3
2009.10.16 KOTMv3
2009.08.07 OSM 작업노트 #15: KOTM v2.5 공개
2009.07.24 OSM 작업노트 #14: cleanup 2
2009.07.09 OSM 작업노트 #13: 도로 업로드 작업 2
2009.06.30 OSM 작업노트 #12: 지도 공개 및 도로 2
2009.06.24 OSM 작업노트 #11: 도로 3
2009.06.19 OSM 작업노트 #10: 해안선과 도로
2009.06.05 OSM 작업노트 #9: bulk upload
2009.06.01 OSM 작업노트 #8: 새로운 지도 1
2009.05.21 OSM 작업노트 #7: 작업 중간정리 1
2009.05.14 OSM 작업노트 #6: Garmin용 지도 공개 1
2009.05.12 OSM 작업노트 #5: API 및 이것저것
2009.04.23 SportTracks 1
2009.03.27 OSM 작업노트 #4: POI 1
2009.03.18 OSM 작업노트 #3: GPS용 IMG 만들기 1
2009.03.16 OSM 작업노트 #2: 도로, 명명규칙, POI 확보
2009.03.10 OSM 작업노트 #1: Tool 3
2009.02.26 Open Street Map 1
2009.02.20 독립 GPS의 활용 14
2008.10.25 한국 지형도 데이터 구하기
2008.10.23 GPS용 한국 지형도 만들기 1

GPS, 자전거 주행, 칼로리 계산

GPS 2011. 3. 18. 20:31

상오기님 사이트에서 BikeTrack이란 프로그램 소개를 보니 칼로리를 출력하는 부분이 있다. 아마도 자전거 주행의 칼로리 소비량을 계산하는 간단한 방식을 이용하는 것으로 추측된다. 간단히 말해, 두 가지 중요한 팩터가 빠져 계산이 맞을 리가 없다.

자전거 주행은 페달을 밟아 동력계를 움직여 지면 마찰을 이용해 앞으로 나아가는데 1. 경사로를 달릴 때 중력의 영향을 받고, 2. 유체(공기) 속을 진행하므로 공기 저항을 받는다. 3. 타이어가 노면에서 마찰을 일으켜 진행하므로 마찰력의 영향을 받기도 한다. 그 결과로 뱃살이 쭉쭉 빠져야 하는데, 달리는 만큼 더 먹게 되어(아울러 기초대사량이 늘어) 살이 안 빠지는 아저씨들이 많다.

경사로가 업힐일 때는 몸무게에 비례해 뒤로 끌어당기는 힘이 크게 작용하지만 다운힐에서는 동력이 소비되지 않을 수 있다. 공기 저항은 면적에 비례하고 속도의 제곱에 비례한다. 뿐만 아니라 바람에 맞서면 당연히 더 힘들고 바람을 등지면 항력이 감소한다(마이너스가 되기도 한다. 샤방샤방 주행). 속도와 무게는 아주 중요한 팩터다. 몸무게가 줄면 덜 힘들다. 자전거가 가벼우면 덜 힘들다. 마찰계수가 작으면 덜 힘들다. 힘 좋은 아저씨들이 용을 쓰며 조금 앞서서 아줌마들과 200km를 함께 달려도, 아줌마들이 덜 피곤한 이유가 그 때문이다.

중력, 공기저항, 마찰력에 더해 자전거의 동력계 손실(좋은 자전거와 덜 좋은 자전거의 차이)과 근육의 ATP 소비에 따른 동력 손실을 감안하면 칼로리 계산이 그렇게 간단히 끝날 리가 없다.

바이크트랙이나 엔도몬도 등의 프로그램이 출력하는 칼로리 소비량은 믿을 수 없지만, 자전거 타기가 걷기나 뛰기보다 칼로리 소비가 더 크고 더 많은 운동량을 필요로 한다는 점은 변하지 않는다 -- 선수가 아닌 한 아무리 빨리 뛰어봤자 자전거보다는 느리기 때문에 공기저항에 따른 항력이 속도 제곱에 비례해 더 작기 때문.

공기 저항은 공기 밀도에 의해 결정되고 공기 밀도는 대기압에 따라 달라진다. 따라서 고도가 높으면 공기 저항은 감소한다. 그리고 맞바람은 주행속도를 깎아먹는다. 맞바람을 맞으면서 해수면에서 1500m 정상까지 업힐을 꾸역꾸역 오르다보면 존재론적 회의가 샘솟는 이유가 그래서다.

어느 정도 쓸모있는 칼로리 계산을 해보려고 심심풀이 삼아 웹을 뒤져 정리:

공기저항: Fw = 1/2 x A x Cw x D x V^2
A: Frontal Area (진행 방향으로 공기가 닿는 면적) 0.4~0.7

D: 공기 밀도(Rho)

Cw: Drag Coefficient. 보통 0.5 (Cycle 0.36, 하이브리드 0.45, MTB 0.7, 투어 바이크 0.8)

V: 속력 (시간당 이동거리)
마찰: Fr = G * W * Cr
G: 중력 상수. 9.81
W: 자전거와 라이더의 무게를 합한 것
Cr: 구름저항상수 (타이어와 도로 상태로 정해짐) 나무길 0.001, 콘크리트: 0.002, 아스팔트: 0.004, 울퉁불퉁한 포장길: 0.008.
중력: Fg = G * W * S

G: 중력 상수. 9.81

W: 자전거와 라이더의 무게를 합한 것

S: slope. 높이/이동거리.
F = Fw + Fr + Fg (watt)
초당 칼로리 소비량 = F * 859 / 3600 / 1000 (Kcal/sec)

공기 밀도 얻기: 참조(http://wahiduddin.net/calc/density_altitude.htm)

D = P / (R * T)

D: 공기밀도 kg/m3

P: 압력(대기압) pascal (millibar * 100)

R: 가스 상수 J/(kg*K). 287.05

T: 온도. 섭씨+273.15
예:섭씨 18도, 1020 hPa 일 때 공기밀도= 102000 / (287.05 * (18 + 273.15)) = 1.220
고도에 따른 기압 변화: p = 1013.25 * (1 - h / 44330.76)^5.255879746 (사이트 참조)

자전거 주행 속도는 바람 방향의 영향을 받는다. 주의: 힘의 크기를 구할 때, 맞바람일 때는 속도에서 더해져야 하고, 등질 때는 속도에서 빼야 한다. 전세계의 weather station으로부터 수집한 풍향 및 풍속 정보를 얻을 수 있는 곳을 찾아 보았다. 무료로 제공하는 사이트가 있다.

스테이션 위치를 지도로 보기

경위도 기반 스테이션 리스트 얻어오기 (XML 포맷)

일자별 기온,기압,풍향,풍속 정보 얻기 #1 (CSV 포맷)

일자별 기온,기압,풍향,풍속 정보 얻기 #2 (airport) (CSV 포맷)

이들 정보를 바탕으로 그나마(상대적으로) 정확한 칼로리 계산 프로그래밍 하기:

입력 상수: 한 번 입력되면 그다지 변경될 일이 없는 정보

자전거 종류 -> Cw

자전거 무게 -> W

사용자 몸무게 -> W

전면 면적 -> A
입력: GPX 등의 표준 포맷으로 입력받아 일괄 계산하거나, 실시간 계산할 때는 GPS 디바이스의 NMEA 출력 중 현재 측점과 이전 측점(n-1, n)이 필요.
Data Repositary: 풍향,풍속 정보를 얻기 위한 스테이션 위치 정보는 웹 사이트를 통해 매 번 query할 필요 없이 리포지터리 형태로 가지고 있으면 된다. 웨더 스테이션이 이리 저리 돌아다니는 것이 아니라서, 한 번 설치하면 위치가 변경될 일이 극히 드무니까.
또한, GPS는 3D fix가 제대로 되지 않는 경우가 많고(위치 오차가 현저하고), 스마트폰에는 기압고도계 등의 정밀 고도계가 달려 있을리 만무하므로 현 경위도로부터 정확한 고도 정보를 알아내기 위한 DEM 파일이 필요. 한반도, 10mx10m 짜리 .bt 포맷 파일의 경우 약 870MB가 필요한데(작년에 필요해서 만들어봤다), 이런 걸 스마트폰에 넣고 다닐 사람들이 있을까? 웹으로 query 하려면 일정 시간 마다 측점 리스트를 보내 해당 경위도의 고도를 얻어와서 부하를 줄이던가 하는 방법을 사용. 풍향/풍속과 고도를 통해 알 수 있는 두 측점간 도로의 기울기는 속도와 중력의 영향이라는 자전거 라이딩을 무척 힘들게 하는 두 팩터를 알아내기 위해 반드시 필요한 정보.

칼로리 계산: 다음을 반복.

n-1번째 GPS 측점을 얻음 -> P
n번째 GPS 측점을 얻음 -> Pn
P, Pn의 고도를 DEM으로 결정
P, Pn으로 S (slope) 계산. S가 0보다 작으면 칼로리 계산에서 제외(?)
P 지점에서 가장 가까운 weather staion 2개로부터 시간을 감안해 풍향 벡터를 보간해서 구하고 풍속 역시 얻어온다.
P, Pn으로 벡터 구성하고 풍향 벡터와 풍속을 감안해 속력 계산 -> V
P의 고도 및 온도, weather station의 기압 등의 정보로 공기밀도 계산 -> D
칼로리 계산 -> F

안드로이드용 프로그램을 짜볼까 하다가, 일단, 돈이 안 되고, 하는 일이 바빠서 미뤘다. 게다가 누가 그나마(?) 정확한 칼로리 계산에 관심이 있을까, 의구심이 들었다.

칼로리 계산 보다는 실시간 고도 측정이나, 풍향/풍속 등 라이딩의 질(?)을 좌우 하는 요소들에 더 관심이 있을 것 같다. 이를테면 어떤 경로의 업힐, 다운힐 구간을 미리 알아내거나, 트랙 정보를 바탕으로 업/다운 고도 합계를 구하고 풍향/풍속 정보를 바탕으로 라이딩의 난이도를 자동으로 결정해 보여주는, 무척 실용적인 용도로 말이다.

그냥, 무의미한 수치를 출력하는 여러 프로그램에 심술이 나서 부리는 오덕질이다.

랜스 암스트롱을 대상으로 수행한 연구 활동으로부터 Edword F. Coyle은 몇 가지 주목할만한 발견을 했다. 코일 박사의 얘기 중 요점을 정리하면:

장기간 주행에서 탄수화물의 섭취는 근피로를 지연시킨다. --> 라이딩 중 가끔 에너지바를 섭취하면 덜 피곤하다.
주행중 탈수는 심혈관 장애를 일으키며, 피부 혈류 흐름을 감소시킴으로써 심각한 고열을 유발한다. --> 한여름에 바보같이 이 지경이 되도록 주행하고 뻗고는 했다. 낙타도 아닌데 꼭 물을 마시자.
소위, 피빨기는 라이딩의 고통을 무려 1/3이나 줄여준다. --> 코일 박사의 발견은 아니지만 중요해서 적었다. 비슷한 속도로 달리는 자전거 뒤에 붙어 피빨기를 하면 아주 편하다는 상식이다.

참고 사이트

http://www.mayq.com/Best_european_trips/Cycling_speed_math.htm

http://www.analyticcycling.com/ForcesPower_Page.html

http://www.cptips.com/energy.htm

KOTM v3.5

GPS 2010. 8. 18. 22:10

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

올초에 OSM 사이트에서 massive upload top 10에 뽑혔다(아마 3위던가?) . 덕택에 POI의 소재, 특히 저작권 문제를 지적하는 사람들이 생겼고(적절한 지적이다) OSM에 업로드한 POI를 전면 재개정하기로 약속했다. 4월 쯤에 시간나는 대로 올리겠다고 뉴스그룹에 공지했다가 (POI 정리가 어느 정도 끝나서) 그동안 바빠서 작업이 정체되었다.

이러저러한 귀찮은 작업을 거쳐 POI를 정리하고(근접 지역의 같은 이름과 같은 tag를 가진 POI를 합쳐주거나 태그가 없는 POI를 제거하는 등) 상당히 많은 양의 자료를 추가, 삭제, 수정하는 작업을 남겨 놓은 상태였다.

어차피 취미 생활인데 목숨 걸고 할 것도 아니라서 대충 시간을 흘려보냈더니, 어느새 6개월이 흘렀고, 지금은 만사가 귀찮아져(POI 검증이 무지 신경 쓰이고 시간을 잡아먹는 일이면서 소득이라고는 잘해봤자 본전이라) 그보다는 늦기 전에 그냥 손쉽게 해치울 수 있는 KOTM 새 버전이나 만들기로 했다. 사실 4월 이후부터 주욱 KOTM v3.5를 사용하고 있지만 남들에게 공개할 수준이 아닌데다, 설치 방법이나 설치 중 오류에 관해, 배포 전에 여러 종류의 각기 다른 시스템에서 무수한 테스트를 거쳐야 하는 등, POI 작업처럼 검증이 필요해 미루던 것이다.

테스트: 삼성 M4650과 노키아 N5800의 각기 다른 os에서 작동하는 Garmin Mobile XT 두 버전, 버전이 다른 두 종류의 MapSource, XP SP3, Windows 2008, Windows 7 등의 요새 많이들 사용하는 os , Garmin Vista HCx 등등 여러 조건에서 설치를 다양하게 해봤다. 그래도 안 되요, 에러 나요, 다운 되요 등등 별별 일이 다 생길 것이다.

일단 설치본에서 배포본만 남기고 제작본은 제거했다. 제작본 제작 방법에 관해 문의해 오는 사람도 없을 뿐더러 사람들이 제작에는 관심이 없어 보였다.

인스톨러는 WinRAR 대신 Nullsoft NSIS를 사용했다. NSIS 사용법을 배우고 비교적 쉽게 만들었다.

transparent 문제 때문에 GMAPSUPP.IMG를 만들 때 영문, 한글 TYP 파일을 각기 다른 것을 사용했다.

OSM 외에 별도로 수집한 12만개의 POI를 거르고 걸러 만들어 놓은 59000개의 비교적 오류가 없는 POI 리스트를 포함했다.

OSM의 bus_stop과 hospital tag는 4월 무렵 대부분 정리가 끝났다.

OSM의 orphan node와 name tag를 며칠에 걸쳐 여러 차례 개정했다. 지난 수 개월 동안 한국 지도는 장족의 발전을 거듭했다.

mkgmap r1667 버전으로 업그레이드 했다. style이 많이 바뀌었고 그에 따른 불가피한 수정을 하고 TYP 파일도 여러 차례 손보았다.

드디어 routable map을 만들었다. 하지만 내비게이션 테스트 결과는 처참했다. OSM의 도로 연결이 아직 제대로 안 되어 있는 탓이 크다. 하지만 라우터블 맵을 만들어봤자 뭘하나? 여전히 POI의 한글 검색이 안 되는데.

Topo Map은 DEM 파일을 추출하는 방식을 개선하고 세선화 단계를 줄였다. 등고선의 정밀도는 향상되었지만 등고선 데이터 크기가 엄청나게 커져서 등고선을 줄이느라 등고선 사이의 간격이 일정치 않았다. 용량 때문에 어쩔 수 없다. GPSr에서 랜더링하는 속도 부터 저장공간을 차지하는 문제까지, 가능한 맵 크기를 줄이기 위해 노력했다.

이렇게 해서 지난 4월 이후 별 진전없이 찔끔찔끔 진행되던 KOTM v3.5 제작을 약 일주일 동안 결론을 짓고 완결했다. KOTM v3.1이 작년 10월에 만든 것이니 v3.5는 사실상 10개월만에 업그레이드 되는 셈이다. 10개월 동안 꽤 많은 것들이 바뀌었지만 뭘 했는지 기억나는 게 별로 없어 작업노트라고 적을 만한 것이 없다.

8월 15일 광복절 기념판으로 만들려고 했으나, 공교롭게 주말에 가족여행이 있어 하루 늦게 설치본 제작과 테스트를 끝마쳤다.

소개 문서를 영문으로 작성하고 유명 사이트에 한국 지도라고 올려놓을까 하다가, 지도 설치와 운용 에 관한 귀찮은 문의를 '국제적으로' 받을 것 같아 관뒀다.

놀고있던 M4650에 KOTMv3.5를 설치했다. Nokia N5800을 Bluetooth GPS로 만들어주는 ExtGPS 프로그램을 사용해서 M4650으로 N5800에 연결하면 M4650의 Garmin Mobile XT에서 사용이 가능한데, 사실 Mappy를 사용하는게 더 나을 듯.

KOTM v3.5 소개, 다운로드, 설치: http://cafe.daum.net/GPSGIS/BSrL/1572

KOTM 다음 버전은 3.6이 되던가 4.0이 되던가 아직 모르겠다. 아직 등고선이 만족스러운 수준은 아니다. 아쉽게도 dem이나 topo map 자료를 얻을 수 있는 방법이 없어 상대적 비교조차 해 본 적이 없다. OSM의 POI는 언젠가는 정리해야 한다. 마냥 미룰 수도 없는 일이다.

OSM 한국 지도 제작자가 작년에 비해서 많이 늘긴 했지만 그렇다고 한국 지도 전반이 획기적으로 달라진 것은 없다. 주소체계 정비가 본격화되면서 사실상 도로명 대부분을 개정하는 작업이 진행되어야 한다.

그래도 그 사람들 덕에 무료 지도를 자유롭게 사용할 수 있는 것이다. 작업자들 만세!

5800 GPS 안테나 개조

GPS 2010. 6. 24. 14:18

노키아 N5800 GPS 성능 높여보자 -- 나도 안테나 개조나 할까 해서 5800을 뜯었다. 설명은 여기가 좀 더 자세하다. USIM과 MicroSD 슬롯이 있는 부근에 있는 GPS 패치 안테나에서 동선을 연장하는 것이다. 안테나로 사용할 선은 9.5cm 길이의 랜선(UTP 케이블)의 피복을 벗겨 준비했다.

파장 λ = C/f = 3*10^8 / 1575.42*10^6 = 0.19042m. (f=GPS 위성의 캐리어 주파수. C=광속)

안테나 길이 = λ / 2 = 0.0952m = 9.5cm

안테나를 붙이고(납땜하지 않고) 적당히 꺾어 휴대폰을 감싸게 했다. 요새는 사진을 죄다 노키아폰으로 찍는 관계로 휴대폰을 개조하는 과정의 사진은 없다.

효과: 사무실의 다른 직원이 가진 5800과 GPS 리셉션을 실내에서 비교해 보니 위성을 좀 더 잡는 것은 보였으나 그래도 Gamin Vista HCx와는 비교가 되지 않았다. 5800의 내장 GPS는 매우 구린 편.

2010-06-29 추가:

* 랜선의 피복을 벗겨 공기 중에 노출되면 쉽게 산화된다. 추후 니켈도금선으로 바꿔야 할 것 같다.

* Garmin Vista HCx와 5800 GPS를 함께 켜고 자전거 주행을 네 번 했다(자출 왕복 2회). 개활지에서 위성이 잡히는 갯수는 안테나 개조 전이나 개조 후 같으나(당연한 얘기지만 개활지에서 상공에 떠 있는 GPS 위성의 갯수는 정해져 있으니까) 수신 감도가 다소 향상되었으며 HCx 기준으로 위치 오차가 이전 +-15m에서 +-8m로 줄어들었다. 테스트할 때 5800은 주머니에 넣고 달렸으니 그 점을 감안하면 이전에 비해 좋아진 셈이다.

효과가 입증되어(?) 사무실 직원 휴대폰에 안테나를 달아주면서 내 5800으로 접사를 찍었다. 별나사를 네 개 풀고 껍데기를 살살 벗겨내고 패치 안테나 접점에 위 안테나를 걸쳐놓고 스카치 테이프로 붙여 고정한다. 작업 시간은 대략 10분 정도? 임피던스 맞추고 뭐고도 없는... 대충 접촉만 시킨다는 목적으로 한 것.

MicroSD, USIM을 지나 상단의 MicroUSB 포트를 지나도록 안테나를 구부려 설치. 이때 기판이나 금속 부분에 안테나 선이 닿지 않도록 주의. 내 경우에는 안테나 선을 휴대폰 하단으로 돌렸다. 휴대폰을 통상 주머니에 거꾸로 넣고 다니기 때문. 이 친구의 휴대폰은 안테나 선을 상단으로 둘렀는데, 휴대폰을 들고 구글맵 등을 실행해 길찾기를 할 때는 안테나가 위쪽에 있는게 낫다.

이제 필드 테스트(?) 결과:

클릭하면 커질 것 같은 그림. 조건: 한쪽이 건물과 담으로 막힌 안양천 자전거 도로변에서 평속 25kmh로 주행 중. 5800은 sportstracker2로 트랙로그를 남겼으며 로그 포인트의 총 갯수는 sportstracker가(1900여개) Garmin GPS(340여개) 대비 5배 이상 밀도가 높다.

5800-org: 안테나 개조 전. 한번 캡쳐. 주머니에 넣고 자전거 주행.

5800-mod1, 5800-mod2: 안테나 개조 후. mod1은 주머니에 넣고, mod2는 꺼내놓고 트랙로그를 남김.

hcx1, hcx2: 레퍼런스용 Garmin GPS Vista HCx. 두 번 모두 자전거 핸들바에 마운트해 놓고 트랙로그를 남김. Vista HCx로 남긴 트랙로그는 여러 번에 걸쳐 기록해도 위치 정밀도가 좋다. 그냥 이게 옳다고 보면 됨.

안테나 개조 전과 개조 후가 꽤 차이가 난다. 개조한 안테나는 최적의 조건에서(적어도 full strengh signal 위성 8개 이상 잡히는 개활지) HCx 대비 그렇게 나쁘지 않은 위치 정밀도를 보여주는 것만 같다. 뭐 사실 최적의 조건에서는 GPS 기기간 차이가 별로 나지 않는다.

골목길 및 고가 차로 아래 주행 궤적. 5800의 안테나를 개조해봤자 트랙로그가 몹시 흔들린다. 게다가 고가차로 아래에서는 위치정밀도가 HCx와 현저하게 차이난다. 무려 70-80m나... 자동차 내비게이션 용 정도로나 막 쓸 정도지, 산행에서 이런 GPS를 믿고 목숨을 맡기긴 무리다. 트랙로그 대충 남기고 위치 적당히 참고하는 정도로 사용할 수준.

오차가 크게 나는 것은 자전거가 주행하고 있기 때문인데, 걸어 다닐 때는 이렇게까지 오차가 커지지 않을 것이다.

2010-07-02 추가:

반파장 안테나가 수신 감도가 안 좋아 노키아폰 전체를 에두르는 안테나를 만들었더니 평소 집 안에서 0~1개 정도 잡히던 위성이 3-5개씩 잡히더라는 글을 보고 의아해서 안테나를 다시 만들었다. 공교롭게도 노키아폰 전체를 안테나로 두르면 1.5파장(반파장*3)이 된다. 보통 다이폴 안테나를 만들 때 반파장씩 둘을 만들던가 접지면에 대해 반파장 짜리를 만드는데, 반파장이 중요한 이유는 반파장일 때 공진폭이 최대가 되기 때문. 하여튼 1.5파장 안테나가 되니 위성이 1-2개 더 잡히고 수신강도도 '느낌상' 약간 상승한 것 같다(느낌 같은 거 사실 믿지 않지만).

그래서 그 상태로 테스트를 해 봤다. 이번에는 노상으로 운영되는 지하철을 타고 자리에 앉아 노키아폰과 Vista HCx를 동일한 위치에 들고 궤적을 작성했다. Garmin 지도의 도로와 철로를 기준으로 사용했다(도로, 철로의 궤도가 신뢰도가 높다고 보는 것은 무리지만 어디까지나 상대적인 레퍼런스로 사용).

노키아폰의 트랙로그의 포인트수가 HCx에 비해 5배 가량 많아 GPS Trackmaker의 Tracklog Reducer로 트랙을 줄였다.

HCx의 철로에 대한 궤적의 상대 오차는 +-20m로 전동차 실내에서 3-4개의 위성이 절반 정도의 감도로 잡히는 것 치고 위치 정밀도는 그럭저럭 괜찮았지만 5800은 종종 70~90m 가량 벌어졌다. 주욱 HCx와 궤적이 한 동안 잘 맞다가 저 모양이 된다.

오른쪽으로 얕으막한 동산을 끼고 직선로의 인도에서 걸으면서 두 GPSr을 나란히 들고 궤적을 작성한 것(클릭하면 확대) 좌측하단에는 하늘을 가리는 장애물이 거의 없다. 좌측하단에서 우측상단으로 걸어가는 동안 얕은 장애물(동산)이 나타나자 노키아폰의 위치정밀도가 낮아진다(흔들린다) 마지막에는 오른편에 아파트가 나타났고 노키아폰의 궤적은 70m 가량 도로와 어긋난다. 궤적 2개를 비교해 보니 1..5파장 안테나나 반파장 안테나나 수신감도 면에선 일단 별 차이가 없는 셈.

HCx가 항상 나은 것은 아니다. 지하철을 타고 가다가 내려서 탑승로를 걸어 지하철역을 나와 교차로에서 지하도롤 통과하는 과정. 전동차가 설 때까지는 5800의 위치 오차가 크지만, 지하도를 통과할 때는 HCx보다 오차가 작다.

이전 데이터에 1.5파장 안테나(5800-mod3)를 추가한 것. 반파장 안테나보다 상태가 안 좋다. 1.5파장 안테나가 위성을 많이 잡는 것은 착시현상인 듯. -- 위성은 돌고 돌므로 시점이 바뀌면 마치 위성 갯수가 늘거나 수신율이 좋아지는 것처럼 보일 수 있으므로.

(클릭하면 커짐)

짙은 파랑색: gps visualizer로 트랙로그에 대한 고도를 추출한 것. (gps visualizer는 SRTM3 DEM을 사용하여 고도를 추출하므로 고도가 정확하다고 볼 수는 없음)

빨강색: Garmin Vista HCx의 기압고도계가 기록한 고도. (기압고도계는 날씨나 기압에 따른 기압편차가 있어 정확한 고도를 얻을 수 없음. 그러나 DEM으로 추출한 고도와 트랜드가 일치하는 것을 확인할 수 있음)

하늘색: 5800의 GPS 고도 (한 눈에 봐도 개판)

2010-07-02 테스트 정리

* 5800의 GPSr은 무슨 이유에서인지 그냥 별로 안 좋다

* 5800의 안테나 개조(반파장)를 하면 수신감도가 좋아진다.

*5800 폰을 에두르는 1.5파장 안테나의 수신 감도가 반파장 안테나 개조 때보다 별로 나아지지 않거나 더 나빠지는 것 같다.
* 안테나 개조를해도 5800의 GPSr의 기본적인 위치 정밀도가 떨어지는 것은 어쩔 수 없다.

아이폰 3Gs을 만져본 적이 있는데 5800에서도 실행되는 Google Maps로 함께 살펴 보건대 GPSr의 수신 감도나 성능은 5800과 대동소이했던 것 같다. 안테나 개조 전이 그랬으니 안테나 개조한 5800이 어쩌면 더 나을 지도 모르겠다.

훗날 다른 GPSr로 필드 테스트를 더 해보기 위해 지금까지의 테스트 결과를 GPS Trackmaker 포맷 파일로 포함해 둔다.

invalid-file

지도 제작 작업 메모

GPS 2010. 2. 22. 16:24

사람들이 흔히 말하는 GPS의 정확한 명칭은 GPS receiver이고, 줄여서 GPSr로 표기하지만 이미 GPS로 용어가 굳어버려서 나도 GPS와 GPSr을 혼용하다 보니 헷갈린다.

lock된 맵을 unlock하는 것은 가능하지만, NT format 을 non-NT format으로 변환하는 것은 현재로선 불가능하다. NT format에 관한 정보는 Garmin사의 비밀로 남아 있다.

Garmin .IMG 파일에는 RGN, TRE, LBL subfile이 포함된다. routable map에는 NET와 NOD subfile이 들어있다. 최근의 MapSource 및 Basecamp에서 사용하는 3d Shaded releif 정보는 DEM 섹션에 들어간다. 2009년 12월 22일 현재 sourceforge의 Garmin IMG format 소스는 DEM을 제외한 나머지 항목들을 리버스 엔지니어링 했다. NT format과 마찬가지로 DEM format 역시 알려지지 않았다.

DEM 파일을 완전히 이용불가능한 것은 아니다. YoMismo는 이렇게 해결했다.

cgpsmapper의 설정 변수인 TreSize가 작을수록 GPSr의 랜더링 속도가 빨라진다. 대신 파일 사이즈는 커진다.

Topomap을 만들 때 globalmapper등의 프로그램에서 등고선을 단순화하는 알고리즘에서 사용하는 Simplify Level 값은 0.1과 1 사이에는 등고선 표현에 차이가 크나, 1과 10 사이에 차이는 거의 없다. 0.1일 때 파일 크기가 작지만 1일 때는 약 2배 이상 커진다.

http://gpsmid.sourceforge.net/ -- osm 벡터 파일을 직접 랜더링. 드디어 나왔다!

http://www.andnav.org/ -- Android Navigation. andnav1은 google 맵을 사용했지만 ver2 부터는 osm tile을 사용한다.

POI를 잔뜩 수집했다. 주로 산 이름인데, 여러 개가 겹치고 각기 조금씩 다른 경위도에 위치해 있는데다가 양이 많아 일괄적으로 수동으로 수정하기는 곤란했다. 예를 들어 태을봉에 해당하는 POI가 모두 7개인데, 정상 위치에서 벗어난 것이 3개, 정상 부근에서 경위도가 조금씩 틀어진 것이 4개로 정확히 정상 중심에 위치하는 것은 없다.

그래서 이중 정상 위치에서 너무 벗어난 것을 제외하고 남은 4개에서 정상 위치에 가장 근접하게 POI의 경위도를 조정하는 작업을 하기로 했다. 해당 경위도의 해발 고도를 알려면 DEM이 필요하다. 아쉽게도 이전에 사용하던 DEM 지도는 global mapper에서만 불러올 수 있고 대체 무슨 포맷인지 알 수 없다(게다가 약간 위치가 어긋났다), 두번째로 NASA가 제공하는 DEM 지도는 정밀도가 떨어져 정확한 정상 위치를 파악하는 용도보다는 고도 변화를 추적하는 정도의 용도로 사용 가능하다(몇몇 사이트나 프로그램이 이것을 사용해 딱 그 목적으로 사용했다).

KOTM에 사용하는 DEM을 MP로 변환한 다음, MP로부터 등위도 DEM을 다시 만들어 이것을 프로그램에서 사용가능한 TIFF나 비트맵으로 만든 다음 사용하려고 시도했다. 최소한 POI의 정상 위치는 이렇게 해서 판별이 가능했다. 하지만 DEM -> MP -> DEM으로 만드는 과정에서 MP가 10m 이하의 등위도 선분을 만들지 못하는 관계로 바다 위의 바위나 섬 주변의 낮은 봉우리는 처리할 수 없었다. 어쨌든 이 작업에 근 일주일을 보냈고 에러는 비교적 낮았다.

그동안 OSM에 올렸던 POI와 새로 수집한 POI를 합치면 약 20만개가 된다. 이들을 정리해서 다시 올릴 계획이다. 연초에 잠시 한가한 틈에 XML Pull Parser를 만들었고, OSM 파일(약 400MB)에서 POI만 추출하는 프로그램을 짰다. 요즘은 바빠서 통 이 작업을 하지 못했다.

정리:

DEM 작업 5일

POI 작업 5일

XPP 제작 및 POI 작업 14일

완결을 짓긴 해야 하는데 언제 다시 작업을 재개하게 될 지 불확실하다. 그 동안 정리되지 않은 POI를 사용해 맵 검증을 하고 돌아다녔다.

KOTM v3,1

GPS 2009. 10. 26. 23:46

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

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

업무 시간을 제외한 대부분의 가용 시간을 KOTM v3.1을 빌드하고 테스트하는데 보냈다. 10시간에 30번 가량 빌드 & 테스트를 해 볼 수 있다. 뭐 상당수는 MapSource에서 미리 확인하고 지도의 맵 피쳐가 잘 들어간 부분을 오려내어 테스트 스윗을 구성하고 일부분만 테스트해 보는 것이지만, 아이콘을 만들고 컬러 지정해서 TYP 파일 만들고 제대로 적용되었는지 확인하는 것은, 어떻게 생산적으로 잘 할 수 있는지 방법을 알아도, 작업의 절대시간을 단축할 수 없다는 점 때문에 생 노가다다.

그건 그렇고, 지도 제작을 좀 해봤거나 GIS 관련 계통 일을 하시는 분들이 보기엔 KOTM은 별 거 아닌 지도다. 자료의 규모나 품질 면에서 상용 지도에 비해 현저하게 질이 떨어진다.

KOTM v3.1은 저번 주 금요일 퇴근 전에 대충 마무리해 GPSGIS에 올렸다.

http://cafe.daum.net/GPSGIS/BSrL/1554

KOTMv3

GPS 2009. 10. 16. 18:15

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

mkgmap 개발자인 Steve에게 일단 email을 보냈다. 이 문제 때문에 지체되었고, 그 동안 바빠서 KOTMv3부터는 OSM 한국 지도를 다운 받아 사용자가 직접 지도를 만들 수 있도록 하겠다는 계획도 미뤘다.

오랫동안 기다리던 sea polygon이 mkgmap r1200 언저리의 리버전부터 포함되었다. 속도는 매우 느리지만 그래도 사용하고 싶다.

일부는 올해까지는 mkgmap에 GUI를 붙일 지도 모르겠다고 스티브가 말한 때문도 있었다. 그래서 내가 만들어 사용하는 osm2img를 굳이 공개하지 않아도 될 것 같다. mkgmap 프로그램의 옵션이 하도 많고 까다로워 GUI front end가 없으면 그 옵션들을 이해하면서 적절히 사용하여 지도를 제작할 사람이 몇이나 있을지 장담할 수 없다...

어느 리비전부터인지 정확히 기억은 안 나는데 multi-core cpu에서 threading을 지정할 수 있게 하는 옵션 덕택에 지도 제작은 30분에서 5분으로 단축되었다. 그래서 지도 만드는게 더 이상 부담스럽지가 않다.

여기저기 산을 돌아다니며 산 정상의 마루에서 GPS를 들고 제자리를 맴돌았다. 누가 보면 정신이 약간 이상한 사람처럼 보였을 지도 모르겠다. TM좌표계를 사용하는 DEM 원본 자료의 오차 때문이다. 최소한 세 군데의 최고점에서 삼각 측량을 하면 오차를 줄일 수 있으리라 여겼다. 그렇게 해서 DEM 지도의 수평 및 수직 정밀도를 KOTMv2.5 때보다 25m 가량 향상시켰다. globalmapper로 DEM의 전체 재작업을 진행 했다. globalmapper 새 버전은 지금 내가 사용하는 버전과 비교해 상당히 많이 좋아졌다. 언젠가는 사용하지 싶다.

자전거 타고 수원 시가지를 돌아서 수원 도로를 반쯤은 완성했지 싶다. 시간 나는대로 계속 진행할 것이다. 예전에 비하면 OSM 작업자가 늘어 기쁘기도 하다.

휴대폰에 Garmin Mobile XT를 설치하고 KOTMv3를 넣으니 Garmin GPS로 보던 지도가 똑같이 나타난다(오히려 WM 기기에서 돌리니 더 느려 보이는데?). Bluetooth GPS만 있으면 지금 휴대폰으로 나돌아다니는데 아무 문제 없을 것 같다.

KOTM 소개

=========

KOTM은 Garmin GPS용 자료로 Korea OSM & Topo Map의 약어입니다. 여러 사람들이 업데이트하고 있는 공개 지도 자료와 인터넷에서 구한 각종 자료를 취합해 만든 지도입니다.

2008년 10월 초 외국인들이 볼 수 있는 한국 지도를 만들어 보자는 취지에서 개인적으로 OSM 프로젝트를 시작하게 되었고, 그렇게 만든 지도를 Garmin GPS에 넣어 개인적으로 사용하다가 이왕이면 다른 사람들도 사용할 수 있게 해보자 하는 취지에서 KOTM 패키지를 만들게 되었습니다.

부탁드리건대, OSM에 많이 참여해 주십시오. OSM은 단순히 Garmin GPS에서만 사용할 수 있는 지도가 아니라, 그야말로 무궁무진한 응용이 가능한 무료 지도 만들기 프로젝트입니다.

KOTM의 원본 자료인 OSM 맵을 확인하려면 이곳에 들어가 보세요:

http://www.openstreetmap.org/?lat=37.125&lon=127.755&zoom=9&layers=B000FTF

이전 버전과 달라진 점

=====================

제작본이 별도로 있습니다. KOTMv3 이후 업그레이 계획이 아직 없습니다. 사용자가 직접 원본 데이터를 가공할 수 있게 되면 더 이상 설치본을 만들 필요가 없어 보입니다. 그보다는 OSM에 어떻게 기여해서 많은 분들이 지도의 품질을 높이는데 기여할 수 있는가 그것을 서포트해주는 것이 나을 것 같아 보입니다 :)

KOTM v2.5의 OSM 데이타 소스는 370MB 인데, 375MB로 용량이 늘었습니다. 생성된 지도 파일의 크기는 조금 줄었습니다.

KOTM v3는 등고선 지도는 좀 더 부드러워졌으며, 정밀도가 KOTMv2.5에 비해 25m 정도 향상되었습니다. 향상되었다기보다는, 이전에 그만큼의 오차를 가지고 있던 것을 개선했습니다.

Garmin GPS 뿐만 아니라 Garmin Mobile XT에서 정상적으로 지도가 표시되는 것을 확인했습니다.

각종 map feature가 이전 버전보다 나아졌습니다. 눈에 띄게 차이나지는 않습니다.

다운로드

=======

다음 bigmail로 1주일 동안 100회까지 다운로드 가능합니다.

설치본: KOTMv3.exe

제작본: KOTMv3p.exe

저작권

======

이 프로그램에 저작권은 없습니다.

자유롭게 배포하고 사용하세요.

설치에 앞서

===========

설치본의 파일 크기는 460MB, 압축을 푼 크기는 506MB 입니다.

제작본의 파일 크기는 328MB, 압축을 푼 크기는 1.33GB 입니다.

압축을 푼 크기를 감안하여 HDD에 충분한 용량이 남아 있는지 확인하세요.

설치본의 설치

=============

KOTMv3.exe를 실행하여 설치합니다.

이때 첫 화면에 나타나는 설치 디렉토리는 C:/Garmin/KOTMv2.5로 다른 디렉토리로 변경하게 되면 압축이 풀린 해당 디렉토리의 Korea*.reg 파일에서 해당 디렉토리를 적절히 바꿔줘야 합니다.

만일 설치 디렉토리가 다르다면 KOTM v2.5.reg 파일을 열어 LOC, BMAP, TDB의 디렉토리 위치를 텍스트 에디터로 변경하고 KOTM v2.5.reg를 더블클릭하여 설치합니다.

설치가 끝나면 registry를 등록하겠다는 메시지가 나타납니다. Ok를 클릭하면 설치가 완료됩니다.

Garmin GPS에 지도를 설치하려면:

* gmapsupp-eng.img는 영문 GPS용, gmapsupp-kor.img는 한글 GPS용 입니다. 이중 원하는 파일을 gmapsupp.img로 변경합니다.

* gmapsupp.img 파일을 GPS에 직접 복사: GPS를 USB Storage 모드로 변경한 후 (Garmin Vista HCx의 경우 Setup->Interface) 이동식 디스크의 Garmin 디렉토리에 GMAPSUPP.IMG 파일을 복사

* GPS에서 SD 카드를 꺼내 PC에 연결하여 직접 복사.

* sendmap.exe로 3*.img 파일을 로드한 후 GPS가 연결된 상태에서 전송.

설치가 끝나면 GPS에서 지형도와 도로를 확인합니다.

제작본의 설치

=============

제작본은 설치본 이후에 OSM 지도를 업데이트할 필요가 있을 때 설치하세요. OSM 한국 지도는 꾸준히 업데이트 되고 있으나 현재는 1개월에 1-2MB 정도가 늘어나는 수준입니다. 제작본으로 지도를 만드는 과정은 대략 1-2시간 가량 걸립니다.

KOTMv3p.exe를 실행하여 파일을 c:/garmin/KOTMv3에 넣습니다. 설치본과 중복되는 파일은 덮어 쓰면 됩니다. KOTM v3를 만들기 위해 필요한 프로그램과 데이터는 다음과 같습니다(이들은 압축된 파일에 모두 포함되어 있습니다).

제작에 필요한 프로그램

======================

* mkgmap -- java 프로그램으로 *.mp, *.img, *.osm 등의 파일로부터 *.img 파일을 생성.

* Java Runtime -- mkgmap을 실행하기 위한 런타임.

* wget -- 웹에서 OSM data를 다운로드 받을 때 사용하는 프로그램. 브라우저로 직접해도 되나 이 쪽이 편리.

제작에 필요한 데이타

====================

* 등고선 파일들 (mp\r*.mp)

* 해안선 파일 (33000000.img)

* 남한 OSM 자료 (sk*.osm)

압축파일에는 Java runtime이 포함되어 있지 않습니다. 2009-10-16일 기준 자바 런타임의 최신 버전은 Java 6 Update 16이고 http://www.sun.com 에서 다운로드하여 설치합니다.

남한 OSM 자료(sk*.osm)는 최신 버전이 필요할 경우 OSM 서버로부터 다시 다운로드할 수 있습니다.

osmkoreadown.bat를 클릭하여 실행하면 sk1.osm, sk2.osm이란 파일을 다운받습니다. 도스창이 두 개 나타나서 진행상황이 표시될 것입니다. 다운에 걸리는 시간은 OSM 서버 상태에 따라 유동적입니다. 길면 1시간 가량 걸립니다.

주의: 다운로드를 중간에 중단하면 그 다음부터 일정 시간 동안은 다운로드가 되지 않습니다. OSM XAPI Server의 트래픽 로드가 상당해서 그것을 제한할 목적으로 같은 좌표의 데이터를 다시 받을 때는 시간 제한을 두어 금지한 것입니다.

KOTMv3 생성

===========

mkgmap.bat는 MapSource 및 Garmin GPS용 지도를 만드는 배치 파일입니다. mkgmap.bat는 mkgmap.jar 프로그램을 실행합니다. 주의: 메모리가 1GB 이하일 경우 프로그램이 제대로 실행되지 않을 수 있습니다.

mkgmap.bat는 두 번에 걸쳐 mkgmap.jar를 실행합니다. 처음에는 영문용 자료를 만들고, 그 다음에는 한글용 자료를 만듭니다.

2개의 지도를 만드는 작업은 AMD Athlon II X2 240 (2.8Ghz), 2GB 메모리에서 619secs, 즉 약 10분 정도 걸렸습니다.

생성된 파일은 mapsource용 데이터, gmapsupp-eng.img, gmapsupp-kor.img 입니다. 생성이 끝난 다음 KOTM v3.reg 파일을 더블 클릭하면 mapset이 MapSource로 등록됩니다. 처음 설치 후 한 번 등록하면 다시 등록할 필요는 없습니다. 또, 이미 설치본이 설치되어 있다면 등록을 하지 않아도 됩니다.

이렇게 만든 지도의 사용법은 설치본과 같습니다.

기타

====

mkgmap r1177 이후 버전에서는 등고선(*.mp) 파일이 제대로 변환되지 않습니다.

mkgmap의 최근 버전은 r00 (해안선).mp 파일이 없어도 sea polygon을 만들 수 있는 옵션이 추가되었으나, sea polygon을 만드는 옵션을 켠 상태로 돌리면 gmapsupp.img 만드는 속도가 현저하게 느려지므로 그 옵션을 사용하지 않습니다. 따라서 해안선 폴리곤을 일부러 만들어 준 것이 33000000.img 파일입니다. 33000000.img 파일은 mp\r00 (해안선).mp를 cGPSMapper로 변환한 것입니다.

첫번째 버그는 mkgmap 제작자에게 리포트했으니 조만간 개선된 버전이 나올 것이고, 두번째는 첫번째 버그가 해소된 다음, 시간이 아무래도 상관없다면 mkgmap.bat 파일을 수정하여 33000000.img을 사용하지 않게 하고, --generate-sea 옵션을 추가하면 됩니다.

win32와 마찬가지로 맵의 제작은 linux에서도 가능합니다. 오히려 리눅스 쪽이 작업이 수월한 편입니다. wget은 보통 리눅스에 포함되어 있으므로 osmkoreadown.bat 파일을 참조하여 실행하면 되고, linux에 JRE를 설치하면 mkgmap.bat 파일을 참조하여 쉘 스크립트를 작성할 수 있습니다. 리눅스에서는 이들 작업을 자동화해서 web을 통해 서비스하기가 수월합니다. 예를 들면 gmapsupp.img파일을 cron job으로 걸어두어 1주일에 한 번씩 업데이트하게 하고 웹에 올려두고 다운로드 링크를 걸어두는 것 등등.

mkgmap-r1177/resources/styles/default 디렉토리에 있는 points, lines, polygons 파일의 level과 garmin icon type을 잘 조절하면 원하는 대로 지도에 나타나는 POI나 도로의 모양을 바꿀 수 있습니다. 또는 type file을 사용해 커스텀 icon을 사용할 수도 있고, 자전거 도로에 특화된 지도를 만든다던지 하는 용도로 사용할 수 있습니다. 자세한 내용은 OSM 홈페이지의 mkgmap 부분을 살펴보세요.

OSM 작업노트 #15: KOTM v2.5 공개

GPS 2009. 8. 7. 22:45

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월이면 프로젝트가 완료되고 따라서 이 작업노트 역시 종료된다.

OSM 작업노트 #14: cleanup

GPS 2009. 7. 24. 16:36

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개의 유명 산행로를 '그렸다'. 북한산 및 도봉산 트래킹 코스

OSM 작업노트 #13: 도로 업로드 작업

GPS 2009. 7. 9. 20:22

OSM의 전 세계 모든 데이터를 다 담고 있는 planet.osm 은 일주일에 한번씩 업데이트된다. planet.osm에서 한반도만 뜯어내려면 원래 그럴 용도로 만든 osmosis 프로그램을 사용한다. 2009.7.2 현재 planet.osm 파일의 크기는 무려 160GB, 압축한 파일의 크기가 6.2GB이다.

win32에서 osmosis를 실행하면 십중팔구 안 된다. 이유는 osmosis.bat 파일에 library path가 잘못 지정되어 있기 때문이다(linux에서는 상관없다). osmosis 0.31 버전 기준으로, osmosis가 설치된 디렉토리의 하위 디렉토리에 있는 ./lib/default/*.jar 를 EXEC 환경 변수에 모두 추가하여 osmosis.bat 파일을 만드는 편이 빠르다.

@ECHO OFF

set JAVACMD=java.exe
set JAVACMD_OPTIONS=-Xmx1024m
set MYAPP_HOME=D:\luke\Documents\private\gps\tool\osmosis-0.31
set LIB=%MYAPP_HOME%\lib\default
set MAINCLASS=org.openstreetmap.osmosis.core.Osmosis
SET EXEC=%JAVACMD% %JAVACMD_OPTIONS%
SET EXEC=%EXEC% -cp %MYAPP_HOME%\osmosis.jar;
SET EXEC=%EXEC%%LIB%\bzip2-20090327.jar;
SET EXEC=%EXEC%%LIB%\commons-logging-1.0.4.jar;
SET EXEC=%EXEC%%LIB%\jpf-1.5.jar;
SET EXEC=%EXEC%%LIB%\mysql-connector-java-5.1.6.jar;
SET EXEC=%EXEC%%LIB%\postgis-1.3.2.jar;
SET EXEC=%EXEC%%LIB%\postgresql-8.3-603.jdbc4.jar;
SET EXEC=%EXEC%%LIB%\stax2-api-3.0.1.jar;
SET EXEC=%EXEC%%LIB%\woodstox-core-lgpl-4.0.3.jar
SET EXEC=%EXEC% %MAINCLASS% %OSMOSIS_OPTIONS% %*
%EXEC%

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

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

osmosis의 bzip2 라이브러리의 버그 때문에 실행 하면 몇 시간 잘 돌다가 exception이 발생하며 프로그램이 중단된다. 오래 전부터 알려진 문제란다. win32용 bzip을 얻어서, 실행파일인 bzip-xxx.exe 파일을 bzcat.exe로 복사해 놓고 다음처럼 실행한다(리눅스에는 bzcat이 기본적으로 설치되어 있다).

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

osmosis의 입력 파라메터로 지정하는 bounding-polygon 파일 'skorea.poly.txt'는 osmosis 위키 페이지에서 참고하라는 각 국가별 polygon 파일을 봤는데, 좀 괴상하다. 남북한 국경선도 명확하지 않고 울릉도, 독도 등이 빠져 있다. 해서 확실한 국경선은 아니지만, 하나 만들었다. skorea.poly.txt:

south_korea

1

124.50082 33.88033

126.84860 32.67590

128.86031 34.19477

130.32874 35.89549

132.62271 37.16911

128.90661 38.93043

124.46191 37.55735

124.50082 33.88033

END

END

이걸 어떻게 만들었냐 하면... 궁즉통, Google Earth에서 대충 한국을 포함하는 polygon을 그린 다음 그것을 kml로 저장해서 좌표를 텍스트 에디터로 옮겨 적었다. 남한의 국경선 폴리곤이 혹시 있지 않을까 싶지만 구글질해서 성과(?)를 얻는 것보다 직접 아웃라인을 따내는 시간이 훨씬 적게 걸린다. -_-

osmosis로 160GB짜리 파일을 처리하는데 얼마나 많은 시간이 걸리는지 모르겠다. 밤에 작업을 걸어두고 잤다. 2시간 40분쯤 돌다가 exception이 발생하며 bzip2 라이브러리 문제로 프로그램이 죽어버렸다. 파일이 깨진 것 같아 다른 서버에서 다운로드 받아 다시 돌렸다. 3시간 정도 걸려 skorea.osm 파일을 얻을 수 있었다.

skorea.osm 파일을 얻은 다음, 일단 잘못된 저수지 정보를 모두 삭제했다. 삭제는 bulk_upload.py를 수정해서 만든 조그만 python 프로그램으로 돌렸다. osmChange를 이용해 한꺼번에 여러 개의 node,way에 대한 작업을 수행하는 것인데, changeset중 단 하나라도 entry에 문제가 있으면 업데이트가 되지 않는다. 그 때는 changeset을 새로 만드는 방법 밖에 없다. JOSM도 동일한 문제가 있다. 예를 들어 하나의 changeset에 100개의 노드를 삭제하는 delete element가 있다고 하면,

<osmChange>
   <delete>
   <node id="34132450" ... />
   <node id="34132452" .../>
   ...
   </delete>
</osmChange>

34132452번째 노드를 삭제할 때 에러가 발생하면 100개의 노드에 대한 delete 작업 전체가 수행되지 않는다. OSM에서 프로그래밍을 하는 사람들이라면 반드시 알아야 할 내용인데 OSM development 섹션에서는 언급이 안되어 있어 메모해 둔다:

Error: 409 : Version mismatch: Provided 0, server had: 1 of Way 36898268

삭제하려는 node의 버전은 1이고 서버의 해당 노드의 버전은 2이면 삭제되지 않는다. 삭제하려는 노드를 누군가 다른 사람이 작업해서 버전 번호가 달라진 것이다.

Error: 410 : The way with the id 35355795 has already been deleted

이미 삭제된 노드로, 이 경우에는 에러로 간주되지 않았으면 좋겠는데 이런 에러 때문에 전체 changeset이 commit되지 않는다.

Error: 412 : Precondition failed: Node 414576118 is still used by way 36898266

삭제하려는 node를 사용하는 다른 way가 있을 경우 발생하는 에러. 이게 가장 골치아프다. 왜냐하면 삭제하려는 node가 만약 어떤 way에 소속되어 있는데, 이미 그 way가 삭제되었다 하더라도 다른 way에서 이 node를 사용하고 있다면 이 node를 삭제하면 안 되는 것은 맞다. 그런데 해당 node가 어떤 way에 속해있는지 사전에 알 방법이 애매하다. 전 node, way, relation을 메모리에 갖고 있던가 그 정보를 db에 넣어 해당 node가 다른 way에서 점유하고 있는지 조사해 봐야 하는데, 삭제하려는 node가 300000 이고 한 node 조사에 100msec이 걸린다면 삭제대상 노드 조사에만 30000초(약 500분)이 걸린다.

osmChange를 사용하지 않고, changeset을 만든 다음 http DELETE로 삭제하는 고전적인 방법을 사용할 수도 있다. 이 방법을 사용하면 한 node에서 발생한 에러가 다른 node의 삭제에 영향을 끼치지 않는다. 그런데 그 방법은 시간이 오래 걸려 비효율적이다. 개당 500msec이 걸린다면 300000개를 삭제하는데 41시간이 걸린다.

그래서 python 프로그램은 먼저 한 번에 111개를 한 세트로 하는 changeset을 사용해 11개 element를 삭제하고, 삭제가 정상적으로 이루어진 element의 id를 기록해 둔 다음, 다음번에 python 프로그램을 다시 실행해 이번에는 53개씩 삭제, 다음에는 23개, 그 다음에는 11개, 5개, 3개, 2개, 그리고 마지막으로 http DELETE로 1개씩 삭제한다. 갯수는 100, 50, 25, 13, 6, 3, 2, 1에 근접한 소수를 사용해서 이전 changeset이 다음 changeset의 배수가 되어 같은 에러가 동일한 위치에서 발생하지 않도록 한 것.

손이 많이 가지만 이전에 잘못 올린 저수지및 호수 데이터 160000개를 삭제하는데 4시간 가량 걸렸다. 사실 작업시간 보다는 changeset의 특성을 파악하고 적응하는데, 특히, 412 에러를 회피하려고 갖은 꽁수를 써 보는데 시간이 많이 걸렸다. 처음에는 c++로 작업하다가 python 프로그램이 워낙 간단하고 편해서 python으로 바꿨다.

smoothing이 적용된 저수지및 호수 데이터(ncat=저수지및호수2)를 저번 주 금요일 저녁에 올리기 시작했다. 월요일에 정상적으로 올라간 것을 확인했다.

교통정보센터의 수정된 도로를 올리기 전에, 이전에 내 아이디로 만든 highway, trunk, primary, secondary 도로를 삭제하기로 했다. 진행 전에 한국 OSM 작업자들에게 도로 업로드 작업을 이번 주 중에 진행한다는 메시지를 작성하여 전송했다. 욕도 일찍 먹는게 낫다고, 이번에 도로 데이터를 올리지 못하면 일이 점점 더 커질 것이다. 한 두어 달을 올릴지 말지 망설이며(서울, 부산, 대전, 안동이 그 당시에 작업이 꽤 진척된 상태였다. 그 작업을 다시 해야 하니까 작업자들에게 미안해서 어떻게 하면 작업양을 최소화하면서 도로 업로드의 당위성을 설명할까 망설였다) 한가한 고민이나 하던 사이에 홍의님이 전주시와 인근 도로 작업을 상당히 진척시켰다.

도로는 월, 화요일에 모두 삭제했다. 올리려고 하는 도로 데이터의 검토 역시 대충 마무리 되었다. 고속도로는 양방향 lane을 그대로 유지하기로 했다. 수요일 OSM 서버의 업데이트가 있기 전 고속도로를 먼저 올려 JOSM과 Potlatch로 상태를 확인했다. 고속도로만 올리는데 3시간 가량 걸렸다. XAPI가 맛이 가는 바람에 조금이라도 일이 틀어지면 다음에 그것을 교정할 기회는 1주일 후에나 주어진다. 특히나 대량의 업로드의 경우는 문제가 심각하다. 조심조심 작업해야겠다.

화요일 밤부터 국도를 올리기 시작했고 수요일에는 도심로와 지방도 업로드를 시작했다. 다 합쳐 20시간 가량 걸렸다. 프로그램이 수고가 많다. 이전의 bulk_upload.py를 좀 더 개선한 소스. bu.py:

[code] #!/usr/bin/python # -*- coding: utf-8 -*- import time import socket import xml.etree.cElementTree as ET import sets import optparse import pickle import os import sys import httplib2 import re socket.setdefaulttimeout(300.0) headers = { 'User-Agent' : 'BatchUploader/0.1', } api_host='http://api.openstreetmap.org/api/0.6' userid = "#####" passwd = "#####" cachefn = "" demo = False idMap = {} testid = '1' class UploadFailed(Exception): pass class ImportProcessor: def __init__(self): self.user = userid self.password = passwd self.e = ET.Element("create") createReq = ET.Element('osm',version="0.6") change = ET.Element('changeset') createReq.append(change) if demo: self.cid = '1' print 'Create changeset ', self.cid return resp, content = self.request(api_host + '/changeset/create','PUT', ET.tostring(createReq)) if resp.status != 200: print 'Error Request changeset ', resp.status, ': ', content raise UploadFailed(resp.status, content) self.cid = content print 'Create changeset ', content def request(self, url, cmd, xml): con = httplib2.Http() con.add_credentials(userid, passwd) fc = 0; failed = True while failed: try: resp, content = con.request(url, cmd, xml, headers=headers) return resp, content except socket.error, msg: fc += 1 if fc > 5: raise print 'Request Error:', msg time.sleep(2) def add(self, item): item.attrib['changeset'] = self.cid self.e.append(item) def upload(self): xml = ET.Element('osmChange') xml.append(self.e) if demo: return 1 resp, content = self.request(api_host + '/changeset/' + self.cid + '/upload', 'POST', ET.tostring(xml)) if resp.status == 200: # print "Return:", content er = ET.fromstring(content) for child in er.getchildren(): old_id = child.attrib['old_id'] new_id = child.attrib['new_id'] idMap[old_id] = new_id return 1 # 그외의 에러 print 'Error: ', resp.status, ':', content return 0 def closeSet(self): if demo: print "Closing changeset", self.cid, '\n' return resp, content = self.request(api_host + '/changeset/' + self.cid + '/close', 'PUT', "") if resp.status != 200: print "Error closing changeset", self.cid, ":", resp.status def doJob(osmData, etypes, csize): cnt = 0 ip = None for e in osmData.getiterator(): if e.tag not in ( etypes ): continue # 이미 기록한 것은 다시 하지 않음 eid = e.attrib['id'] if eid in idMap: continue if ip == None: ip = ImportProcessor() # way 또는 relation이면 이전에 기록된 id로 기록함. if e.tag == 'way' or e.tag == 'relation': for child in e.getiterator(): if child.attrib.has_key('ref'): old_id = child.attrib['ref'] if idMap.has_key(old_id): child.attrib['ref'] = idMap[old_id] print 'create [', ip.cid, ':', cnt, '] ', e.tag, eid ip.add(e) cnt += 1 if cnt >= csize: ip.upload() f = open(cachefn, "w") pickle.dump(idMap, f) f.close() ip.closeSet() ip = None cnt = 0 if cnt > 0: ip.upload() f = open(cachefn, "w") pickle.dump(idMap, f) f.close() ip.closeSet() usage = "usage: %prog -i input.osm" parser = optparse.OptionParser(usage) parser.add_option("-i", dest="infile", default="", help="read data from input.osm") (options, args) = parser.parse_args() if options.infile == "": print "specify input osm file" raise cachefn = options.infile + ".db" try: if os.stat(cachefn): print 'Read from cache file:', cachefn f = open(cachefn, "r") idMap = pickle.load(f) f.close() except: print "no cache found" osmData = ET.parse(options.infile) st = time.time() doJob(osmData, ("node", "way", "relation" ), 500) print "\nJob done. %.0f" %(time.time() - st), "secs ellapsed" [/code]

OSM 서버의 느린 응답 때문에 에러가 빈번하게 발생하여 프로그램이 자주 멎는다. 프로그램 탓은 아니다. changeset이 완전히 반영되지 않으면 idMap에 기록하지 않도록 하고, 한 번에 commit하는 element의 갯수는 2000개나 5000개가 아닌 500개 정도로 제한해서, 시간이 더 걸리더라도 안정적으로 작동하는데 촛점을 맞췄다.

아울러, 저 것과 같은 기능을 하는 프로그램을 처음에는 VC++ 2005로 작성하려고 했지만 c++로는 작업량이 상당했다. 무엇보다도 expat SAX xml parser 때문에 로직을 짜기가 어렵다. c++에서도 python처럼 쉽게 작성 하려면 XPP(xml pull parser) + DOM을 사용하는게 마땅하다. python 프로그램은 한 시간도 안 걸리는 것을, 그것과 등가한 VC 프로그램을 작성하려면 1-2일쯤 걸릴 것 같다.

수요일 밤에 작업이 끝났다. 업로드에 15시간 정도 걸렸다. 작업 시간을 잘 맞춘 덕에 업로드된 내용이 그 다음날 바로 반영되었다.

서울 부근의 겹치고, 태그가 불분명하게 설정된 도로를 다시 정리하는 작업을 진행 중.

OSM에서 mapnik renderer로 본 지도. mapnik으로는 그간 무슨 삽질을 했는지 알 수가 없어서,

Osmarender로 렌더러를 바꿨다. 저 촘촘한 도로들이 지난 한 달 동안 작업한 것. 이것으로 한국 지도 작업을 진행하기 위한 기본 뼈대가 어느 정도 갖춰진 셈이다. 갈 길은 여전히 멀다...

OSM 작업노트 #12: 지도 공개 및 도로

GPS 2009. 6. 30. 16:41

도로 작업 후 파일 크기는 350MB에서 88MB로 극적으로 줄었다. 도트 픽셀이 보이는 해안선과 저수지 및 호수 데이터 역시 크기가 현저하게 줄었다. 하지만 이들을 조합해 Garmin용 이미지를 만들자 파일 크기는 10MB 가량 밖에 줄지 않았다. 용량이 크게 줄지는 않았지만 선의 복잡도가 줄어 GPS에서 지도를 출력하는 시간이 단축되긴 했다. 덕택에 TRE와 RGN 사이즈를 줄일 수 있었다.

저수지 및 호수 데이터를 작업하고 나서 이전의 bulk_upload.py로 예전 자료를 삭제하고 신규 자료를 업하려고 하다가... bulk_upload.py의 버그로 이전 자료가 두번 업로드되고 말았다. 파이썬 프로그램을 좀 더 자세히 살펴봤어야 하는데, 사후약방문이라고 나중에야 이상해서 소스를 보니 bulk_upload.py는 말그대로 업로드만 가능했다. 소스 중에는 delete와 modify도 되게끔 하는 부분이 있지만 제대로 작동하지 않을 뿐더러 순서가 잘못 되어 있었다.

즉시 지우려고 보니 OSM 서버 업그레이드 후 XAPI 서버가 맛이 간 상태라 한반도 데이터를 다운받을 수가 없다. 6월 13일 다운된 xapi 서버는 6월 29일까지도 복구되지 않았다. 천상 중복 업로드된 데이터를 교정하려면 매주 수요일 업데이트 되는 planet.osm을 다운받아 한반도만 뜯어내 잘못된 저수지 영역을 모두 선택하여 삭제하는 작업을 다시 해야 한다.

그렇게 하면 되는 작업이지만, 이제는 좀 짜증이 난다. API 0.6 업그레이드 후 뭐 하나 잘못되서 수정하려면 며칠씩 걸리고 API 0.6 자체의 엉성함 때문에(transaction도 아니고 그렇다고 transaction이 아닌 것도 아닌 아주 애매한 컨셉) 가외로 까먹는 시간이 상당하다. 0.6은 또 속도가 느려 잘못 업로드된 저수지및 호수(약 10MB) 자료의 절반을 데이터베이스에서 삭제하는데 27시간이 걸렸다. 그나마도 제대로 되면 좋겠는데, 제대로 되지도 않아 툭하면 서버가 다운되어 접속이 안되거나 영 바보스러운 응답을 늘어놓기 일쑤였다. 하여튼 0.6 API로 스트레스 받지 않고 OSM 배치 작업을 하는 사람들이 영 신기하기만 하다. 솔직히 뭐 이따구로 아마추어스럽게 설계했나 싶다.

아... 아마추어들이지 참.

그럴 때도 되었지 싶어 이번 주 월요일에는 그간의 OSM 지도와 도로 작업 데이터/해안선 따위등을 긁어모아 KOTMv2(Korea OSM & Topo Map version 2.0)을 만들었다. 이번에 만들어서 공개하면 세번째가 되는데, KOTM이란 이름을 사용하게 된 것은 두 번째 이고, 앞으로 그 이름으로 통일하려고 v2.0이 되었다. 이번에는 SFX에 설치하며서 registry 파일을 자동으로 등록해주는 간단한 인스톨러를 포함했다.

KOTMv2 소개

KOTM v2 소개
============

KOTM은 Garmin GPS용 자료로 Korea OSM & Topo Map의 약어입니다. 여러 사람들이 업데이트하고 있는 공개 지도 자료와 인터넷에서 구한 각종 자료를 취합해 트래킹 및 사이클링 때 내외국인이 두루 사용할 수 있도록 영문 Garmin용 지도로 만든 것입니다.

KOTM v1과 v2의 차이점
=====================

* 10m Topo Map . 수평 해상도가 9배 증가. 수직 해상도는 정확한 자료가 없어서 확실치 않습니다. 이 자료는 http://www.biz-gis.com 에서 얻은 DEM 2008년 버전을 참고한 것입니다. 다만 울릉도와 독도는 기존 KOTMv1과 마찬가지로 SRTM3 자료입니다.

* 한국교통정보센터의 표준노드링크 정보(http://nodelink.its.go.kr/)의 고속도/국도/지방도 노드 및 링크를 를 mp 파일로 가공한 http://club.paran.com/club/home.do?clubid=bikeadventure 에서 얻은 것을 재가공했습니다. 가공 방법에 관한 정보는 http://www.pyroshot.pe.kr/tt/entry/OSM-작업노트-11-도로 에서 확인하십시오.

* POI에 도로분기점과 행정구역(시군구읍면동) 약 35000개가 추가되어 총 POI는 10만여개로 늘었습니다. 아울러 저수지 및 호수 등 수계 데이터가 추가되었습니다.

지도의 정밀도
=============

topo 맵의 경우 중부기점 TM을 적용한 것으로 추측되며(이 때가 가장 오차가 적었습니다) 애당초 원본 자료에 프로젝션 정보가 포함되지 않아 전국의 임의 지점 5군데를 기준으로 지형도의 정밀도를 측정하고 일률적으로 보정했습니다. 보정이 필요했으며 그 보정이 확실하지 않다는 이유 때문에 수평 오차를 감안하고 사용해야 합니다. 지도란 때때로 생명을 담보로 하는 것이므로 지형도에서 발생한 오차를 감안하여 지형도는 어디까지나 참고 자료로써 사용하기를 바랍니다. 제가 측정한 것으로는 수평 방향 오차가 25m 정도 벌어질 수 있습니다. 고도는 어떤 방식을 사용했고 어느 정도의 오차를 가지는지 모르므로 언급하기 어렵지만 이전 KOTMv1에 비해 상당히 높은 수평 정밀도(이전 자료에 비해 9배)에 비추어 어느 정도의 수직 정밀도를 가지고 있다고 생각합니다.

국가교통정보센터의 표준노드링크 자료를 사용한 도로 데이터는 GPS를 이용한 실측에서 비교적 좋은 결과를 보여줬습니다.

다운로드
========

파일 크기가 약 250MB입니다.

Nate, Daum, Naver의 대용량 메일 다운로드 링크입니다. 7월 6일 ~ 7월 7일까지 다운로드 받을 수 있습니다.

http://gigafile.nate.com/download/sid=46&info=cdbcbf679eb5d2ff6026ec603814b3aa98b1ed8af0d87baca5e88e25bbbd18e8a7763dc16339ed86eabde5ea91418184a6d12e84e9d95fa030

http://bigmail28.mail.daum.net/Mail-bin/bigfile_down?uid=LlgkAiE96bcwWT3mQR_hdZ69Pa8pyjmn

http://bigfile.naver.com/bigfileupload/download?fid=0QFcbreZDBgwFwYwHX3TFo2jKogmaxgrKqgwKogmKqKjaAbXFriCK4MlMrMrFq0oMoI0axgrp4UXKxUdKxC0K4M=

Windows Live Skydrive에는 50MB 단위로 분할된 7개의 파일을 올려두었습니다. 다운로드 속도가 매우 느리며 한번에 1-2명의 사용자만 다운이 가능합니다. 기간 제한은 없습니다.

http://cid-c828054758ad855f.skydrive.live.com/browse.aspx/.Public/KOTMv2

설치
====

* KOTMv2.exe 또는 KOTMv2.part1.exe를 실행하여 설치합니다.
* 이때 첫 화면에 나타나는 설치 디렉토리는 C:/Garin/OSMMap10m로 다른 디렉토리로 변경하게 되면 압축이 풀린 해당 디렉토리의 Korea*.reg 파일에서 해당 디렉토리를 적절히 바꿔줘야 합니다.

* 만일 설치 디렉토리가 다르다면 Korea Topo 10m + OSM Map.reg 파일을 열어 LOC, BMAP, TDB의 디렉토리 위치를 텍스트 에디터로 변경하고 Korea Topo 10m + OSM Map.reg를 더블클릭하여 설치합니다.

* 설치가 끝나면 registry를 등록하겠다는 메시지가 나타납니다. Ok를 클릭하면 설치가 완료됩니다.

* Garmin GPS에 지도를 설치하려면

   * gmapsupp.img 파일을 GPS에 직접 복사
   GPS를 USB Storage 모드로 변경한 후 (Garmin Vista HCx의 경우 Setup->Interface)
   이동식 디스크의 Garmin 디렉토리에 GMAPSUPP.IMG 파일을 복사
   * sendmap.exe로 3*.img 파일을 로드한 후 GPS가 연결된 상태에서 전송.
   * GPS에서 지형도와 도로를 확인합니다.

다음 버전에는 제대로 된 인스톨러를 만들어야겠다. 사용자가 설치 디렉토리를 다른 곳으로 변경할 때 해당 디렉토리로 자동 변경하여 .reg 파일 없이 registry에 등록하고, Garmin GPS용 IMG와 MapSource용 이미지를 선택할 수 있도록. 아예 내친 김에 Sendmap.exe로 GPS에 자동 설치까지 가능하게? Winrar의 SFX가 이 정도면 훌륭한 편이라 vbs 스크립트 하나 추가하는 정도로 해도 될 듯 싶지만.

OSM의 비전: 아이팟 터치, 안드로이드, WM6 기계에서 오픈 스트릿 맵 타일을 다운받거나(wifi online) 벡터 데이터를 원본 그대로 가공하여 랜더링하는 엔진을 만들어(offline) GPS로 연동하면 그 이상의 활용이 있을까? 렌더러 소스가 공개되어 있으니 모바일 장치용 프로그래밍을 좀 하면 되는데, 뭐 이미 누군가가 하고 있으니 기다리다보면 나오지 싶다.

OSM 작업노트 #11: 도로

GPS 2009. 6. 24. 20:52

작년 10월부터 OSM 간보기를 하다가 올 3월초부터 OSM 작업을 시작했는데, 4개월만 더 있으면 OSM 작업하겠다고 생각한지 만 1년이 된다.

저번 주와 마찬가지로 이번 주에도 작업을 그리 많이 하지 못했다. 이번 주는 화요일, 수요일 합쳐 약 7시간 정도 작업. 이 기사 쓰는데 쓰는 시간이 더 걸리는 것 같다. 국가교통정보센터의 지도가 내년에 업데이트 되어도 그것을 손쉽게 업데이트할 방법을 찾다보니... 도로 작업에 너무 많은 시간을 까먹고 있다.

국가교통정보센터의 지도에서 추출한 도로로 다음 네 단계로 작업으로 나눴다. 라우팅은 미심쩍은 것들이 많아 이번 주 작업에서 뺐다.

1. 노이즈 제거

왼쪽: 원본 데이터, 오른쪽: 노이즈 제거 후

아마도 프로젝션에 따른 오차를 보정하다가(추측임) 위와 같은 노이즈가 원치않게 끼어든 것 같다. polygon 처리에 사용하던 이동평균 보간으로 노이즈를 없애버리면 유의미한 vertex도 날아가므로 노이즈의 성향을 살펴 연직 및 수평 이동이 발견될 때에만 제한적으로 보정 했다.

이런 노이즈의 '크기'는 대략 1-4m 정도. 2점/3점까지 수평/연직이 발견되면 한 점이나 두 점을 삭제하고 2점/3점의 평균 거리로 첫 번째 위치를 이동하여 보정했다.

2. 선로 합치기

국도 및 지방도는 고속도로처럼 뚜렷한 경계선에 의해 구분되지 않으므로 2개의 라인이 서로 다른 방향을 가진 벡터로 진행할 필요가 없다. 물론 국도나 지방도 중에서 4/8차선이 없는 것은 아니지만, 2개의 라인으로 표현되면 파일 크기가 커지고, 굳이 그렇게 도로 폭을 크게 묘사할 필요가 없다고 판단해 국도와 지방도의 선로를 합치기로 했다.

선로를 합치기 위한 조건은, 두 벡터의 시작점/끝점이 일정 거리 내에 인접해 있고 벡터의 방향만 반대일 때이다. 아울러 polyline의 이름과 타잎이 일치해야 한다.

시작점, 끝점은 경위도좌표로 나타나므로 두 좌표의 거리를 재어 파라미터로 정한 거리 안에 들어오면 인접했다고 판단할 수 있다. 평면 상의 두 점의 거리는 sqrt( (x2 - x1)^2 + (y2 - y1)^2 ). 물론 경위도로 표현되는 두 좌표는 구체인 지구 구면의 거리가 되어야 하므로 평면 거리는 쓸모없다. 구면 상의 두 점의 거리는 구면기하 삼각함수를 이용한 Haversine 공식을 사용해 계산:

d = acos(sin(lat1) * sin(lat2) + cos(lat1) * cos(lat2) * cos(lon2 - lon1)) * R
R(지구반지름) = 6371000m

자전 및 공전을 하는 지구가 완전한 구체는 아니라서(WGS-84 ellipsoid 모델에서 적도 반지름은 6378km, 극 반지름은 6357km) Haversine식은 0.3% 가량의 오차를 가진다(즉, 1km 거리에서 3m 가량의 오차). 오차를 줄이려면Vincenty 공식을 사용하면 되지만(오차가 무려 1mm), 좌표간 거리가 대단한 정밀도를 가질 필요가 없고 계산량도 많아 Haversine 공식을 사용하기로 했다. 지구면의 두 지점에 관한 여러 종류의 수식은 여기를 참조.

왼쪽: 작업 전, 오른쪽: 작업 후

국도 및 지방도에 좌표 거리를 25m 이내로 했다. 선로 합치기는 비교적 잘 되었다. 예상대로 파일 크기는 1/2로 줄었다.

3. 인접 차선 결합

국가교통정보센터의 도로는 대부분 잘게 토막나 있다. 이것들을 하나의 긴 도로로 묶어 놓는다. 선로 합치기와 마찬가지로 벡터의 시작점/끝점이 일정 거리 내에 인접해 있으면 합친다. 경우의 수는 네 가지다.

vector1: B1 ---->---->---->---- E1
vector2: B2 ---->---->---->---- E2

E1, B2 인접: vector2의 B2를 지우고(공통) vector2를 vector1뒤에 연결한 다음 vector2 삭제(공통)
B1, E2 인접: 위와 비슷
B1, B2 인접: vector2의 방향을 바꿔 vector1에 연결
E1, E2 인접: 위와 비슷.

왼쪽: 떨어져서 별개로 선택되는 도로들, 오른쪽: 연결된 도로

4. 벡터 평탄화

벡터가 완만하게 변화하는 구간에서만 평탄화를 실시한다. 평탄화를 하면 지점의 갯수가 줄어든다. 변화폭은 일정 갯수의 지점에서 벡터 방향(bearing)의 각도 변화의 총합을 측정하여 파라미터로 결정한다. 예: 10점 동안 각도 변화가 10도 미만이면 평탄화.

평탄화는 급격한 변화 구간(예를 들면 도로의 인터체인지의 원형 진입로)은 그대로 놔 두고 완만한 변화 구간을 압축하는 효과가 있어 파일 크기를 줄일 수 있다. 3점 각도 변화 15도에서 원래 데이터를 크게 손상시키지 않으며 그 크기를 대략 1/2로 줄였다.

잘 뒤져보면 위에 언급한 네 가지 작업에 적합한 좋은 알고리즘이 있을 법하지만, 굳이 속도나 효율을 요구하는게 아니라서 일단 이대로 프로그래밍하기로 했다.

네 가지 작업의 효과(또는 취약점)을 확인할 수 있도록 파라미터를 선택하여 처리할 수 있도록 GUI 프로그램을 짰다.

이전의 해안선 처리에 사용하던 프로그램과 통합하고, polygon 처리할 때도 smoothing을 넣으니까 vertex 수가 10% 가량 줄었다. 빙고.

프로그램을 돌려보니 출력 파일의 크기가 원본의 24~30% 정도 밖에 되지 않는다. 원래 계획했던, 350MB를 100MB 이내로 줄이는 것이 가능하다. 한동안은 한가하게 출력 파일을 검증하는 작업을 할 것이다. 더디긴 하지만 작업은 계획대로 진행되고 있다.

OSM 작업노트 #10: 해안선과 도로

GPS 2009. 6. 19. 13:45

OSM의 coastline은 PGS에서 자동 변환한 것으로, polygon이 아닌 polyline이라서 OSM 파일을 Garmin GPS용 .img로 변환하면 바다와 육지 경계만 표시될 뿐, 바다는 파랗고 육지는 육지색으로 표시되지 않는 문제가 있다. 여기에다가 transparent 옵션을 주고 .img 파일을 만들면 해안선은 엉성한 basemap에 묻혀 사실상 GPS에서 보이지 않는다. basemap에 묻히면 해안선 뿐만 아니라 시퍼런 바다에 등고선이 돋아있는 희안한 현상도 볼 수 있다.

남해안. 아래쪽은 새파란 바다여야 한다.

OSM의 랜더러들은 해안선을 판단해 바다와 육지 경계를 표시하므로 문제가 없지만, mkgmap, cgpsmapper 등에서 coastline을 적절히 처리할 방법을 찾아야 한다. mkgmap 제작자가 해안선을 처리할 방법을 나름대로 강구중인 것 같으나, 언제될 지 알 수 없다. 주욱 OSM 지도 작업을 하면서 느낀 거지만, 일단은 자력갱생 해야 한다.

현재로선 OSM 지도의 주 활용처가 Garmin GPS 디바이스인 관계로 이 문제를 해결하기 위해 임시변통 격으로(mkgmap에서 해안선을 다루게 될 때까지) polygon으로 구성된 해안선 데이터를 얻어와 바다를 구성하는 수 밖에 없다.

세계자전거오지여행의 운영자가 국가교통정보센터에서 공개한 한반도 도로 지도를 가공한 mp 파일에는 해안선 polygon 데이터가 있다(최근 데이터에는 없음). 이것을 뜯어와 img를 만들어 봤더니 드디어 바다와 육지가 구분되었다. 그런데 문제가 좀 있다.

해안선을 확대하면 디지타이즈된 라인이 아마도 한반도 저해상도 파일을 가지고 작업한 것처럼 라인이 단속적으로 끊어졌다.

성격은 좀 다르지만 국가교통정보센터의 도로에도 비슷한 문제가 있다.

오버줌 상태에서 보면 라인이 매끄럽게 연속적으로 이어진 것이 아니라 단락적으로 지글거린다. 이 때문에 도로만 데이터 크기가 350MB나 되어 OSM 서버에 도로 데이터를 올리는 것을 계속 망설이고 있었다. 해안선 문제 뿐만 아니라, 불필요한 노이즈를 억제하여 도로 데이터의 크기를 줄이는 방법도 역시 필요하다.

이들 문제를 해결하기 위해 벡터를 보간하는 방법을 궁리했다. 첫번째 방법은 벡터의 연속된 인접 3점으로 구성된 삼각형의 무게 중심을 구하는 공식을 이용해 다음 지점을 구하는 것이다. 그림으로 그리면,

좌상단이 첫 포인트, 우상단이 마지막 포인트. 두꺼운 실선은 원래의 좌표 벡터. 푸른선은 3점 포인트를 이용해 구성된 삼각형, 붉은선은 ABC 세 점으로 이루어진 연속적인 삼각형의 중심을 따라 이어진 선.

이렇게 하면 anti alias를 한 것 같은 효과가 나타난다. 원래의 검정 실선보다 붉은 선이 좀 더 부드러워지는 것. 포인트 수는 원래 7개에서 5개로 줄었는데, polyline이 상당히 길 경우 이 알고리즘을 적용하면 포인트의 수가 대략 1/2로 감소한다. 즉 파일 크기가 50% 줄어든다. 식: 각 점 A,B,C가 (x1,y1), (x2,y2), (x3,y3)로 구성되어 있을 때 삼각형의 중심은 xc = (x1 + x2 + x3) / 3, yc = (y1 + y2 + y3) / 3.

두번째 삼각형과 세번째 삼각형에서 지나친 평균화 때문에 라인이 뭉툭해진다. 이것을 개선하기 위해 알고리즘을 바꿔 마름모의 중심을 이용하되 마지막 3점은 삼각형으로 계산하는 형태로 바꿨다.

삼각형보다는 원래 형태가 잘 반영되었다. 사각형(마름모) ABCD의 중심점은 xc = (x1 + x2 + x3 + x4) / 4, yc = (y1 + y2 + y3 + y4) / 4. 이것을 일반화하면 xc = (x1 + x2 + ... + xn ) / n, yc = (y1 + y2 + ... + yn) / n. 어? 정리해 놓고 보니 좌표의 이동 평균을 취한 것이다. 기껏 머리 좀 굴렸더니만 하하. 이때 n이 증가하면 포인트 수는 줄어드는 대신 궤적의 변화는 둔해진다.

과문한 탓에 더 빠르고 훌륭한 알고리즘을 만들진 못했다. 어디 뒤져보면 꽤 괜찮은 알고리즘이 있을 것 같다. 이쯤 해두고 알고리즘을 구현했다. 간단한 프로그램을 작성해 원래의 해안선 Polished file을 변환해 보았다.

원본.

알고리즘 적용.

만들긴 했지만 해안선은 애당초 DEM처럼 정밀한 데이터가 필요하다. 운 좋게 그걸 구하게 되면 이건 폐기할 것이다. 일단은 이동평균법을 이용해 Garmin GPS용 해안선을 예쁘게 만들었고(OSM 서버에는 안 올린다), 주 활용은 도로 데이터의 크기를 줄이는 것이다.

일단 OSM 서버에 도로 업로드하는 것은 당분간 안 하기로 했다. 도로 작업은 앞으로 몇 단계로 나뉘어 진행하게 될 것 같은데... 1. interpolation. 2. merge lanes. 3. connect. 4. add route information.

어쩐지 삽질하는 느낌을 지울 수 없다. 이런 데이터는 어딘가 이미 있다. 단지 그 데이터를 구하지 못해서...

OSM 작업노트 #9: bulk upload

GPS 2009. 6. 5. 17:42

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으로 작업했다.

게다가 울릉도 DEM 자료는 해발 980m 가량의 성인봉이 잘려 나갔고 군데군데 쥐가 파먹은 것 같은 구멍이 있다. 뭐가 잘못된 것일까.

globalmapper에서 다시 작업했다. 제대로 나온다. srtm2osm이나 groundtruth는 사용해선 안될 프로그램 같다. :)

울릉도, 독도는 DEM 및 표준도로 데이터와 coastline이 조금 어긋나 있었다. 그리고 어긋난 것은 지금으로썬 PGS의 coastline이 잘못된거지 싶다. 울릉도 표준도로는 웹 검색으로 구한 울릉도 트랙로그와 맞춰놓은 것이다.

지도 만들기 작업하면서 지도 만들고 MapSource로 볼 때면 MapSource가 동일 id의 지도를 볼 때 그 지도의 데이터를 캐싱해두기 때문에 제대로 작업이 된 것인데도 화면에 안 나타나는 경우가 있다. 그때는 맵소스를 띄우기 전에 C:\Documents and Settings\<사용자 ID>\Application Data\GARMIN\MapSource\TileCache 디렉토리의 파일을 모두 삭제한다. 그보다 간단한 방법은 만들어놓은 가민용 IMG 파일을 MapEdit에서 읽어서 확인하는 것. 하지만 전체 지도의 일관성을 확인하려면 최종 확인은 여전히 MapSource로 해야 할 것이다.

OSM2IMG를 개정했다. mkgmap.jar가 실행중 에러가 발생했을 때 에러 코드를 리턴하지 않기 때문에 사실 맵이 제대로 만들어졌는지 확인하기가 좀 힘들다. console output을 캡쳐해서 다만 에러 메시지만이라도 확인할 수 있게 했다. 또, MapSource에 설치할 때 registry에 자동 기록하고 registry 파일을 만들게 했다. 그리고 MapSource에 설치될 때 tile cache를 삭제해서 MapSource에 이상한 표시가 나오지 않도록 했다. OSM2IMG가 이제 썩 쓸만한 프로그램이 되었다. 이 김에 제대로 만들어서 배포할까?

한강 작업 때문에 메르카토르를 사용해 보고 어느 정도 쓸만하다 싶어 북한산 트래킹 코스 작업을 해봤다. Potlatch에서는 작업중 데이터를 날려 먹어 귀중한 3시간을 허비했다. JOSM에서는 WMS로 야후 맵을 출력하는 속도가 워낙 느려 답답했다. 메르카토르에서 두어 시간 작업하다가... 황당하게 프로그램이 다운되었다. 뭘 해도 쉽지가 않네? 간단한 작업에나 사용할 수 있을 듯. 메르카토르는 태그 에디팅이 좀 많이 불편한 편. 다음 버전 나올 때까지 기다려보자.

OSM 작업노트 #8: 새로운 지도

GPS 2009. 6. 1. 19:33

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

2주 전에는 약 1주일 동안 OSM에 독도 그리기 작업을 했다. 그 동안 OSM 한국 지도에 독도가 없었다. 독도가 OSM에 아주 콩알만하게 나와 망망대해에서 섬을 찾을 방법이 사실상 없어 울릉도와 독도 사이에 관광 여객선 루트를 넣었다. google을 뒤져보니 누군가 울릉도에서 유람선을 타고 독도로 가는 동안 트랙로그를 남겨둔 것을 찾아서 작업은 쉽게 끝났다. 하는 김에 동해와 울릉도 관광선 경로도 완성했다.

아쉽지만 정확한 POI 정보가 없어 옛 선착장과 새 선착장 정도를 그리고, 어디서 줏어온 완전하지 않은 아웃라인(coastline)을 그려넣는 정도로 만족했다. 한국인의 독도에 대한 대단한 관심과 열정과 달리, 언제나 그렇지만(당연하게도) 데이터는 없다. 저 꾀죄죄한 독도의 몰골을 개선해줄 획기적인 방법은 없을까?

독도는 그렇다치고, topo 10m 작업과 전국 도로를 넣으니 자료가 무척 그럴듯하다.

완성된 두 지도를 MapSource에서 비교했다. 북한산 백운대 부근. 위엣 것은 SRTM3 10m, 아랫것은 비지니스 GIS에서 얻은 Topomap 30x30m 짜리. 파일 크기는 거의 비슷하지만, 등고선만 봐도 확연히 차이가 난다. OSM에는 topo map을 올릴 수 없다. 자료 자체가 너무 커서. 아래 지형도는 오차가 있는 듯 한데, 현재는 동측(easting) -30m, 북측(northing) -300m를 오프셋으로 주고 어거지로 맞춘 것이다. 전국의 4개 측점을 기준으로 재 보았으니 대충은 맞겠지만 아무래도 계산대로 나온 것이 아니라서 불안하다. 사실 등고선 지도의 정밀도를 측정할 방법이 없다. GPS자체도 믿을 수가 없고.

Map Level이 달라 두 지도의 등고선 표시 형태가 다르나, 어쨌든 그건 무시하고, 표준 도로 때문에 고속도, 국도, 지방도, 그리고 광역시에서는 시전역 주요도로 등이 나타난다. 아울러 이전 지도에서 도시 정도만 표시된 것과 달리 새 지도에서는 행정구역 대부분(시군구읍동리)을 보여준다. 여기에 water body(저수지, 호수 따위)도 추가되었다. 모든 주요 도로에는 번호와 이름이 붙어 있고 교차로 역시 이름을 갖는다. 그래서 POI가 15만개 가량으로 늘었다. 안 세봐서 정확한 숫자는 모르겠다.

그런데 문제가 있다. 지도는 한국에서 가장 작업이 잘 되어 있어 언제나 예로 들기 만만한 대전광역시. OSM에 있는 기존 도로와 표준 도로가 겹친다. 이걸 확대해 보면,

표준 도로는 중앙선 분리가 되어 있고 기존 도로는 중앙선 분리를 안 했다. 표준 도로는 중앙선으로 분리된 두 도로편의 벡터가 맞게 설정되어 있지만 기존 도로는 1차선 편도로 그려놓았기 때문에 방향 설정이 맞지 않다. 새 도로는 다른 도로와 연결(join)되어 있지 않다.

문제는, 추후 routable map을 만들 때 올바르게 방향이 설정된 도로 벡터가 필요하므로 표준 도로를 사용해야 하는데, 이렇게 되면 나를 포함한 남들이 수개월에 걸쳐 정성들여 작업한 기존 도로를 모두 지우고(그렇다. 그들의 노고가 완벽한 과거의 삽질이 된다) 연결이 안되어 있는 새도로의 연결을 일일이 손을 만들어줘야 한다(프로그램으로 자동으로 하려다가 대체 어떻게 해야 할 지 끔찍해서 중단).

일단 내가 작업한 도로(motorway, primary, secondary)는 자동으로 지우는 작업을 할 수 있을 것 같다. 이것도 시간이 걸리는 일이다. 남들이 만든 도로를 지울 때 어떻게 말해야 하나 싶다.

여하튼, 이 자료만 OSM에 올리면 사실상 한국 지도가 완성된다. 앞으로 진행할 작업을 생각하면 한숨이 나오지만...

이번 작업 정리:

남한 자료는 OSM 호스팅하는 Cloudmade에서 다운로드. 표준도로들.osm은 이전 표준도로 자료에서 레이어별로 뜯어낸 .mp 파일을 .osm으로 편의상 변환한 것들(곧 JOSM 등의 프로그램으로 OSM에 업로드할 것이다)로 여러개다. *.img는 topomap용 dem 데이터(다운로드 링크). globalmapper로 변환하니약 1시간 정도 걸렸다. mkgmap.jar는 *.mp 및 *.osm 파일을 입력으로 받아 garmin용 맵을 생성해준다. mkgmap.jar에는 이상한 버그가 있어 확장자가 .mp처럼 소문자이어야지만 처리한다. mkgmap.jar로 garmin map 파일 생성하는데 걸리는 시간은 대략 30분.

globalmapper용 파라미터 및 스크립트는 OSM 작업노트 #7: 작업 중간정리 참조.

mkgmap.jar 실행 파라미터:

java.exe -enableassertions -Xmx512m -jar "D:\gps\tool\mkgmap\mkgmap.jar" --description="(C) 2009, luke" --mapname="34100000" --family-id=440 --product-id=1 --country-name="South Korea" --country-abbr="KOR" --code-page="1252" --name-tag-list="name:en,name:ko_rm,name" --transparent --ignore-osm-bounds --no-poi-address --add-pois-to-areas --lower-case --tdbfile --overview-mapname="44000000" *.mp *.osm

표준도로 데이터는 앞으로 1-2개월 안에 OSM 안에 삽입할 예정이다. 그러므로 부러 다운받도록 어딘가 올려둘 필요는 없을 것 같다. 나중에는 cloudmade.com에서 south_korea.osm.bz2만 다운받으면 되니까. 표준도로들의 원래 파일리스트:

고속도로.osm

국도.osm

지방도.osm

도심로.osm

교차로및지명.osm

국립공원.osm

저수지및호수.osm

GlobalMapper가 유료 프로그램이라 DEM의 MP 변환은 소스를 알려 줘도 쉽지 않은 일이 될 것 같다. 25개의 *.mp 파일들은 합쳐서 약 1GB 쯤 되는 데이터라 압축해도 어디 올려놓기는 뭣하다. 사실 정밀도 문제 때문에 공개한다는게 의미있는 일인지, 일단 한동안 검증부터 해봐야지 싶다.

한가할 때 최종 출력 파일만 공개할 생각이다. 설치도 번거로우니 간단한 인스톨러를 만들어야겠다.

OSM 작업노트 #7: 작업 중간정리

GPS 2009. 5. 21. 19:11

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

OSM 작업을 하면서 지금까지 만든 프로그램과 라이브러리. 컬러 코딩: 파란색=Application, 빨간색=Library, 노란색=외부 라이브러리.

REW, NCAP, POI2OSM 프로그램은 다시 쓸 일이 없다. POI2OSM은 한글 로마자 변환할 때 참고하려고 가끔 쓰게 될 지도 모르겠다. 앞으로는 MP2OSM과 OSM2IMG 정도만 사용하게 될 듯. MP2OSM은 이미 perl 버전으로 누군가 만들어 놓은 것이 있으니 공개할 필요가 없고 OSM2IMG 역시 mkgmap의 front end로 사용하려고 만든 GUI wrapper이므로 공개할 일은 없을 것 같다. 결국 이 프로그램 전부는 한시적 작업을 위한 것인 셈.

이하 작업 설명에 사용하는 컬러 코딩: 연두색=입력 파일, 파란색=Application, 빨간색=출력 또는 작업.

POI2OSM은 세 종류의 입력 파일을 받는다. .CSV는 Garmin에서 POI Uploader 프로그램이 사용하는 포맷. .KML은 Google Earth에서 사용하는 포맷. .GPX는 GPS 관련 프로그램들 사이에 데이터 교환을 목적으로 만든 포맷. POI2OSM은 이런 입력 파일을 받아 .OSM을 생성하는데, 주로 POI 이름을 .OSM 포맷에 맞는 태그로 변환한다. 이때 사용하는 태그는 name(한글 및 영문 이름), name:en(영문 번역 + 로마자 발음 표기명), name:en_rm(로마자 발음 표기명)이다. 좌표 변환은 TM 중부 좌표를 변환하려고 끼워 넣었다. 예전에 얻은 자료가 TM 좌표라서 그것을 변환시키기 위해서다.

지하철역, 행정도시 등의 좌표 입력을 구글 어스에서 하고 구글 어스에서 생성시킨 .KML 파일을 .OSM으로 변환하기 위해서도 사용했다. 또한 GPS에서 얻은 POI 변환에도 사용했다.

REW/NCAP은 7만 여개의 POI 수집 작업 중에 사용하던 프로그램이다. 먼저 '대학교'라는 명칭 분류를 사용해 구글과 네이버의 검색 결과를 뒤져 대학교 이름들을 얻어오고 이것들을 Yahoo POI 검색에서 좌표를 얻어와 파일로 저장했다. 파일에는 명칭, 좌표 달랑 둘 밖에 없는데, OSM 파일로 변환하기 위해서는 적절한 tag가 가미되어야 한다. 예를 들어 신라호텔은 amenity=hotel 태그를 가져야 하고, 은평초등학교는 amenity=school 태그를 가져야 한다. 이런 명칭 분류는 수동으로 할 수가 없어 명칭에 포함된 특정 문자열을 검색해 그에 알맞는 태그로 변형시킨다.

최종 출력물 중 .KML은 이렇게 얻어진 좌표를 구글 어스에서 확인해(샘플 검사) 좌표 및 명칭이 올바른 위치에 있는지를 확인하기 위해서였다. 7만여개의 태그 분류는 거의 손으로 확인했지만, 7만개의 좌표의 올바름까지 다 확인할 수는 없었다. 프로그래밍과 별도로 명칭 수집과 분류에만 엄청나게 많은 시간을 소비했다. 문제가 많은 작업이고, 완벽할 수도 없었고, 이런 작업을 다시 할 일은 없을 것이다.

이렇게 해서 OSM에 넣은 자료와 손으로 그린 도로 지도(고속도로 따위)를 합치고 SRTM3 topo map을 합친 것이 최종 결과물이었다.

topo map을 만드는 과정도 만만치 않은 작업이라 어떻게 이를 단순화할 수 있는 방법을 찾다보니 osm의 몇몇 유틸리티가 dem2topo 프로그램과 마찬가지로 dem 파일로부터 등고선을 생성시켜 주는 것을 알게되었다. 하지만 이 프로그램 들을 사용해 topo map을 만들어 본 결과 이전 SRTM3 데이터보다 시간만 오래 걸리고 결과는 그저 그랬다. 애당초 SRTM3 데이터의 정밀도가 떨어지는 것이 문제인 것이다.

하여튼 이전 작업을 도표로 정리하면,

SRTM3 자료를 DEM2TOPO 프로그램을 사용하여 polished file을 만든 다음,

MapEdit와 cGPSMapper, MapSetToolKit, SendMap등의 프로그램을 이용해 .IMG를 만들고 이것을 MapSource에서 사용하도록 변환한다. 이 방법은 시간도 많이 걸릴 뿐더러 과정이 복잡하고, GPS에만 사용하는 데이터를 만드는 것 이상의 의미가 없다.

하여튼 DEM 자료의 정밀도가 떨어지는 문제부터 해결 방안을 찾기로 했다. 어떻게 방법이 없을까 고민하다가 http://www.biz-gis.com 사이트에서 상당히 정교한 DEM 파일을 다운로드 받을 수 있도록 공개한 것을 알게 되었다. 10m 정도에도 문제가 없어 보였다.

그래서 Topo map을 다시 작성하는 작업에 착수했다. 이번에는 globalmapper로 작업했다.

두 가지 문제가 있다. GlobalMapper의 script 버그로 25개의 파일을 스크립트로 변환하면 등고선을 10m 마다 따게 해 놔도 자기 멋대로 20m 단위로 따는 문제가 있다. global mapper의 버그로 추정된다. 25개의 파일을 일일이 하나 하나 변환하다 보니 시간도 시간이지만 변환이 아주 귀찮다. 변환 완료된 것을 보고 다음 파일을 또 변환하려니 일을 하면서 하루가 꼬박 걸렸다. --> 2009/05/22 Simplification factor를 지정해서 해결. dem 파일 변환에 사용한 스크립트:

GLOBAL_MAPPER_SCRIPT VERSION=1.00
UNLOAD_ALL

DIR_LOOP_START DIRECTORY="D:\GPS\DEM 2008" FILENAME_MASKS="*.img" RECURSE_DIR=NO

IMPORT FILENAME="%FNAME_W_DIR%" PROJ_FILENAME="D:\GPS\DEM 2008\Korea TM.prj"

GENERATE_CONTOURS INTERVAL=10 ELEV_UNITS=METERS SPATIAL_RES=30.0,30.0 FILL_GAPS=YES SMOOTH_CONTOURS=YES SIMPLIFICATION=3.0
EXPORT_VECTOR FILENAME="%DIR%\out\%FNAME_WO_EXT%.MP" TYPE=POLISH_MP GEN_PRJ_FILE=NO TEMPLATE_FILENAME="D:\GPS\DEM 2008\template.mp"

UNLOAD_ALL
DIR_LOOP_END

주의: .MP를 만들 때 MP Template file을 사용하지 않으면 metric을 meter로 지정해도 feet로 바뀐다. 스크립트에서 사용한 템플릿 파일(template.mp):

[IMG ID]
CodePage=1252
LblCoding=9
ID=02309485
Name=Korea
Elevation=M
Preprocess=G
TreSize=511
TreMargin=0.00000
RgnLimit=1024
Transparent=S
POIIndex=N
Copyright=2009, luke
Marine=N
Levels=4
Level0=24
Level1=22
Level2=20
Level3=18
Zoom0=1
Zoom1=2
Zoom2=3
Zoom3=4
[END-IMG ID

스크립트에서 사용한 프로젝션 파일(Korea TM.prj):

PROJCS["Transverse_Mercator",GEOGCS["Geographic Coordinate System",DATUM["WGS84",SPHEROID["WGS84",6378137,298.257223560493]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["scale_factor",1],PARAMETER["central_meridian",127],PARAMETER["latitude_of_origin",38],PARAMETER["false_easting",199960],PARAMETER["false_northing",499700],UNIT["Meter",1]]

두번째 문제: 원본 DEM 자료의 projection이 TM인데 False Easting 20000, False Northing 50000, Scale Factor 1.0, Central Meridian 127.0, Latitude of Origin 37.0 으로는 남쪽으로 300m, 서쪽으로 65m의 오차기 있다.

어디서 들은 풍월이 있어 이런 저런 파라미터를 변경해 봤지만 문제가 해소되지 않았다. 그것도 일률적인 것은 아니었다. 데이터 파일에 따라 각기 다른 프로젝션으로 시도해 봤으나 역시 조금씩 에러가 있었다. 어쩌면 MapSource의 버그 때문일지도 모르겠다. MapSource는 이전 지도 데이터를 캐싱해 두기 때문에 .IMG 파일을 새로 만들었음에도 이전의 잘못된 프로젝션에 의해 나타난 데이터가 다시 나타나기 때문인지도 모른다.

하여튼 그래서 프로젝션 파일을 하나 만들고 파라미터를 조정해서 최대한 오차를 줄였다. False Easting 199960, False Northing 499700, Scale Factor 1.0, Central Meridian 127.0, Latitude of Origin 37.0 이건 아무리 생각해도 편법이다.

이 자료에는 울릉도가 빠졌다. 울릉도 부분은 SRTM3에서 가져와야 할 것 같다.

이렇게 해서 만든 10m Topo Map은 SRTM3에 비해 현저하게 부드러운 등고선을 보여준다. topo map이야 매일 작업하는 것이 아닌 이상 정확한 프로젝션과 엘립소이드 정보를 알면 더 이상 바랄나위가 없는 등고선 지도를 만들 수 있게 된다.

그 다음에 얻은 .MP 파일은 한국 전역의 고속도로, 국도, 지방도 및 분기점 정보다. 여기에 면 단위 행정구역과 저수지 정보 등 완전히 노다지를 얻은 기분으로 데이터를 쳐다봤다. GNS에서 16만개의 POI 정보를 얻기는 했지만, 이 자료는 여태까지의 OSM 작업을 대부분 삽질로 돌려버릴 정도로 임펙트가 강했다.

당장 .mp 파일을 .osm 파일로 변환시키는 프로그램 제작에 착수했다. 뭐 그래봤자 작업일수로는 이틀 걸렸지만.

mp2osm 프로그램을 누군가 perl, python으로 만들어 놓은 것이 있었다. 하지만 굳이 그 프로그램을 사용하지 않고 새로 만든 이유는, 이름 변환 따위의 후반부 작업을 통합하기 위해서다. *.mp 파일의 데이터 크기가 300MB 가량이라 스크립트의 느린 실행속도를 감내하기도 그렇고, 이왕 OSM 작업을 하면서 만들어놓은 각종 라이브러리가 있으니 차라리 프로그램을 짜는게 낫다고 생각.

mp2osm 프로그램은 아직 multipolygon 처리를 하지 않았다. 나중에 수계 데이터 쪽을 다루게 되면 그쪽 작업이 필요하다. 두번째로 *.mp 파일의 coastline이 OSM의 coastline보다 정밀해서 그것만 따로 따낼 방법을 찾아봐야겠다.

하여튼 이렇게 만든 .osm 파일을 이용해 MapSource용 .tdb와 GPS용 .img를 만들려니 문제가 생겼다.

*.osm 파일을 *.img로 변환시키기 위해 mkgmap.jar를 사용해야 하는데, 이렇게 만들어진 *.img는 MapsetToolkit/cGPSMapper에서 통합한 후 MapSource로 읽어들일 때 오류가 발생한다. 다 안되는 것은 아니고 .osm을 변환한 .img 중 딱 한 파일만 안되서 대체 뭐가 문제인지 원인을 찾느라 시간을 많이 소비했다. 아무래도 MapsetToolkit이 사용하는 cGPSMapper와 mkgmap 사이의 궁합에 뭔가 문제가 있는 것 같다.

이 방법은 예전부터 마음에 들지 않았다. 툴이 일원화 되어 있지 않고, 버그 투성이에, 특히 freeware 버전의 cGPSMapper는 routable map도 만들 수 없다. 그래서 mkgmap만 가지고 작업해 보기로 했다.

mkgmap.jar가 java 프로그램인데다, 옵션은 cGPSMapper만큼 많아 무슨 작업을 하려면 옵션 때문에 정신이 사나와 mkgmap.jar를 실행할 수 있는 GUI front-end인 OSM2IMG을 만들었다. cGPSMapper를 사용하지 않으니 만사가 다 해결되었다.

.OSM 파일은 JOSM을 이용해 OSM database에 업로드할 수 있다. JOSM 버그인지 OSM 사이트의 버그인지는 확실치 않지만 10MB 정도의 .osm 파일을 JOSM으로 업로드하다가 중단되었다. API가 아직 안정화되지 않아 다수 문제가 있지만 차차 안정화될 것이다. JOSM 띄우는 것도 버거워서 uploader를 만들었으나, API가 0.5에서 0.6으로 바뀐 부분을 반영하지 않아 호환되지 않는다.

내친 김에 topomap 자료인 10m 짜리 .mp 파일 중 용량이 비교적 작은 제주도를 mp2osm으로 변환한 후 osm2img와 mkgmap으로 .img를 만들어 보았다. 잘 된다.

궁극적인 목표는 보라색 테두리를 친 부분이다. 누구나(한국인을 비롯한 외국인 누구나) OSM에서 한국 지도 자료를 다운받아 mkgmap만 가지고 Garmin용 지도를 만들 뿐만 아니라 웹 상에서도 지도를 활용하는 것이다.

앞으로 할 작업 리스트

* 표준도로 mp파일에서 할 일들

* 작업 정리

* DEM 10m에서 해안선 뜯어오기

* 왜 25m의 오차가 생기는 것일까?

* 울릉도 도로 다시 테스트

* DEM 파일로부터 .osm으로 직접 변환 시도.

* 추후 표준도로 mp가 업데이트 되었을 때 일괄 변경 방법

* 기타 지도 작업

* 가져온 태그 정리(산,들판 따위 태그가 있음)

* 시/군/도 경계선 만들기

* osm

* korea map -- 기존 osm에서 한꺼번에 지울 방법과, 어떻게 지울지 방법을 궁리

* josm에서 큰 osm 파일을 보낼 때 fail 나는 이유 알아볼 것

* OSMbroker 개정(API 0.6)해서 업로드 가능하도록.

* mp2osm, osm2img 프로그램 업그레이드

* multipolygon 구현

* target dir 설치

* registry auto update

* registry read

* 표준도로파일에서 가져온 데이터의 태그 검증

* 지명및분기점.osm에서 불필요한 태그 정리

* mkgmap

* routable map을 만들려면 필요한 정보

* .osm contour 전체 파일 변환 시도

* level : 0:24,1:22,2:20 <-- 의미 명확하게 정리

* 맵의 레벨 정하기: osm_garmin_map.csv

* 개별 파일 단위로 옵션 주는 것

* .img 파일만으로 .tdb 생성

* style define

OSM 작업노트 #6: Garmin용 지도 공개

GPS 2009. 5. 14. 15:59

그저 일없이 미루고 있던 Garmin GPS용 OSM 지도를 공개했다. 이번이 두번째다.

제목: Garmin GPS용 지형도+OSM 지도

소개
====

이 지도에는 Open street map과 SRTM3 DEM을 변환한 지형도가 들어 있습니다. 저 자신이 개인적으로 사용하는 것으로 외국인들에게 한국 지도를 소개하기 위해 작업한 것입니다.

상용 지도 수준은 못되고, 영문 GPS에 넣을 마땅한 지도가 없는 분들을 위해 공개하는 것이며 자료의 정확도는 보증할 수 없습니다. 이후에 설명합니다.

다운로드
========

예전에 지형도를 올렸을 때 많은 분께서 다운을 요청하셨지만 보내드리지 못했습니다. 지금도 250MB 정도의 파일이라 어디 둘 곳이 마땅치 않네요. 일단은 기한이 정해진 대용량 메일과 아주 느리고 한번에 1-2명 밖에 받지 못하는 것으로 추측되는 windows live 계정의 skydrive에 파일을 올려두겠습니다.

http://gigafile.nate.com/download/sid=2&info=0caa52991517c46c33f99d75a660840f90c3862dd8b93a9e33524fbf235a5282e46aebd9bffcfc69d8202f8a5e0743fe8bf05b0ace57ac2fb552e96b58

Nate: 5월 21일까지 다운로드 가능.

http://bigfilel5.naver.com/bigfileupload/download?fid=0m+cbreZDBgrK3YwHX3Tax2ZHqUmKAvmFxudKxtqFoKXHquXKqk4FxMmFoUdMxblMxpCp6JSM4KqaApCM4KXFz3C

Naver: 5월 21일까지 20회 다운로드 가능.

http://mail16.paran.com/write/download.php?id=cyana@paran.com&home=/D16/c/y/a/cyana@paran.com&host=gigamail9.paran.com&port=80&bigpath=/D9/5/20090514/14/28/cyana@paran.com&uni=1242279405.10542.mail16x0.zip&bigname=Korea+OSM+Topo+Map.zip

Paran: 5월 20일까지 다운로드 가능.

http://www.filesavr.com/koreaosmtopomap

filesavr: 언제까지 다운 가능한지는 모르겠습니다.

http://cid-c828054758ad855f.skydrive.live.com/browse.aspx/.Public/KOTM

Skydrive. 언제든지 다운로드가 가능하나 여러 사용자가 동시에 다운이 안되는 것 같습니다. 그럴 때는 기다렸다가 다시 시도하던가, 다음날 받으세요. 참고: 파일당 50MB의 제한이 있어 여러 개의 파일로 나뉘어 있습니다.

동호회에 매일 들어오는 것이 아니라서 뒤늦게 쪽지를 보내 주시거나 업로드를 요청하시면 보내드리기가 어렵습니다. 위에 링크들에 올리는데만도 몇 시간 걸리네요 ^^; 그렇다고 250MB 짜리 파일을 장기간 보존할 공간이 없다보니, 행여 파일을 다운 받으신 분께서는 상기 대용량 메일 계정으로 자기 자신에게 메일을 보낸 후 다음분들이 쉽게 다운받을 수 있게 다운로드 링크를 댓글로 달아주면 좋겠네요...

설치
====

0. Korea OSM Topo Map.zip 파일을 C:\Garmin\OSMMap 디렉토리에 압축을 풉니다.

1. GPS에서 지도 보기(맵 복사)

   * sendmap.exe로 3*.img 파일을 로드한 후 GPS가 연결된 상태에서 전송.
   * 또는, GMAPSUPP.IMG 파일을 GPS에 직접 복사.
   GPS를 USB Storage 모드로 변경한 후 (Garmin Vista HCx의 경우 Setup->Interface)
   이동식 디스크의 Garmin 디렉토리에 GMAPSUPP.IMG 파일을 복사

   * GPS에서 지형도와 도로를 확인합니다.

2. MapSource에서 지형도 및 도로 지도를 사용하기

   * Korea OSM+Topo Map.reg 파일을 더블 클릭하여 registry 파일을 설치합니다.

   주의: 만일 C:\Garmin\OSMMap 디렉토리가 아닌 다른 디렉토리에 설치했다면
   Korea OSM+Topo Map.reg을 텍스트 에디터에서 읽어와 경로를 수정해 주어야 합니다.

   * MapSource에서 'Korea OSM+Topo Map'을 선택하면 지도를 볼 수 있습니다.

자료 및 정밀도
==============

topo map으로 사용한 SRTM3 자료는 NASA의 suttle survey 미션 때 radar 간섭 측량으로 얻은 자료를 3 arc second(90m x 90m) 단위를 한 픽셀 단위로 만든 것입니다. 픽셀당 고도 평균 오차는 16m로, 이것은 90m x 90m 단위 평면의 평균 고도 오차를 의미합니다. 오차에 관한 더 자세한 내용은 google을 뒤져보시면 될 것 같습니다.

SRTM3 자료 자체가 해상도가 떨어지는 것이라 지형도 데이터는 지형의 형세를 파악하는 목적으로 사용하는 것은 가능하나 산악 트래킹시 믿을만한 자료로 활용하는 데에는 주의를 요합니다. 예를 들어, 깊이 11m, 폭 15m의 협곡은 지형도에 반영되지 않고 얕은 여울로 나타날 수 있으므로 지형도만 믿고 산길을 개척 하다가는 봉변을 당할 수 있습니다.

이와 함께 공개 도로 지도 작성 프로젝트인 Open street map(http://www.openstreetmap.org)에서 틈틈이 작업한 한국 도로 및 POI 자료를 함께 더했습니다.

POI는 아주 많이 불완전합니다. 상용map의 POI 갯수는 300만개 가까이 된다고 하는데 제가 얻은 것은 약 9만개 가량입니다. 자료를 공개한 곳도 없고 얻을 곳도 없고 상용 데이터베이스를 가져와 사용할 수도 없기 때문에 지극히 원시적이고 시간이 많이 걸리는 방법으로 법률에 위배되지 않는 방식으로만 수집하고 입력했습니다. 현재 POI로 포함된 항목들은 기본적이고 필수적이라 할만한 것들로 다음과 같습니다.

초등학교, 중학교, 고등학교, 대학교, 경찰서, 도서관, 병원, 미술관, 박물관
고속도로 휴게소, 우체국, 버스터미널, 호텔, 모텔, 찜질방, 사우나, 야영장, 유스호스텔, 민박, 리조트
서울시 버스 정류장, 지하철역, 기차역, 해수욕장, 사찰, 성당

이들 자료를 google 또는 naver를 통해 명칭만 수집하고 yahoo의 poi 서치를 통해 2주에 걸쳐 좌표를 얻어내고 이들 좌표를 변환하여 osm에 입력한 것입니다. 프로그램을 짜서 돌린 것이라 태깅이 부정확하거나, 어떤 것은 경위도가 바다 한가운데 떠 있는 등 부정확한 것들도 있습니다. -_-;

이들 POI는 한글 로마자 변환과 한글 로마자+영문번역 단계를 거쳐 여러 개의 이름을 가지며 OSM 지도에서는 한글을 사용하고 GPS용 데이터에서는 로마자+영문번역 자료를 사용합니다. 예를 들어 '은평초등학교'는,

한글(name): 은평초등학교 (Eunpyong Elementary School)
로마자 변환(name:ko_en): Eunpyong Chodeunghakgyo
로마자+영문번역(name:en): Eunpyong Elementary School

이러는 이유는 첫째, 로마자 변환 만으로는 지명의 의미를 이해하기 어렵기 때문이고, 둘째, 로마자 변환은 그래도 존재해야 하는 것이 외국인들이 지명 전체를 발음할 수 있어야 하기 때문입니다(한국에 와서 길을 묻거나 할 때).

영문 번역 규칙은 영문 표기 사전(http://englishname.seoul.go.kr/jsp/index.jsp)을 참조했고 일부 영문 번역은 외국인들과 협의해 가용하고 타당한 범위에서 임의 번역했습니다. 이 와중에 로마자 표기에서 camel case와 hyphen 사용을 배제했습니다. 외국인들이 그걸 아주 끔찍해 하더군요.

도로는 대부분 yahoo aerial map을 참조하여 2개월에 걸쳐 손으로 그린 것이고 (yahoo aerial map과 naver의 항공사진은 소스가 같은 것으로 추정됩니다) gps로 자전거 주행 중 도로와의 오차를 검증해 본 결과 상용 수준은 아니라도 참고용으로 사용할 수준은 된다고 판단했습니다.

OSM 지도 작업을 계속하다보면 다음 버전은 아마도 꽤 괜찮은 지도가 될 가능성이 있다.

* complete 국도, 지방도

http://club.paran.com/club/home.do?clubid=bikeadventure

위 사이트에서 얻은 자료(전국 단위 표준 노드링크 데이터)를 변환하는 작업. 원본 데이터나 polished file은 도로 선로를 2개의 polyline으로 만들었고 접점이 없어 사실상 변환해도 수작업이 들어가야 하고 그 때문에 나중에 routable map을 만들기 어렵다는 문제점이 있다. 그러나 지금처럼 도로를 손으로 그리는 길고 지루한 작업 보다는 자동변환하는 것이 낫다고(없는 것보다는 낫다고) 보고 있다.

* DEM 정밀도 향상

http://www.biz-gis.com/bbs/zboard.php?id=pds&no=159

위 사이트 자료 적용 궁리. 테스트는 해 봤는데 TM 좌표계가 중앙 기준인 것 같아 동부나 서부의 오차가 어떻게 되는지 아직 테스트를 제대로 안해봤다. 하여튼 기존 SRTM 자료보다는 훨씬 부드럽고 깨끗한 10m 짜리 등고선 지도를 얻을 수 있었다. 자료 자체는 SRTM1과 같은 정밀도의 30m x 30m 인 것 같다.

* 전국 산행로 및 MTB(자전거도로) 지도

개인 및 여러 동호회에서 수집한 트랙 로그를 변환하려고 계획은 했으나, 저작권 등의 문제로 보류. 만약 그 분들이 osm에 트랙로그를 올려주면 공개할 의사가 있다는 뜻으로 받아들일 수 있지만, 동호회 자료를 수집해서 임의 가공하는 것은 문제될 소지가 있다. osm의 가치를 설명하고 설득하는 것이 좋겠지만(산행로 등을 공통 데이터베이스화하면 공공이익에 기여하게 된다 운운) 수개월째 생각만 하고 있는 중.

이 작업은 트랙로그의 GPS 수신 에러를 제거하고 normalize(경로를 단순화)한 후 여러 개의 트랙로그으로부터 경로 평균치를 구하여 편차를 줄인 산행로를 만들어 OSM에 올리는 일련의 작업을 자동화하는 과정이 될 것 같다. 아님 귀찮은데 대충 하고 말던가. 어차피 전국 어디가나 신작로처럼 변해버린 산행로에서 도로 오차가 2-3m쯤 난다고 누가 신경이나 쓸까? :)

OSM 작업노트 #5: API 및 이것저것

GPS 2009. 5. 12. 15:54

전용 GPS에 장래가 있을까? 없어 보인다. 안드로이드폰 나오면 조금 지켜본 후 그걸 살 것이다. 구글맵을 캐싱해서 가지고 다니면 지금 들고 다니는 GPS도 사실상 필요가 없어진다. 전화도 받고 자전거 주행하거나 산에 올라가서도 지형도 및 지도를 파악할 수 있는데 뭣하러 값비싼 돈 주고 전용 gps를 사서 생고생을 해가며 없는 지도 만드느라 시간을 보낼까? 다만 전용 gps는 생명을 답보한 극한 상황에서 안드로이드 폰보다는 신뢰성있게 작동할 가능성이 높다. 어쨌거나 전용 GPS의 장래는, 예전에 PDA를 잡아 먹고 여전히 성장중인 스마트폰에게 잡아먹힐 것이다. 의심의 여지가 없다.

다음 GPSGIS에서 SRTM3가 정밀도가 떨어진다는 얘기를 듣고 정말일까? 평소 궁금하게만 여기고 귀찮아서 뒤져보지 않았던 SRTM3의 오차에 관해 찾아봤다: SRTM 자료는 기본적으로 이미지 같은 것이다. 하나의 픽셀에 대한 elevation level이 기록되어 있는데, SRTM1 자료는 쉽게 말해, 한 픽셀이 1초(arc second) 단위로 가로x세로 30mx30m인 영역으로, 그런 픽셀이 3601x3601 크기이다. 전 세계를 커버하는 SRTM3는 3초 단위(90m)로 픽셀 영역은 1201x1201이다. 가장 널리 사용되는 SRTM3는 높이 오차가 약 16m이다. 즉, SRTM3는 90m^2에서 고도 오차 16m인 데이터다.

그다지 정밀한 자료 같아 보이지 않겠지만 어째서 SRTM3 자료와 GPS 바로미터의 고도차가 생각보다 크지 않았는지(오차가 적었는지) 알 수 있다. 경사도 15% (각도가 아닌 구배로 15m/100m)인 도로에서 SRTM3의 고도 오차를 제외한 인접셀과의 최대 오차는 15mx90m/100m = 13.5m. SRTM3의 높이 오차가 인접셀 사이에 비슷하게 평탄화되었다면, gps 고도 오차를 최소 2m로 감안하면 기약 100m 간의 직선 구간에서 10~20m 정도의 평균 오차 밖에 나지 않는다. 사실 DEM 자료를 만들 때 여러 가지 변수가 포함되어 오차 계산이 꽤 복잡할 것으로 추측되지만(오차 관련 자료: http://www2.jpl.nasa.gov/srtm/SRTM_paper.pdf
) 그래도 오차폭이 30m를 넘을 것 같지 않다.

한국에서는 도로 경사도를 15% 이상 넘지 않게 설계한다고 들었던 것 같다. 자전거 주행에는 SRTM3로도 문제 없어 보인다. 다만 산악 트래킹할 때 이 자료를 믿고 가다가는 절벽으로 추락할 수도 있다. 고도가 높은 산의 절벽면은 레이다 간섭 사각지대가 되어 void라고 부른다. 이것들을 제거하는 프로젝트가 있었다. http://srtm.csi.cgiar.org/

국내에서 지형도에 사용하는 데이터는 SRTM3를 사용하지 않고 항공 수준 측량을 한 것 같다. 그런 자료는 물론 공짜로 얻을 수도 없고 DEM으로 널리 배포될 것 같지 않다. 천상 SRTM3로 버텨야 한다.

GPS의 오차

위성이 무려 14-16개씩 잡히는 확 트인 개활지에서 gps 오차가 최저치인 +-2m임에도 도로를 벗어나는 궤적이 나타난다 -- 직선 도로를 주행한 후 트랙로그를 살펴보면 비뚤비뚤하다. 그것 말고도 샘플링 속도 때문에 자동차/자전거를 타고 고속 주행할 경우 트랙로그에 어쩔 수 없이 오차가 나타나기도 한다 -- 트랙로그를 1초 단위로 기록하면 고속으로 달릴 때 늦은 샘플링 속도에 따른 경위도 위치오차가 크게 벌어질 수도 있다. 트랙로그를 msec 단위로 기록하면 되지만 GPS의 작은 저장장치로 감당이 안된다. GPS 자체도 이들을 보정하기 위한 알고리즘을 사용하고 있는 것 같다. 하지만 자세한 정보를 얻지는 못했다.

마지막으로, 개활지가 아닌 좁은 소로처럼 수신율이 떨어지는 곳에서는 오차폭이 상당히 커진다. 도로폭이 3m 밖에 안되는 곳에서 양 옆으로 20여 m 높이의 건물들이 즐비하게 늘어서 있으면 수신율이 현저하게 떨어져 오차가 커지게 된다. 1차선 도로의 우측에 달라붙어서 가는 자전거의 경우 자동차보다 수신율이 떨어지는 것은 자명하다. 전용 GPS보다 수신율이 더 떨어지는 내비게이션 기기들은 그래서 내비게이션 화면에 나타난 현재 위치의 차량을 수신 좌표에 인접한 도로에 착착 달라붙여서 표시해 준다.

변산반도의 도로 지도를 yahoo aerial map만 보고 그렸는데 실 주행 데이터와 오차가 10m가 안 되었다. 사실 GPS에서 튀는 데이터가 있어서 GPS가 오히려 더 미덥지 않다. 구글맵스와 대조해봐도 마찬가지였다. 그말인 즉슨, 오차가 발생하기 쉬운 gps에 의존하여 OSM 지도를 그릴 것이 아니라, 오히려 Potlatch나 JOSM등의 백그라운드 yahoo map의 도로 윤곽을 보고 그리는 것이 낫다. 물론 residental/service road처럼 야후 항공 사진으로는 확인이 곤란한 지도에서는 gps의 트랙로그를 '참조'하여 지도를 그리는 것이 유리하다.

그래서 내 경우 OSM 지도를 그릴 때 GPS를 세컨드 디바이스로, 참조용으로만 사용했다. 믿을 수가 없으니까.

이런 저런 잡다한 작업을 하다가 다시 길을 그리기 시작했다. 사실 바빠서 길을 그릴 시간은 많지 않다.

OSM 서버가 최근에 업그레이드 되면서 API 버전이 0.5에서 0.6으로 올랐다. transaction과 비슷한 changeset이 도입되었고 database 접근은 전보다 훨씬 빨라졌다. 그러나 대량의 데이터를 가져오는데 자주 쓰곤 했던 XAPI는 아직 불완전해서 API로 업로드한 대량의 데이터가 XAPI로 반영되는데 시차가 존재한다. 4월 업데이트 이후 XAPI는 여전히 안정이 되지 않았다. XAPI query는 가끔 입력한 POI가 엉터리로 나왔다. 사실 좀 종잡을 수가 없다.

0.5에서 0.6으로 API가 바뀌면서 이전 프로그램과의 호환성이 떨어졌다. JOSM는 재빨리 업그레이드가 되었고 메르카토르는 조금 늦었다. Potlatch도 물론 업그레이드 되었다. 아쉬운 것은 XML 압축 규격이 없고, OSM 역시 XML 압축을 만들지 않아 데이터 전송량이 클 경우 전송 자체만으로도 꽤나 많은 시간을 소비한다는 점이다.

JOSM에서 사용하는 .osm 파일에도 변화가 생겼다.

<?xml version='1.0' standalone='no'?>
<osm version='0.6' generator='osmxapi: OSM Extended API' ...>
<node id='368646044' lat='38.222193' lon='127.209948' user='...' action='modify' visible='true' version='1' >
<tag k='name' v='Sample'/>
</node>
</osm>

XAPI가 여전히 0.5 베이스로 작동하기 때문에 패치한 xml 파일의 버전 정보가 아직 없다. changeset이 도입되면서 이제는 way, node 따위의 버전을 체크하고 그것들을 변경시 증가시켜야 한다. 대량의 데이터 작업에서 xml diff를 사용케 하겠다던 것 역시 아직은 버그 때문에 적용되지 않았다. XAPI가 xpath를 지원하지 않고 단순한 bounding box를 사용하기 때문에 사실 이만저만 불편한 것이 아니나, 언젠가는 차차 안정화되겠지 하며 기다리고 있다.

새로운 API에 맞춰 만들어놓은 간단한 프로그램들의 OSM broker 소스를 개정해야 하는데... 좀 귀찮아서 관뒀다.

그동안 Potlatch 한글화를 했다. 메시지 한글화에 큰 의미는 없어 보인다. wiki 페이지도 한글화할까 하다가 누군가가 해 놓은 한글화만으로도 충분하다고 생각했다.

mkgmap과 srtm2osm 따위 프로그램을 사용해 지형도와 스트릿 맵을 완샷에 작업하는 스크립트를 짜느라 하루 정도 시간을 보냈다. 결론은, 참 쓸모가 없고 시간과 노력만 허비했다. 기존에 만들어놓은 지형도 데이터보다 정밀도나 해상도는 떨어지지만 시간은 좀 단축시킬 수 있다. 스트릿맵이야 원래와 같으니까 상관없다.

별도로, Wikiloc에 경로 그리기 메뉴가 추가되었다.

사실 정말 필요한 것은 gpx 업로드해서 gpx를 분석하고 트랙로그를 지도와 연동해 화면에 표시해주는 것 보다, 자전거 여행할 때 구글 맵이나 다음 맵 따위를 배경에 깔고 저것처럼 경로를 그려준 다음 gps에 업로드해 행복하게 트랙백을 하는 것이다. 그 정도 작업을 하려면 아무래도 웹 프로그래밍을 배워야 할 것 같은데 어째 시간이 많이 걸릴 것 같아 누군가 해주겠지... 아니면 구글 뒤져보면 누군가 만들어 놓았겠지 하는 막연한 생각만 들었다.

SportTracks

GPS 2009. 4. 23. 15:05

상오기님 블로그에서 SportTracks이란 프로그램을 보았다. 그러고보니 어디선가 이름을 들어본 적이 있는 것 같다. 트랙로그를 관리해 주는 프로그램인데, 해당 사이트의 플러그인들을 보니 단순한 트랙로그 관리 프로그램이 아니었다. 여태까지 트랙로그를 워낙 원시적으로 관리하고 있던 차라(.gdb 또는 .gtm으로 기록하고 주행기록 정보는 excel로 별도 관리) 이 김에 맘 먹고 써보기로 했다.

써보면 써 볼수록 놀랍다. 특히 플러그인으로 제공되는 기능이 막강하다. 프로그램의 목적이 단순한 트랙관리 뿐만 아니라 운동선수를 위한 지속적인 트레이닝 관리에 있다는 걸 알 수 있었다. 이거 운동선수에게 꼭 필요한 프로그램같다. 나처럼 주말에나 간신히 레저용으로 바이크 잠깐 타는 사람이야 단순히 트랙로그 관리 정도로 사용할 법하지만. 시간 날 때 좀 더 세부적으로 파악해 보기로 하고, 기본적인 사용법은 상오기님 블로그에서 확인하면 될 것 같으니, 프로그램 운영에 필요한 몇 가지 플러그인에 관한 정보를 정리해 둔다.

플러그인 설치: 확장자가 .exe이거나 .st2plugin인 파일은 SportTracks 설치 후 더블 클릭하면 설치가 된다. 그외 확장자가 .dll인 것들은 SportTracks이 설치된 디렉토리의 plugins 서브 디렉토리에 복사해 놓는다. 플러그인 설치 후 SportTrack을 다시 시작해야 한다. 유용한 플러그인은 다음과 같다.

GPSBabel: gps 파일 포맷간 변환. gpsbabel 설치 후 커맨드라인 툴인 gpsbabel.exe및 libexpat.dll 파일을 plugin 설치 디렉토리에 복사해 두어야 한다. 자신의 트랙로그 뿐만 아니라 다른 사람들의 유용한 트랙로그를 가져와 난이도를 분석한다던지 하는 용도로 사용하려면 이 플러그인을 설치해두는 것이 필요해 보인다.

GPS Correction: GPS 측점 중 거리가 음수로 나타나는 것들(잘못된 것들)을 평가해 제거한다. 눈에 띄게 달라지는 것을 느끼진 못했다.

Elevation Correction: GPS Barometer가 없거나, 있어도 기압고도 변경이 심하여 원래 해발고도와 다르게 기록되는 경우 SRTM 자료를 이용해(플러그인 설치후 자동으로 다운받는다) 해당 경위도의 고도로 교정한다. SRTM3의 경우 SRTM1을 3x3 매트릭스로 평탄화한 자료로 고도 오차는 최대 90m까지 벌어질 수 있다는 말들이 있는데, 실측 결과 20-30m 정도의 차이를 보였던 것 같다. 사실 90m 오차라는 말의 신빙성을 확인할 수가 없어 좀 더 찾아봐야겠다.

Analyze Elevation Correction: Elevation Correction 플러그인으로 교정한 고도와 GPS 트랙로그 고도를 비교하여 지나친 차이가 발생하는지 여부를 평가한다. 고도 교정 플러그인의 SRTM 자료가 정밀한 것은 아니라서 GPS 측점이 맞을 수도 있다. 그런데 이 플러그인이 실제로 작동하는지 그 여부를 확인할 수 없었다.

High Score: 최대 속도, 최저 속도 등 가장 높은 점이나 가장 빠른 속도 순으로 GPS 기록측점 을 정렬하여 테이블 형식으로 보여준다.

Overlay: Activity를 2개 이상 겹쳐서 보여주는 플러그인. 예를 들어 같은 코스를 여러 차례 주행할 때 두 주행 기록 사이의 퍼포먼스를 평가해 보고 싶을 때 오버레이 뷰를 사용한다.

GPS2PowerTrack: activity(tracklog)를 분석하여 칼로리 소비량을 계산해 준다. 분석을 위해 날씨 정보를 수집해야 하는데, 이를 위해 weather station 정보를 자동으로 얻어온다. 칼로리 소비량을 알려면 force 및 drag force를 계산해야 하고, drag force를 계산하려면 drag coefficient 따위 알아야 할 정보들이 좀 있다. 아직 자세히 살펴보지 않았다.

Map Overlay: 2개의 플러그인으로 구성되어 있다. 하나는 경로 상에 지도를 오버레이 표시해 주기 위한 것이다. 한국에서 사용 가능한 지도는 AR Terran과 Satellite 인데, 둘 다 구글맵을 사용하는 것 같다. 다른 플러그인은 activity(tracklog)를 속도나 고도 등을 색깔로 구분해서 출력해 주는 플러그인이다. 속도나 고도로 경로를 색깔별로 출력하기 위해서는 날씨 정보를 제공하는 GPS2PowerTrack이 설치되어 있어야 한다.

After Import: gps tracklog를 가져온 후 powertrack에 필요한 자료를 가져와 칼로리 소비량 따위를 계산하기 위한 작업을 자동화한다. 사실 이것 외에 뭐 다른 용도가 있는지는 잘 모르겠다. 다만 이 플러그인이 없으면 수동 작업이 무척 귀찮다는 것 뿐.

GPSBabel, GPS Correction, Elevation Correction 등은 tracklog를 가져올 때 적용되는 일종의 전처리 플러그인이라 할 수 있고 High Score, Overlay, PowerTrack, Map Overlay 등은 가져온 tracklog를 바탕으로 후처리를 하는 플러그인으로 볼 수 있다. 이들 외에도 여러 종류의 플러그인이 있는데 나머지는 귀찮아서 생략.

tracklog를 평가하기 위해, Power Track과 Map Overlay는 거의 반드시 설치해야 하는 플러그인이다. 다만 그 플러그인 제작자가 말은 도네이션웨어라고 하면서 도네이션 안하면 플러그인을 일정 기간 이상 사용 못하게 제한해 놓아 좀 귀찮다.

Map Overlay로 표시된 자전거 주행 정보. 여기 나타나는 temperature 및 tailwind, headwind는 날씨 정보에서 가져온 것이다. 이 화면 처음에 보고 확 맛이 갔다. 바로 내가 원하던 것이다.

calory 소비량을 force - drag force로 계산하는 것 같은데, force는 tracklog의 측점간 속도와 착용 장비 전체의 무게를 바탕으로 계산하고 drag force는 인체(및 자전거)의 항력계수와 날씨 정보로부터 얻을 수 있는 역풍, 순풍 등의 파라미터와 몸무게 및 장비 전체 무게 따위로 계산하는 것 같다(몸무게를 이용해 BMI 계산해주는 것은 기본). 자세한 식은 http://en.wikipedia.org/wiki/Drag_force 에서 찾으면 될 것 같은데, 위키피디어 자료에 의하면 서 있는 인체의 항력계수는 1.1, 자전거에 타서 허리를 숙인 경우 0.9 정도가 되는 것 같다. 플러그인에서 어떤 식으로 계산한 것인지 배경을 잘 몰라 좀 더 찾아봐야 정확한 칼로리 계산이 가능할 것 같다.

놀란 것은 한국의 날씨 정보 사이트에서는 볼 수 없었던 종류의 정보를 한국에 설치된 weather station을 이용해 그 자료를 축적해 둔 외국 사이트에서 확인했다는 점이다.

GPS2PowerPack 플러그인 화면의 weather stations 트랙로그에 의해 자동 검색된 weather statins들.

weather station중 하나를 클릭해 들어간 웹사이트에 나타난 날씨 정보. 시간별로 온도, 습도, 풍향및 풍속, 해수면기준 기압, 심지어 가시도까지 나타난다. 이들 데이터는 수개월~수년 동안 해당 사이트에 보전되어 있는 것 같다.

OSM 작업노트 #4: POI

GPS 2009. 3. 27. 16:31

OSM 컨테스트에서 격찬을 받은 Open Cycle Map 은 등고선 지도와 자전거 경로를 결합한 아이디어가 꽤 훌륭하다. 그래! 바로 이거다 싶을 정도다. 다음이나 네이버에서 지도를 가지고 개최 하는 사용자 매시업 프로젝트들처럼... 음... 시시껄렁하지 않다. 또는 google mymaps처럼 바보스러워 보이지도 않는다.

OSM의 구현에서 엿보이는 simplicity는 무척 마음에 든다. 그래서 누가 이런 좋은 것을 만들었는지 뒤져봤다.

OSM의 공동 창업자(?) 중에 한 사람인 영국인 Nick Black 은 GIS 학과 졸업생 출신으로 복잡한 데이터 포맷과 족같이 비싼 GIS 소프트웨어 및 지도에 충격을 받고 2004년 오픈 스트릿 맵 프로젝트를 시작했다. 영국이나 한국이나 GIS 정보를 공공재로써 정부 차원에서 무상 공급하지 않는 사정은 매한가지인 것 같아 동병상련의 감정을 느낀다. 그리고 그들이 OSM 사이트를 만들고 5년이 지났다. 매트릭스화 된 영국 및 유럽과 달리 한국은 여전히 황량한 깡촌으로 남아 있다.

도로 작업과 POI 작업을 여러 번 했는데, OSM 작업이 제대로 반영되었는지 알기가 힘들다. OSM의 slippery map은 OSM database에서 데이터를 가공해 map tile을 만드는데 시간이 많이 걸리는 작업이다. 그래서 cloud computing 또는 clustering 등을 사용하여 tile을 분산 랜더링하는 프로젝트가 진행 중인 모양이다. 한국의 좋은 인터넷 인프라 사정을 감안하면 기회가 닿는대로 참여해야지 싶은데, 아직은 그것 말고도 할 일이 많으니 일단 보류.

하여튼 slippery map에 사용할 tile을 리얼타임으로 업데이트하는 실험적인 Tile Server 가 있다.

---

대전과 안동 지역 지도 작업을 누가 했는지 궁금했는데, 한국에 살고 있는 미국인 로버트씨가 70% 이상의 작업을 했단다. 그외 OSM 작업하는 한국인들은 여전히 거의 없는 실정. 로버트씨와 도로 분류 및 한글 로마자화에 관한 이메일을 몇 번 주고 받으며 토의했다. 한국 지도 만드는데 한국인은 없어서 외국인과 지도를 어떻게 만들지 토론 한다는 게 다소 희안하달까?

로마자화(로마음소화가 맞겠지) 보다 마음에 걸리는 문제는 한글-영문 변환이다. 경동초등학교-> Gyeongdong primary school은 쉬운 편이지만, '서원유통할인마트용호초등학교'는 어떻게 변환해야 할 지 감도 안 잡힌다. 자연어 처리는 매우 어려운 문제다. 일단 제끼고 단순 단어 규칙을 사용하여 변환하는데 촛점을 맞췄다. 따라서 결과가 경우에 따라 매우 한심할 수도 있다.

이전에 업로드한 POI를 대폭 수정하기 위한 작업을 벌였다. 이때 로버트씨와의 토론에서 얻은 몇 가지 정보를 반영했다. 명칭 태그는 3개로 나뉜다. name, name:en, name:ko_rm. 작업을 위해 OSM XAPI 를 사용했다.

노드 중 내가 작업한 것들'만' 가져오는 방법은 아래와 같다.

http://www.informationfreeway.org/api/0.5/node[osm:user=xbbx][bbox=125.3,33,129.8,38.7]

planet.osm 파일에서 직접 뜯어오려면 osmosis를 사용한다. 예.

osmosis --read-xml planet.osm --way-key-value keyValueList="railway.tram,railway.tram_stop" --used-node --write-xml city_tram.xml

---

강원도 주요 지방도를 끝냈다. 서울은 누군가 하겠지, 관심 없고, 주로 전라도, 강원도 등의 아무도 할 것 같지 않은 지역을 위주로 작업할 것이다. 지금은 도로 작업을 잠시 접고, 저번 한 주 동안 POI 수집에 열을 올렸다. 거의 일주일이 걸린 '프로젝트'가 되었다.

POI를 OSM에 업로드 하기 위해서는 갖은 작업이 필요하다.

명칭 수집

POI 수집 작업의 요점은 저작권 따위의 재산권을 침해하지 않으면서 자료를 모으는 것이다. 수집 작업은, 예를 들어, 초등학교 리스트를 얻어 초등학교의 좌표를 얻어오는 과정을 자동화하는 것이다. 초등학교 리스트를 네이버 검색 엔진에서 찾아온 1차 검색 결과를 그대로 사용하면 안된다. 왜냐하면 검색 결과의 소유권이 구글이나 네이버에 있기 때문이다.

구글이 web robot를 사용해서 웹 사이트를 수집하듯이 아주 갖은 지랄을 다 한 끝에 온갖 사이트를 검색하여 법적 하자가 없을 것으로 추측되는 9만 여개의 고유 명칭을 얻었다. 이 작업이 거의 7일 걸렸다.

POI 좌표 얻어오기

그리고 yahoo poi api는(한국 야후 만세!) 하루 5만건으로 제한하긴 했지만, 고유명칭을 알고 있으면 WGS84 좌표를 얻을 수 있다. 다만 야후에서 POI 검색으로 얻은 결과에 '야후에서 얻었음'이란 말을 달기만 하면 된다. 그러고보니 소프트웨어를 무료 공개해 인류 공영에 이바지 한다는 구글을 통해서는 뭐 하나 얻은게 없는데(얻으려 애썼지만 성과가 '0'이다) 야후는 구글처럼 떠벌리지도 않으면서 인류 공영에 이바지 하고 있다는 생각이 든다.

OSM 지도 그리기에 크나큰 도움을 주는 slippery map을 야후에서 제공하고 POI 검색도 야후에서 제공한다. 명칭 수집과 병렬로 진행된 이 작업은 5일이 걸렸다.

OSM HTTP Protocol

먼저 HTTP를 사용하여 OSM server와 통신하기 위한 프로토콜 스펙 을 알아야 한다.

UTF-8 코드 변환

Unicode로 작업했으면 했지, UTF-8은 나하고는 거리가 먼 포맷이었다. UTF-8 스펙과 정의에 관해서는 웹 페이지 여기저기에 워낙 자료가 많으니 생략하고, 핵심을 간단히 정리하자면,

UTF-8은 파일 및 web 전송때 한시적을 사용한다고 생각해야 할 포맷이다.
Unicode는 프로그램에서 사용하는 포맷이다. 즉 UTF-8이건 나발이건 내부적으로 처리할 땐 무조건 unicode로 변환해야 편하다.

win32에서는 파일을 열 때(만들 때가 아님) UTF-8 파일임을 지정해 줘야 한다. (unicode도 지정해야 하나?) unicode 텍스트 파일의 경우 BOM(Byte Order Marker)를 파일의 첫 두 바이트에서 읽어 처리하기 때문에 별다른 처리를 하지 않지만 UTF-8 텍스트 파일은 UTF-8 플랙을 지정하지 않으면 영어를 제외한 언어 코드를 처리할 수 없다.

_wfopen_s(&f, filename, L"rt,ccs=UTF-8")
fopen_s(&f, filename, "rt,ccs=UTF-8")

파일에서 문자열을 읽어올 때, vs.net에서 unicode 빌드의 경우 wchar_t로 변환되고, mbcs 빌드의 경우 char로 변환된다.

UTF-8은 ASCII 파일과 실질적으로 같기 때문에(7bit가 high일 경우 코드 페이지에 따라 3~4bytes로 해당 언어가 변행된다), 읽은 문자열을 파일로 저장하거나, 웹으로 전송할 때는 내부처리 포맷인 16bit(linux는 32bit인 것 같음) unicode를 UTF-8로 변환한 후 저장해야 한다. 관련 함수는,

WideCharToMultiByte(CP_UTF8, ...)

파일이 아닌(파일을 읽을 때 자동으로 변환해 주는 것이 아닌) UTF-8 코드는 아래의 함수로 변환할 수 있다.

MultiByteToWideChar(CP_UTF8, ...)

XML 처리

XML 포맷으로 저장되는 OSM 파일은 워낙 크기가 크기 때문에(planet은 6.4GB) MSXML이나 tinyXML 등의 DOM형 파서에서 처리할 때 메모리를 엄청나게 소비한다. 따라서 MSXML SAX2, MS XmlLite, Expat Libray 등의 stream XML parser를 사용하는 것이 바람직하다. (사실 MS XML library는 개인적으로 사용하지 않는다. 주로 tinyXML과 expat만 사용한다)

MSXML SAX2는 C/C++에서 사용하기가 귀찮고, xmllite는 platform SDK를 설치해야 하고 portabillity도 높지 않다. 역시 expat library가 가장 낫다.

좌표 변환도 공부했다. 일단 카 내비게이션 소프트웨어에서 자료를 얻을 수 있을 거라고 막연히 추측했기 때문인데 그리 도움은 되지 않았다. 하여튼 한국에서 사용하는 좌표계는 Bessel TM, Bessel TM128 (Katech), WGS84 등이다. 이중 TM128은 자동차 내비게이션에서 자주 사용하는 1점 좌표계인 듯. OSM은 WGS84를 지원한다. TM128을 WGS84 좌표로 변환하는 소스는 http://www.gisdeveloper.co.kr/337 에서 구할 수 있었다.

남은 작업

이런 과정을 거쳐 몇 가지 프로그램을 작성해서 POI를 수집하고 OSM 태그 붙이기를 자동화하고 OSM 파일로 변환하고 OSM Server에 POI를 올린다는 것이 시나리오다. 이들 자료는 나중 관리 목적으로 별도의 태그를 하나 더 붙일 예정이다.

OSM 작업노트 #3: GPS용 IMG 만들기

GPS 2009. 3. 18. 19:51

OSM 파일로부터 IMG를 만드는 다양한 방법이 있다. 이중 해볼만한 방법들을 나열해 보면,

1. Planet.osm Dump 파일에서 한반도만 뜯어오기
2. 이미 만들어진 한반도 osm 파일 얻기
3. database에서 직접 osm 추출하기
4. Garmin GPS용으로 이미 만들어진 한반도 img을 사용하기.

1,2,4항은 일주일에 한 번 업데이트 된다. 보통 매주 수요일 UTC+1에 업데이트 되는 것 같다. 이중 1항은 시간이 워낙 오래 걸리고 작업량도 많아 그다지 추천할만한 방법이 아니다. 3항은 일주일 동안 기다리기 뭣할 때 사용할만한 방법이나, 한반도를 정확하게 추출하는 것이 아니고 시간도 꽤 걸리는 편이라 지도 작업 중 지도 변경 내용이 반영되었는지 한시라도 빨리 확인해 볼 때나, 최신 업데이트 자료가 필요할 때 사용할 방법이다. 4항이 가장 쉽지만 4항은 만들어진 img 파일의 세부 내용을 수정할 방법이 없다. 예를 들어 routable map을 만든다던가...

1. Planet.osm Dump 파일에서 한반도만 뜯어오기

매주 수요일 오전 1시에 planet.osm을 덤프한다. 여기에 매일/매시간 단위로 diff 파일이 생성된다. 자료는 아래 url에서 구할 수 있다.

http://planet.openstreetmap.org/

OSM 사이트는 속도가 느리므로 mirror site에서 직접 다운 받는 것이 시간을 절약하는데 도움이 된다.

http://ftp.snt.utwente.nl/pub/misc/openstreetmap/planet-latest.osm.bz2
ftp://ftp.heanet.ie/mirrors/openstreetmap.org/planet-latest.osm.bz2
http://ftp.heanet.ie/mirrors/openstreetmap.org/planet-latest.osm.bz2
http://planet.king-nerd.com/planet-090311.osm.bz2
http://planet.openstreetmap.org/planet-latest.osm.bz2

이중 ftp.snt.utwente.nl 사이트가 가장 빠른데, 그래도 5.4GB(2009-3-18일 기존) 짜리 파일을 다운 받으려면 무려 2시간이 넘게 걸린다. 하여튼 이렇게 다운받은 planet 파일에서 한반도 부분만 따내야 한다. 이때 사용하는 프로그램이 Osmosis이다.

일단, 한반도를 따내기 위해서는 polygon filter file이 필요하다. polygon filter file format 정보는 아래 url에서 구할 수 있다.

http://wiki.openstreetmap.org/wiki/Osmosis/Polygon_Filter_File_Format

이미 작업되어 있는 파일이 있으므로 굳이 필터 파일을 만들 필요는 없다. 남한 필터 파일('south_korea2pts.txt')은 아래 url에서 구할 수 있다.

http://www.maproom.psu.edu/dcw/
http://www.maproom.psu.edu/cgi-bin/dcw/dcwarea.cgi?Asia

planet.osm 파일에서 한반도를 뜯어오려면 컴퓨터에 다음 프로그램들이 설치되어 있어야 한다.

* Java Run Time http://www.sun.com
* Osmosis http://wiki.openstreetmap.org/wiki/Osmosis

planet 파일(planet-latest.osm.bz2), 남한 필터 파일(south_korea2pts.txt), osmosis.jar 파일을 같은 디렉토리에 넣고 다음 명령을 실행하면 korea.osm.bz2 파일이 생성된다.

java -Xmx1048m -jar osmosis.jar --read-xml enableDateParsing=no file=planet-latest.osm.bz2 --write-xml korea.osm.bz2 --bounding-polygon file="south_korea2pts.txt"

또는,

bzcat planet-latest.osm.bz2 | java -Xmx1048m -jar osmosis.jar --read-xml enableDateParsing=no file="-" --write-xml korea.osm.bz2 --bounding-polygon file="south_korea2pts.txt"

DateParsing을 하지 않으면 속도가 좀 빨라진다. osmosis에서 bz2를 프로세싱하는 것보다 bzcat을 하는 것이 속도가 빠르다. bz2 파일을 풀어놓고 작업하면 속도가 빠르다. 다만 파일 크기가 워낙 커서 디스크 공간을 많이 차지한다.

2. 이미 만들어져 있는 한반도 osm 파일 가져오기

planet.osm으로부터 각 국가별 파일을 만들어 다운받기 편하게 만들어놓은 사이트가 있다. 이곳 자료는 1주일마다 업데이트 된다. osm 파일 뿐만 아니라 garmin GPS용 IMG 파일도 이미 만들어 놓았다.

http://downloads.cloudmade.com/asia/south_korea#breadcrumbs
http://downloads.cloudmade.com/asia/south_korea/south_korea.osm.bz2

3. database에서 직접 osm 추출하기

데이터베이스에서 XAPI query(http://wiki.openstreetmap.org/wiki/XAPI)를 사용하여 korea.osm 파일을 생성한다. 이때는 한반도의 polygon을 지정할 수 없으므로 bounding box(사각형 박스)를 사용하여 얼추 비슷하게 만드는 수 밖에 없다. 가장 rough한 bounding box는 경위도가 다음과 같다: 125.3,129.8,33.0,38.7 이 좌표는 울릉도가 빠지고 일본의 대마도와 큐슈가 일부 포함된다.

바운딩 박스의 범위를 알고 싶을 땐 http://www.openstreetmap.org/ 의 export 메뉴에서 직접 해 보면 된다.

하나의 바운딩 박스로 한반도 전체를 가져오면 파일크기는 100MB 가량(2009-3-18 기준), 시간은 30분 가량 걸린다. 다운 받기 위해서는 web browser에서 다음과 같은 형태의 url을 타이프한다.

http://www.informationfreeway.org/api/0.5/*[bbox=125.3,33,129.8,38.7]

또는 wget utility를 사용할 수도 있다.

wget http://www.informationfreeway.org/api/0.5/*[bbox=125.3,33,129.8,38.7] -O korea.osm

바운딩 박스에 울릉도가 빠지고 일본의 대마도와 큐슈가 포함되는 걸 원치 않는다면 파일을 여러 개로 쪼개 다운받는다. 여러 개로 쪼개 병렬로 다운 받으면 속도 상의 이득이 있다(다운 받는데 약 5분).

wget http://www.informationfreeway.org/api/0.5/*[bbox=126,33,127,34] -O jeju.osm
wget http://www.informationfreeway.org/api/0.5/*[bbox=125,34,129,35] -O korea1.osm
wget http://www.informationfreeway.org/api/0.5/*[bbox=125.5,35,130,37] -O korea2.osm
wget http://www.informationfreeway.org/api/0.5/*[bbox=125.5,37,131,39] -O korea3.osm

---

1,2,3 어느 방식을 사용하든 최종적으로 한반도의 osm 파일을 얻을 수 있다. 이 파일을 Garmin GPS IMG 포맷으로 변환시키려면 GroundTruth 나 Mkgmap 을 사용한다.

GroundTruth를 사용해서 Garmin GPS용 IMG를 만들려면 cGPSMapper 프로그램이 필요하다. cGPSMapper 프로그램을 설치한 후 GroundTruth가 설치된 디렉토리에 통째로 복사해 놓는 것이 편하다. 또한 Rule 파일의 수정이 필요하다. 일단은, 영문 Garmin GPS용 한글 지도를 만들려면 설치된 디렉토리에서 Rules/DefaultRules.txt 파일에서 name 태그를 name:en으로 바꿔줘야 한다. 자세한 내용은 GroundTruth help 참조.

groundtruth는 wget 없이 database에서 osm 파일을 직접 생성할 수도 있다.

groundtruth getdata -b 33,125.3,38,129.8 -o korea.osm

생성된 OSM 파일을 이용해 IMG 파일을 만든다. 자세한 옵션은 groundtruth help를 참조.

groundtruth --osmfiles=jeju.osm,korea1.osm,korea2.osm,korea3.osm --mapid=33361200 --mapname="Korea OSM Map" --fc=200 --productcode=200 --productname="Korea OSM Map"

mkgmap을 사용하면 아래와 같이 타이프한다. 자세한 옵션은 mkgmap help를 참조.

java -Xmx512M -jar mkgmap.jar --mapname="33361200" --description="Korea OSM Map" --country-name="Korea" --country-abbr="KOR" --transparent --name-tag-list=name:en,name:ko_rm,name jeju.osm korea1.osm korea2.osm korea3.osm

이렇게 해서 생성된 *.IMG 파일을 MapsetToolkit과 Sendmap 프로그램을 이용해 Garmin Mapsource와 Garmin GPS용 파일을 만든다.

최종 결과물은?

어느 분이 도로 작업을 끝내 놓은 대전시를 Garmin MapSource에서 본 것.

대전의 확대 부분

감동적인 결과물. 이 맛에 작업한다.

OSM 작업노트 #2: 도로, 명명규칙, POI 확보

GPS 2009. 3. 16. 20:07

도로에서 motorway는 고속도로(번호 및 이름 지정), trunk는 고속화 도로 및 국가가 관리하는 주요 간선(지도에서 보통 도로 번호가 동그라미 안에 표기된다. 이름이 있을 수도 있고 없을 수도 있다), primary는 지방이 관리하는 지방도(지도에서 도로 번호가 네모 안에 표기된다. 구간에 따라 특정한 이름을 가질 수 있다), secondary 및 tertiary는 주요 도시의 내부 교통을 잇는 도로(번호는 없으나 도로 이름을 지정), resident는 골목길(역시 이름만 지정)로 하면 맞겠지 싶다.

서울에는 보통 지방도로보다 차선 수가 많은 도로가 생길 수 있다. 이들 도로는 lanes로 차선 수를 지정하는 것으로 해결해야 할 것이다. 안 그러면 조그만 중소도시의 시 내부를 연결하는 도로에 마저 trunk나 primary를 지정하게 되는데, 이들은 관리되는 주요국도, 지방도가 아니면서 실제 화면에 나타날 때는 주요 도로처럼 보이게 된다.

자전거길(cycleway)과 트래킹로/도보로(footway)는 지금 생각하기엔 사치다. 그들 관련 자료는 많다. 그것들은 적절히 편집하고 정규화한 다음 track reduce해서 일괄적으로 올리는 것이 바람직하다. 사실 cycleway와 footway 용도의 gps 자료는 신뢰성이 떨어진다. 이건 나중에 다시 언급...

한국 지도 제작에 여러 사람들이 협력하여 지도를 만들려면 한국 지도 제작 가이드가 가장 먼저 필요하지만 글쎄다... 일단 OSM 명명 규칙에 관해 기존 OSM 다큐멘테이션을 참조해 주요 요소에 대한 대략의 정보를 정리했다. 때가 되면 편집해서 올릴 것이지만(더 좋은 것은 누군가 편집해서 가이드라인을 올릴 때까지 기다리는 것이지만) 내가 아직 POI 관련 작업을 본격적으로 시작한 것은 아니다.

지도 제작을 해 보니 딱 이 말이 떠오른다. "안 해봤으면 말을 하지마." 고민해야 할 것들이 꽤 많다. 이전 아마추어 지도 제작자들은 그런 고민을 해봤다. 따라서 지도 제작을 하려면 먼저 선구자들로부터 배워야 한다. 아니면 '안 해봤으면 말을 하지 마' 류의 온갖 시행착오를 다 겪어 보던가.

대표적인 예: 이전 POI 작업할 때 이름 때문에 고민했는데 작업 전에 일본쪽 자료를 참조했더라면 도움이 되었을 뻔 했다. 일본 역시 로마자 표기 문제로 name 태그를 여러 개로 분할했다.

name:korean (english)
name:en=english
name:ko=korean
name:ko_rm=korean romanization

예:

name=상명여대 (Sangmyong Women's University)
name:en=Sangmyong Women's University
name:ko=상명여대
name:ko_rm=Sang-myong-yeo-dae

이미 올라가버린 이름을 어떻게 할 수는 없고, 나중에 OSM 자료를 통째로 다운받아 이름을 rewrite하는 자동화 프로그램을 짜야할 것 같다. 4월 이후에 OSM protocol 0.7(0.6이던가?)로 교체되면 그때 가서 천천히 생각해봐도 늦지 않다.

작업 중에 영문 이름을 병기하려면 작업 시간이 많이 걸리므로 일단은 한글 이름만 입력하는 편이 낫겠다. 먼저 한글 이름 입력 후 나중에, 정기적/부정기적으로 일괄 수정.

POI는 여전히 심각한 문제다. 간단한 데이터라면 입력이 가능하지만 별다른 뾰족한 방법이 떠오르지 않는다. 그렇다고 상용맵을 해킹할 수는 없다. 일단 이렇게 생각하기로 했다.

서울시가 wikipedia에 서울의 여러 지역을 설명하는 프로젝트를 진행한다고 했으니 서울의 POI는 시간날 때 서울시에 제안 메일을 보낼 생각이다. http://oasis.seoul.go.kr

서울시와 마찬가지로 다음 공공기관과 연락해 본다.

한국관광공사
국립공원관리공단
각 시도 지자체

이들 공공기관/단체는 가지고 있는 POI를 공개하거나, 심지어 해당 관청이 공무원을 동원해 openstreetmap에서 직접 작업할 명분이 있다. 관광안내 팜플렛 수십만부 찍어 외국에 뿌리는 것보다 더 효과적인 대외 관광 산업 지원 및 활성화라는... 4월쯤에 메일을 보내 한글 명칭, 가능하면 영어 명칭, 경위도 정보 정도만이라도 보내주면 내가 작업해서 올려 주겠다고 설득해 봐야겠다.

국립지리원은 세금 걷어 지도 그려서 그것을 국민에게 돈 받고 팔아먹는 희안한 기관으로 보여 컨택을 해야 하나 망설이게 된다. 그래도 (내가 잘못 알고 있을 수 있으니) 시도는 해 봐야겠지?

몇몇 학과 학생들은 GIS 자료를 다룬다. 학교의 교수님들을 통해 과제나 프로젝트로 openstreetmap을 하라고 설득하는 것도 의미있다. 그들이 가지고 있음직한 공개되지 않은 엄청난 양의 자료를 OSM에 올릴 수만 있다면...

OSM Korea Mapping project에 wiki page를 등록한 사람은 2009년 3월 16일 현재 6명 뿐이다. http://wiki.openstreetmap.org/wiki/Category:Users_in_Korea 참여를 독려할 마땅한 방법도 없고, 여기 저기 OSM을 선전하기가 실은 귀찮다.

싫증날 때까지만이라도, 하다보면 머리가 멍해지는 도로나 계속 그리자. 이것들은 향후 아무짝에도 쓸모없는 삽질로 밝혀질 가능성이 아주 높다. 그러나 내 인생의 한 때에 공공의 복리를 위해 삽질한 적이 있다는 시시한 자긍심은 남게 될 것이다.

OSM 작업노트 #1: Tool

GPS 2009. 3. 10. 20:40

Potlatch 0.10f 버전은 작업 중 실시간으로 OSM 자료를 가져오므로 conflict가 발생할 가능성이 적다. 반면, JOSM은 한 페이지를 에디트할 때 이전 데이터를 로드해두지 않으면 작업 내용이 충돌할 수도 있다.

potlatch가 비교적 쉽게 작업할 수 있는 반면, 잘못 작업하고 나서 할 수 있는 일이 undo밖에 없어 다른 사람이나 다른 시간에 작업하고 수정하거나 삭제하기가 어렵다. JOSM은 그런 문제가 없다.

potlatch에서는 gpx로 작업할 수 없다. 오직 path(track)을 upload하기만 가능하다. JOSM은 GPX를 레이어로 깔고 새로 라인을 그리는 것이 가능하다. JOSM의 단점은 메모리를 많이 먹는다는 것. 그리고 데이터베이스 접근 속도가 아주 느려서 서울 버스 정류장 약 24000여개의 데이터를 업로드하는데 무려 하루가 걸렸다. OSM의 데이터베이스 엑세스가 느린 탓일까?

일단의 이유로 고속도로를 그리는 작업에서는 potlatch를 사용하고, POI를 입력하거나 잘못된 정보를 수정할 땐 JOSM을 사용했다. merkaartor는 버그가 여럿이지만 JOSM 보다는 빠르다. 안정화되면 JOSM에서 메르카토르로 전환해야 겠다.

네이버 항공사진과, potlatch 또는 JOSM이 사용하는 야후 항공사진은 같은 자료다. 현재로써는 대조작업용 맵으로 다음 맵+항공 사진 오버레이가 국내에서 구할 수 있는 지도 중 가장 좋다. 네이버 맵에는 이상한 버그가 있어 대조 작업 중 가끔 브라우저에서 마우스 휠 버튼이 작동하지 않는 현상이 있다.

OSM이 사용하는 데이터베이스는 postgres를 변형한 postGIS이다. GIS 정보를 다루는데 특화되어 있다. 날이 갈수록 눈에 띄게 데이터베이스 접근이 느려진다.

앞으로 시간을 들여서 할 일은 osm 데이터를 직접 패치해 오는 것(과 이것을 로컬 db에 저장해서 지도를 빠른 속도로 수정 하기). 그리고 그 자료를 Garmin IMG 포맷으로 바로 변환한 후 한국 지형도와 합치는 작업을 자동화하는 것이다. OSM Composer라는 프로그램이 이들 작업을 자동화해주는데 DEM 파일 처리할 때 메모리를 엄청나게 사용하며 다운되기 일쑤였다.

지금은 작업에 참고할 지표를 만드는 중이고, 본격적으로 작업이 시작되면... 내가 가고 싶은 곳이나 흥미가 당기는 곳을 주로 하기로.

Open Street Map

GPS 2009. 2. 26. 20:07

이전 독립 GPS의 활용에서 만든 지형도(등고선 지도)에는 도로와 POI가 포함되어 있지 않다. 등고선 지도에 Open Street Map 지도를 합치면 GPS에 도로와 POI를 사용할 수 있다.

OSM(Open Street Map)은 전세계적인 도로 지도 제작 프로젝트다. 얼마전에 google에서도 google map maker를 만들어 사용자 참여로 구글 맵에 누락되거나 업데이트 되는 지도를 만들 수 있는 방법을 제공하기 시작했다. google map maker의 단점은, 사용자가 만들어 놓은 지도 데이터의 소유권이 구글에 귀속되며, 사실상 맵을 만들어서 구글맵 사용자 사이에 공유하는 것 외에 달리 써먹을 데가 없고 아직 GPS에서 사용할 도구가 없다.

OSM은 구글 맵 메이커에 비해 사용이 비교적 자유롭다. 여기서 만들어진 지도를 바탕으로 여러 가지 파생 프로젝트가 생겨났으며, 그중 대표적인 것이 GPS 디바이스에서 사용하는 도로 지도를 만드는 OSM Map On Garmin이다.

OSM에서 만든 자료를 변환해 routable map과 POI(point of interest) 데이터 베이스를 구축하고 이것을 Garmin GPS에서 업로드 해 사용할 수 있다. Garmin의 .img 포맷이 알려져 있고 OSM Tile file database access가 자유롭기 때문에 가능한 일이다.

Cloudmade에서 매주 업데이트 하는 국가별 지도 파일을 다운받을 수 있다. 다운 받은 파일을 GPS에 업로드하면 바로 사용 가능하다. 이중 한국의 서울과 일본의 도쿄를 비교:

아직은 한국 사용자들의 참여가 적어 한국 지도가 질적/양적인 면에서 다른 국가에 비해 상대적으로 어설프고 부족하다.

cloudmade의 자료는 이미 만들어진 파일이라 분리 후 다시 통합하기 어려우므로, computerteddy에 의해 매주 업데이트 되는 전 세계 지도 중 필요한 부분을 다운 받아 작업해야 한다.

전체 파일인 worlds.tgz의 압축된 용량은 1.42GB에 달하므로(압축 해제한 *.img 파일의 총 크기는 3.4GB) 별개 이미지로 나누어진 다운로드 디렉토리에서 필요한 파일만 다운받는 것이 시간을 절약할 수 있다. 이때, OSM 자료를 tile 별로 업데이트한 것이라(자세한 내용은 OSM 사이트 참조), 한국에 해당하는 타일을 가져오려면 위치에 해당하는 타일 파일명을 알아야 한다. Convert Coordinates to OSM Tile Numbers 참조.

울릉도를 제외한 대략의 타일 파일 이름은 다음과 같다.

63295024.img 63295025.img 63295026.img 63295027.img 63295028.img 63295029.img
63295204.img 63295205.img 63295206.img 63295207.img 63295208.img 63295209.img
63295384.img 63295385.img 63295386.img 63295387.img 63295388.img 63295389.img
63295564.img 63295565.img 63295566.img 63295567.img 63295568.img 63295569.img
63295744.img 63295745.img 63295746.img 63295747.img 63295748.img 63295749.img

이들 .img 파일을 sendmap 프로그램을 이용해 Korea topo 맵의 .img 파일과 합쳐 단일 gmapsupp.img를 만든다.

GPS에서 POI를 보면 OSM에서 한글 이름으로 만든 것은 글자가 깨져서 나온다. OSM에서 '영문이름(한글이름)' 식으로 입력하면 이런 문제가 사라진다. 두번째 화면에서는 지형도와 도로 지도가 함께 나타난다. 도로 지도만 나타날 뿐, routable map을 만드려면 computerteddy가 고맙게 올려주는 파일들로는 안되고, OSM 지도를 사용하는 다른 사람들처럼 별도의 작업을 벌여야 한다. 시간이 좀 나면 공부해서 만드는 방법을 좀 배워야 할텐데...

OSM 프로젝트는 Wikipedia 프로젝트와 흡사하므로, 계정을 만들면 누구나 도로 지도를 그려 올릴 수 있다. Potlatch는 web + flash로 온라인에서 작업하는 도구, JOSM, Merkaartor 등은 오프라인에서 작업할 때 주로 사용하는 툴이다. 작업 규칙과 방법에 관해서는 한국 사용자 모임 참조.

편집은 보통 자신의 GPS에 기록된 tracklog와 waypoint를 업로드한 후, 그 자료를 바탕으로 도로를 그리는 방법과, potlatch 같은 경우 web 상에서 yahoo map이 오버레이 된 상태에서 도로를 따라 그리며 작업하는 방법, JOSM 등의 프로그램에서는 지도 오버레이용 플러그인을 설치하여(예를 들면 google map plugin) 지도를 오버레이 한 상태에서 도로를 그리는 방법 등이 있다.

OSM 지도는 1주 마다 업데이트 되므로(아직 한국 지도는 거의 업데이트 되는게 없지만) 매번 지도 이미지 파일을 받기는 번거러워 GNU Tool 중 win32용 wget을 사용해(linux 배포본에는 보통 기본적으로 포함되는 유틸리티) 이들을 한꺼번에 받는 스크립트를 사용하면 작업이 덜 번거러워진다.

invalid-file

아울러 이렇게 만든 파일은 Garmin MapSource에서 도로를 볼 수 있는 상태가 아니므로 MapsetToolkit을 사용해 *.TDB 파일을 만들어줘야 한다. MapsetToolkit 사용법은 GPS 한국 지형도 만들기 참조.

Garmin MapSource에서 topo map과 함께 본 모습

독립 GPS의 활용

GPS 2009. 2. 20. 19:51

1. 서론

한국에는 전용(독립/단독) GPS 사용자가 많지 않다. 많이 늘었으면 좋겠다는 심정으로 이 글을 쓴다. 독립 GPS 사용자 대다수는 산악 트래킹 중 경로 파악을 위해 사용하고 최근의 자전거 붐으로 자전거 속도계 대신 다양한 기능을 할 수 있는 GPS를 사용하는 사람들이 조금씩 늘어가는 추세다. 일부는 조깅 중에 활용. 하지만 한국에서 판매되는 전용 GPS의 가격이 워낙 비싼데다 PDA나 PMP, 휴대폰 등에 GPS 칩이 탑재되는 일이 점차 일반화 되면서 전용 GPS 사용이 한국에서 쉽게 보편화될 것 같지는 않다. 오히려 점차 사라지지 않을까?

자전거에 Garmin Vista HCx를 마운팅한 모습. 사람들이 물으면 GPS라고 말하기 귀찮아서 속도계라고 대답하지만 :)

한글판 전용 GPS를 취급하는 Garmin 한국 공식 대리점(http://www.garmin.co.kr)에서 판매하는 기기는 Garmin 60CSx의 경우 100만원, 콜로라도 300의 경우 110만원 가량 한다. 이들은 한국 지형도와 도로 지도를 모두 포함하고 있다 -- 2009년 2월 20일 기준.

GPS 내비게이션이 가능한 PDA, PMP류는 20-30만원이면 구할 수 있으니, 굳이 전용 GPS를 구매할 사람이 있을까?

물론 있다. 전용 GPS는 시중에서 흔히 구할 수 있는 AA 전지 2개로 약 12시간에서 18시간 가량 사용할 수 있다. water proof가 되고, 기기 자체가 매우 튼튼하다. 애당초 전용 GPS를 사용하는 목적이 레크레이션 활동, 즉, 트래킹, 바이크 라이딩, 패러 글라이딩 따위에 주로 활용되기에 그런 방면의 요구 조건에 부합하는 성능과 특성을 갖추고 제작되었다. 별도의 전원 공급 없이는 길어봤자 4-5시간 사용 가능한 내비게이션 PDA, PMP와 달리 장시간 산악에서(때때로 목숨이 오락가락하는 상황에서) 신뢰성있는 작동을 보장해야 하기 때문이다.

GPS를 사용하면 레크레이션 활동이 좀 더 흥미로워 진다.

track, trackback: waypoint, route, 기록된 track을 통해 왔던 길을 되돌아 가거나 특정 지점으로 내비게이션. 최근 gps들은 track data를 일자별로 자동 저장한다. 2GB SD 카드 정도면 수 년 이상의 track data를 저장할 수 있다. 즉, 장기간 여행을 할 때 그 궤적 전부가 기록된다. 일 평균 기록량은 300-500kbytes.
feedback: GPS의 가장 일반적인 사용 용도. 고도 변화, 구간별 속도 변화, 평균 속도, google earth, google map 따위를 통해 이동 경로 파악 등등. 그래서 조깅 등의 운동에서 bio feedback 자료로 사용할 수 있다.
wikiloc.com : 전 세계 도시를 비롯하여, 온갖 산간 오지를 헤메며 그야말로 피땀(?) 흘리며 자전거 끌고 산길을 걸어 만든 온갖 트랙 데이터와 POI(point of interest)가 올라와 있다.
openstreetmap.org : 사용자 참여로 전세계의 routable map 제작 프로젝트가 벌어지고 있다. 예를 들어 후쿠오카에서 도쿄까지 자전거 여행을 하고 싶을 때 오픈 스트릿 맵의 일본 지도를 다운받아 GPS에 심어넣고 사용할 수 있다. wikiloc과 다른 점은, track이 아니라 routable map이란 점.
geocaching.com : gps를 이용한 세계적인 보물 찾기 사이트. 주말에 할 일 없을 때 시간 보내기 좋다.
geocoding: GPS와 카메라의 EXIF 정보를 연결하여 사진을 찍은 위치를 기록하는 것. panoramio.com 과 연결되어 google earth를 통해 보는 대부분의 사진들을 자동화.

내 경우 배낭 여행하다가 GPS 때문에 몇 차례 목숨을 구한 적이 있다. 한번은 이란 북동부 알리 사드르 동굴에 일본인과 동행 했다가 사막에서 눈보라 맞고 길을 잃어 버렸을 때, 이집트의 사막에 무작정 나갔다가 도무지 끝도 없이 막막한 사막을 걸어서 돌아올 때, 과떼말라 빠까야 화산에서 갑자기 들이닥친 비바람이 분화구에서 쏟아져 내려 거대한 수증기 기둥을 만들어 길을 찾을 수 없게 되었을 때. 그때 gps가 없었더라면... 흠.

몇 년 전에는 파타고니아 오지를 오직 GPS와 식량만 들고 탐험한 두 여행자가 화제를 모은 적이 있다. 인디아의 엄청 복잡한 바라나시 골목에서 소떼들에게 쫓기며 헤메는 것이나, 지도에도 없는 파키스탄 북부 산악 지대를 여행하거나, 울란바토르에서 몽골 북서부 러시아 접경 지역에 이르는 광대한 초원의 길없는 길을 말 타고 돌아다니는 여행자에게 GPS는 상당히 매력적인 가능성을 열어준다. 아니, 실제로 GPS 들고 그렇게들 여행한다.

돈 들인 오지 탐험 같은 경우엔(예를 들어 공룡 뼈를 주우러 고비 사막에 간다던지... 요즘 트리케라톱스 뼈다귀가 20억원이나 한다던데... ) GPS는 기본이고, 도요타 랜드로버에 태양전지와 Inmarset BGAN 단말기를 싣고 다니며 오지에서 위성 인터넷을 한다. 분당 14$이란 천문학적인 액수가 문제이긴 하다. 인마세트는 최근에 F3 위성을 런칭하면서 속도는 물론, 커버리지가 넓어진 듯.

독립 GPS 활용에 관해서는 http://cafe.daum.net/GPSGIS (다음 GPSGIS 동호회)를 참조하는게 도움이 된다.

삶을 좀 더 편하게 해 주는 게시물의 위치: http://cafe323.daum.net/_c21_/bbs_read?grpid=KSj8&fldid=Lrtt&datanum=396

2. 한국 지형도

routable map과 topo map이 포함되어 있다고는 하지만, 무려 100만원에 가까운 기기를 장만해서 사용하기엔 손이 떨린다. 한국 가민사에서 판매하는 같은 기계를 ebay에서는 약 300$(환율 1500원/$ 환산 약 45만원) 수준에서 구할 수 있다. 그보다 저렴한 Garmin Vista HCx 같은 것은 약 220$(33만원 가량)에 구입할 수 있다. 작년 환율 오르기 전에 구입해서 무척 흐뭇하다. 뭐 일단은 가민 계열에서는 획기적인 인터페이스의 콜로라도 시리즈가 대세다. 백만원짜리 사기 뭣하다면 적어도 지형도만이라도 갖춰보자.

다음의 GPSGIS 동호회를 비롯하여, 이미 여러 사람들의 노력이 더해져 DEM(digital Elevation Model)을 이용한 한국 지형도를 만드는 방법이 공개되어 있다. 지형도 만드는 방법은 웹을 뒤져 보던가, 아래를 참조.

GPS용 한국 지형도 만들기
한국 지형도 데이터

만드는 과정이 복잡하고 시간이 많이 걸린다. 만들어진 데이터를 windows live 공개 웹 하드에 올려뒀다.

http://cid-c828054758ad855f.skydrive.live.com/self.aspx/.Public/KTM/KoreaTopo10m.part1.rar
http://cid-c828054758ad855f.skydrive.live.com/self.aspx/.Public/KTM/KoreaTopo10m.part2.rar
http://cid-c828054758ad855f.skydrive.live.com/self.aspx/.Public/KTM/KoreaTopo10m.part3.rar

위 파일은 Garmin GPS용이다. 주의: 이 자료는 NASA의 위성에서 찍은 DEM 파일을 이용해 작업한 것인데, 실제 등고선의 해상도는 10m 급이 아니라 거의 30~50m 급에 가깝다. 따라서 등고선 정밀도가 많이 떨어진다.

이 지도로 두 가지 작업을 한다.

2.1. Garmin Mapsource에서 보기 위한 지형도

PC에 Garmin MapSource가 설치되어 있어야 한다. 설치 CD로 MapSource를 설치한다. MapSource는 보통 C:/Garmin에 설치된다. 설치가 끝나면 반드시 업그레이드를 해 준다.

업그레이드를 하면 MapSource 뿐만 아니라 Trip & WayPoint Manager v4라는 이름으로 기본 지도(Base Map)가 업데이트 된다. 이 자료는 C:/Garmin/TRIPWPT4에서 확인할 수 있다.

Base Map은 일반적으로 GPS 디바이스에 설치되어 있는 세계 지도보다 상위 버전이며, 가민에서 드물게 업데이트 한다. 업데이트 될수록 검색 가능한 POI와 도로가 늘어나고 지도 자체가 정밀해 진다.

다운로드 받은 KoreaTopo10m.part1.rar를 C:/Garmin/KoreaTopo10m에 압축을 푼다. 만일 디렉토리가 다르다면, Korea Topo 10m.reg 파일의 경로를 수정해 줘야 한다. Korea Topo 10m.reg를 더블 클릭하면 설치가 끝난다.

MapSource를 실행하여 메뉴바 아래 툴바의 콤보 박스에서 Trip And Waypoint Manager V4 아래에 Korea Topo 10m가 보이면 설치가 잘 된 것이다.

2.2. GPS 디바이스에 올리는 지형도.

sendmap20.exe를 실행한 후, 화면을 참조하여 파일을 추가한다. 이때, 같은 디렉토리에 있는 TRIPWPT4.img를 사용하거나, 만일 Trip & Waypoint Manager가 업그레이드 되었다면 업그레이드된 이미지를 추가한다.

여기까지 하고 나서, 다음 세 가지 작업을 할 수 있다.

2.2.1 Upload maps to GPS

GPS가 USB에 연결되어 있다면 설정한 이미지를 모두 올린다. 이때 GPS 내부에 있는 원래 지도 이미지에 덮어쓴다(원래 지도 이미지는 지워진다).

2.2.2 Create GMAPSUPP.IMG

GPS 없이 GMAPSUPP.IMG 파일을 만든다. 이 파일은 Garmin GPS를 외장 USB Storage로 연결하여 외장 USB Strage 드라이브의 /Garmin/GMAPSUPP.IMG를 대체할 수 있다. 2.2.1은 원래 GPS에 있던 이미지를 지워버리지만, 2.2.2는 원래 이미지를 백업받고 만들어진 이미지로 대체할 수 있는 기회가 주어진다.

2.2.3 Create EXE file

sendmap20.exe과 해당 이미지를 합쳐 독립적으로 설치 가능하고 배포 가능한 실행 파일을 만든다. 설치 파일을 실행하면 2.2.1과 마찬가지로 GPS에 있던 이전 이미지를 덮어 쓴다.

3. Geocoding

디지털 카메라와 GPS를 이용해 사진에 GPS 좌표를 기록해 놓는 것을 geocoding이라 한다. 몇몇 고급카메라는 GPS를 내장하고 있다. 또, Nikon D2X처럼 인터페이스 케이블을 이용해 GPS와 연결하여 사진 찍는 시점에 바로 geocoding 되는 기기들도 있다. 하나 같이 비싸다. 소니 CS1에 딸려오는 SW도 이런 기능을 한다. 하긴 한다. CS1이란 GPS 디바이스가 좀 아니라서 문제지.

독립 GPS로도 geocoding 작업을 할 수 있게 해 주는 프로그램은 많다. google에서 geocoding으로 검색하면 꽤 여러가지가 나온다. 개중 freeware이면서 사용이 간단한 것이 GPicSync이다.

goecoding을 하려면, 또는 하기 앞서, 만일을 위해, 사진을 본격적으로 찍기 전에, gps 시간과 카메라 시간을 맞춰 놓은 다음 GPS 트랙 로그를 기록하고, 사진을 찍는 것을 추천한다.

3.1 GPicSync의 옵션 설정

Picture foler: 사진이 저장된 디렉토리를 선택한다.
GPS file: gpx 파일을 선택한다 (gpx는 gps eXchange format으로 대부분의 프로그램이 지원)

Google Earth Icons: 아이콘을 picture thumb로 선택했다면 google maps export url을 함께 사용해야 한다. export url의 thumbs 디렉토리에 그림에 해당하는 섬네일 아이콘들이 저장된다. camera icon을 선택하면 구글이 지원하는 카메라 아이콘을 사용.

Google Earth Elevation: Clamp to the ground로 지정. 나머지는 항공사진용 옵션.

Google Earth with timestamp checkbox: 체크하면 파일명에 날짜가 따라 붙는다.

Google Maps export, folder URL: 자신의 홈페이지에 사진을 저장해 놓았다면 그 홈페이지의 사진이 담긴 디렉토리를 지정한다. 조금있다가 설명할 panoramio에 geocoding할 사진을 올려놓을 용도면 안 써도 그만.

Create a log file in picture folder: 변환 과정을 로그 파일로 남긴다.

interpolation: 가능한 체크해 둔다. gps tracklog의 시간과 카메라 시간이 언제나 정확하게 일치하는 것이 아니므로 트랙로그 자료를 전후 보간 해서 비슷한 시간에 맞춘다.

backup pictures: geocoding 할 때 원본 파일을 backup 디렉토리에 보관한다. 사진이 많을 경우 속도가 현저하게 느려진다.

add geonames and geotagged: 사진에 사진을 찍은 장소의 지정학적 위치명을 함께 기록해 주는데, 외국의 경우 꽤 쓸모가 있지만 한국에서는 이름이 조금 이상하게 나온다(구글 maps의 지명을 생각하면 됨). geocoding 진행 중 좌표에 해당하는 이름을 웹을 통해 가지고 오므로 속도가 느려진다.

UTC Offset: 한국의 경우 9를 지정(GMT+9), 만일 외국에서 찍은 사진이면 해당 국가의 UTC offset을 지정해야 한다.

geocode picture only if time difference...: 좌표가 일치하지 않을 때 허용 가능한 시간 차이를 지정. dfefault인 300이면 5분 차이인데, 이 정도 시간 차이가 나도록 좌표가 일치하지 않으면 사실상 geocoding이 엉터리로 될 가능성이 높다. 만일 tracklog가 너무 커서 GPS 도구에서 tracklog reduce 작업을 했다면 300초를 초과할 수도 있다.

3.2 Geocoding 시작

Options->Local time corrections 버튼을 누른다. 매우 중요하다. 카메라를 켜서 카메라의 시간을 위에 기록하고, GPS를 켜서 GPS의 시간을 아래에 기록하고 Apply correction 버튼을 누른다. GPS 시계는 매우 정밀하지만, 카메라 시계는 내버려두면 내장시계의 정밀도에 따라 drift가 존재한다.

사진을 찍기 전에 gps 시계와 카메라 시계를 맞춰 놓았더라도 확인해 보는 것이 좋다.

Synchronise! 버튼을 누르기 전에 원본 디렉토리를 통째로 백업해두는 것이 바람직하다. option 설정에서 backup pictures를 체크해 둬도 되나, 전자가 속도가 빠르다.

Synchronise! 버튼을 누르면 geocoding을 시작한다. 보시다시피 time difference는 10초 이내이고, 이 정도가 정상이다.

변환이 끝나면 Google Earth button을 눌러 사진을 확인해 볼 수 있다. 단, 이 때 Google Maps export가 체크되어 있고 url이 지정되어 있다면 사진을 참조하는 장소는 홈페이지의 사진이 담긴 디렉토리가 된다. 체크되어 있지 않으면 로컬 HDD 파일을 보여준다. 전자가 blog 따위에 자신의 이동경로와 사진을 함께 올리기에 편하다. 후자는 google earth를 통해 사회에 공여(?)하는 것이다. 용도에 따라 전자, 후자, 전/후자를 선택하면 되겠다.

3.3 Panoramio

geocoding된 파일을 panoramio에 올리면 google earth 사용자들이 언젠가 그 사진을 볼 수 있게 된다. 사진 링크하기도 편하다. 이미 geocoding된 사진이므로 업로드해서 mapping 안 하고 그냥 등록하면 된다.

등록된 사진은 별표가 표시된다. 별표가 표시되었다는 것은 google earth에서 채택되었다는 뜻이다. 채택이 되더라도 실제로 google earth에 사진이 나타나는 것은 한참 후의 일이다. '지도 상의, in Google Earth(KML)'을 클릭하면 구글 어스에서 당장 사용할 수 있는 kml 파일을 다운로드 받아 구글 어스로 링크된 이미지를 볼 수 있다. 즉, 구글 어스에 사진이 등록되기 전에도 친구들에게 사진을 보여줄 수 있는 url 인 셈이다.

4. Tracklog의 활용

트랙로그는 GPS를 켠 순간부터 GPS를 끌 때까지 GPS 내부에 기록되는 좌표 및 이동 정보다.

트랙로그는 Garmin MapSource, GPS Trackmaker, Google Earth 등의 프로그램을 이용해 GPS에서 직접 다운로드 받을 수 있다. 그외에도 GPS 자체적으로 일별로 트랙로그를 SD card에 기록하고 있는데, GPS를 USB Removable Disk로 인식하여 접속하면 이동식 디스크릐 루트 디렉토리에 적재된 gpx 파일을 볼 수 있다.

트랙로그는 프로그램에 따라 여러 가지 포맷으로 저장된다. 이들 포맷 간의 변환은 GPSBabel 프로그램으로 할 수 있다.

가장 호환성이 좋은 포맷은 .gpx이나, .gpx 파일은 XML text로 기록되어 파일 크기가 상당히 큰 편이다.

4.1 트랙로그의 평가

트랙로그를 평가하는 여러 종류의 툴이 있다. http://utrack.crempa.net/ 이 사이트에서는 .gpx 파일을 입력 받아 온라인으로 트랙로그를 평가해 준다. 그리고 그 결과를 pdf로 다운받을 수 있게도 해 준다. 샘플은 4시간 30분 동안 한강변을 자전거로 주행한 기록 http://www.pyroshot.pe.kr/tt/attachment/1333738485.pdf 로 확인 (m.s.l = meters from sea level)

4.2 wikiloc

wikiloc은 트랙로그를 공유하는 사이트이다. tracklog 파일을 사이트에 올려두면 다른 사용자가 리뷰 하거나 다운 받아 자신의 GPS에 다운로드하여 trackback할 수 있다. 상당히 유용한 기능으로, 비슷한 경로를 여행할 경우 많은 도움이 된다. 샘플:

5. Vista HCx

Garmin Colorado Series에 밀려 곧 역사 속으로 사라질 운명이긴 하지만, 독립 GPS의 샘플 운영 화면을 보여주기 위해 가지고 있는 Garmin Vista HCx의 화면을 캡쳐.

Cities & Satellite Page: 위성 수신 상황. 실내에서 잡은 거라 리셉션이 별로 좋지 않지만, Sirf III 에 비해 현저하게 빨라진 32채널 칩 사용으로, 산행 중에 주머니나 배낭에 넣어둬도 forest canopy(숲으로 뒤덮인 지역)나 골짜기에서도 위성을 놓치는 일이 거의 없다. 현재 위치에서 가장 가까운 '도시'를 찾는 페이지.

마그네틱 컴퍼스 내장. GPS 컴퍼스는 GPS 수신이 될 때만 작동하기 때문에 자기 컴퍼스가 꼭 필요하다. 바로 미터는 기압계 역할은 물론 기압에 따른 고도계 역할도 한다. 기압계는 급격한 날씨 변동을 모니터링하여 산악에서 발생하는 사고를 방지하는 효과가 있다.

Trip Computer, Map page: Trip Computer는 트래킹이나 바이크 라이딩할 때 가장 자주 보는 페이지. Map page에 Korea Topomap 10m를 적용한 화면. 야간이라 화면이 검게 나옴.

Calendar Page. 낚시하러 갈 날짜를 잡을 때 유용한 페이지.

Waypoint Find, Tracks Page: 기록된 waypoint 또는 POI를 검색하거나(가장 근접한 지점을 찾거나), 트랙을 선택해 trackback할 때 사용하는 페이지.

Sun & Moon, USB Mass Storage Connect Page: 해지는 시각, 해 뜨는 시각은 산악 트래킹할 때 아주 유용한 정보. 월령도 때때로 유용하다.

이외에도 Geocaching 관련 page, GPS를 이용한 게임, 계산기 따위 잡동사니를 포함해 많은 페이지가 있지만 생략. Vista HCx에 없는 것은 mp3 player, text viewer, 동영상 플레이어, 카메라, wifi 따위.

한국 지형도 데이터 구하기

GPS 2008. 10. 25. 16:13

NASA의 셔틀 서베이 사이트에서 구할 수 있는 지형도 타일 파일(.hgt)은 여러 개로 흩어져 있고 작업하는데 시간이 많이 걸려 다른 방법을 강구해 보았다.

US Geological Survey 1 Km GTOPO30 Digital Elevation Models에서 일단 동아시아 및 동남아시아 타일 DEM 파일을 구했다(e100n40.tar.gz). 여기서 얻은 파일은 Dem2Topo에서 인식이 안되므로 3DEM 프로그램(freeware)으로 읽어 들인 후 Geo Tiff DEM 파일로 변환해야 한다.

3DEM에서 File->Load 메뉴를 선택하고 GTOPO30 타잎으로 파일을 선택한다.

Width(Degree)를 적당히 조절한 다음, 지도상의 흰 사각박스를 움직여 한국 부근에 갖다 놓는다. Projection은 Lon/Lat을 선택한다. 위치가 맞으면 e100n40.tar.gz 파일을 선택한다. 위치가 어긋나면 로드에 실패한다.

메뉴의 Operation->Set Smaller Area를 클릭하여 마우스로 한반도를 선택한 후 Enter를 누른다. File->Save GeoTiff DEM을 선택하여 파일을 저장한다.

Dem2Topo를 실행해서 저장해 둔 GeoTiff DEM 파일을 로드한다. Dem2Topo 작업이 끝난 후 생성된 polish file(.mp)을 gpsMapEdit에서 로드하여 불필요한 부분(예를 들어 일본 큐슈 지역)을 선택한 후 삭제한다.

나머지 작업은 GPS용 한국 지형도 만들기와 같다.

최종 생산된 .img 파일 크기가 10MB에 불과하지만, 아쉽게도 등고선의 정밀도가 많이 떨어진다.

GPS용 한국 지형도 만들기에 사용된 SRTM 데이터는 NASA 및 NGA(National Imagery and Mapping Agency)가 독일과 이탈리아와 협력하여 만든 전 지구적인 규모의 Digital Elevation Model이다. 2000년 2월 11일 발사된 스페이스 셔틀 Endeavour에 SIR-C(Spaceborne Imaging Radar-C)를 싣고 약 11일 동안 레이다 간섭측량법을 이용하여 이미지 데이터를 수집했다. 남위 56도에서 북위 60도에 이르는 지표중 80%의 영역을 이미징했는데, 그중 99.96%가 한 번 이상 측정되었고, 94.59%가 최소한 두 번 이상, 50%가 세 번 이상 측정되었다.

이렇게 생성된 SRTM 데이터는 세 가지 포맷이 존재한다. SRTM1은 평탄화 작업을 하지 않은 것(노이즈가 많음), SRTM3는 인접 셀을 평탄화하여(3x3) 정밀도를 향상시킨 것, SRTM30은 30x30셀을 평탄화 한 것이다. 이들 데이터는 수퍼컴퓨터로 가공 처리 되어 EROS Data Center(EDC) 또는 SDDS(Seamless Data Distribution System)를 통해 배포했는데, 이 아티클에서 설명한 데이터는 SDDS에서 배포하는 GTOP30이며, 이것은 SRTM30의 데이터를 가공한 것이다. 포맷만 다른 같은 데이터다.

GPS용 한국 지형도 만들기

GPS 2008. 10. 23. 20:18

DEM(Digital Elevation Model) 파일을 Garmin GPS에서 사용가능한 맵 파일(.img)로 만드는 절차. 구글에서 한국어 웹을 뒤져보면 여러 종류의 문서를 찾을 수 있다. 키워드: gps hgt img

이 과정이 정말 눈물겹다. 올해 2월에 컴퓨터를 처음 구입한 이유가 이 작업을 하기 위해서였는데, 그 때는 변환이 잘 안 되었다. full map을 한 번 만드는데 12시간 이상 걸리니까 옵션 몇 개 바꾸고 테스트 하면서 작업하면 계산상 일주일이 우습게 간다. 그래서 그 동안 죽 시간이 안 나서 미뤘다. 조씨가 자전거에 마운팅해서 쓸 GPS를 구입하면서 쓸만한 지형도를 찾길래 그런 건 없으니 스스로 만들라고 했다. 고생하길래 절차를 알려주는 김에 나도 만들었다. 이 작업으로 이틀을 보냈다. 나도 울고 컴퓨터도 울고 GPS도 울었다.

흠... 다음은 open street map에 관해 써봐야지...

DEM 파일을 ftp://e0srp01u.ecs.nasa.gov/srtm/version2/SRTM3/Eurasia/ 에서 다운로드 한다. 또는, http://cafe.daum.net/GPSGIS에 가입하여 외부 자료실을 뒤져보면 된다. 아래는 남한 관련 다운 받을 파일 리스트.

N33E126.hgt.zip
N34E125.hgt.zip
N34E126.hgt.zip
N34E127.hgt.zip
N34E128.hgt.zip
N35E126.hgt.zip
N35E127.hgt.zip
N35E128.hgt.zip
N35E129.hgt.zip
N36E126.hgt.zip
N36E127.hgt.zip
N36E128.hgt.zip
N36E129.hgt.zip
N37E124.hgt.zip
N37E125.hgt.zip
N37E126.hgt.zip
N37E127.hgt.zip
N37E128.hgt.zip
N37E129.hgt.zip
N37E130.hgt.zip
N38E124.hgt.zip
N38E125.hgt.zip
N38E126.hgt.zip
N38E127.hgt.zip
N38E128.hgt.zip

변환에 사용한 소프트웨어

Dem2Topo 1.9 (http://people.uleth.ca/~brad.gom/dem2topo/)
IDL 7.0 (http://www.ittvis.com/ProductServices/IDL.aspx)
gpsMapEdit 1.0.51.0 (http://www.geopainting.com/en/)
cGPSMapper 097c Freeware (http://cgpsmapper.com/)
Sendmap 2.0 (http://cgpsmapper.com/)
MapsetToolkit 1.40 (http://cypherman1.googlepages.com/)

IDL 7.0을 설치하고(가입해야 다운 받을 수 있으며 license가 없어도 사용가능하다) Dem2Topo를 다운 받아 압축을 풀고 dem2topo.sav 파일 실행

이미지를 클릭하면 확대해서 볼 수 있음
Select DEM File(s)을 눌러 여러 .hgt 파일을 한꺼번에 선택한다.
Minor 를 10m로 해야 GPS에서 해안선이 그나마 덜 뭉개지고 보인다. 아쉽게도 dem2topo는 해안선을 만들어 주지 않는다. Sea Level Threshold를 0m로 해두어도 해안선이 안 보이는 것은 마찬가지다.
Contour Simplify Factor를 크게 하면 윤곽선(contour)이 볼품 없어진다. 파일 크기는 줄어들고 처리시간은 늘어난다. 반대로 factor를 0으로 설정하면 윤곽선 정보를 건드리지 않아 처리시간은 많이 줄지만 파일 크기는 늘어난다. 10이 추천하는 값이다.
Plot Setting의 Enable Plot와 Enable bitmap을 꺼두면 화면 업데이트가 없어지므로 속도가 향상된다.
Create .mp file(s) 버튼을 눌러 polished file을 생성한다.

MapEdit를 실행하여(별도 설치과정 없음), .mp 파일을 여러개 읽어 들인다.
읽어들인 파일을 묶어 단일 파일로 저장하면 변환에 필요한 시간을 줄일 수 있다.
단, 묶어서 저장하는 파일 크기가 지나치게 크면 cGPSMapper에서 변환에 실패할 수 있다.
경험치: 150MB 크기의 .mp 파일을 변환할 때 cGPSMapper가 메모리를 2GB쯤 사용. 250MB의 .mp 파일은 메모리 오류가 나며 변환 실패. 따라서, 개개의 .mp 파일 크기가 클 때는 파일을 merge 하지 않는 것이 바람직.

MapEdit에서 파일을 로드한 후 File->Properties메뉴로 들어간다.

Header Tab에서 unique id(자릿수 맞춰 적당한 숫자)와 Friendly Name을 세팅.

Levels Tab에서 Bits 및 Map Source zoom 레벨을 선택한다. 이 값은 Dem2Topo 프로그램의 help를 보면 기정의되어 있다(사용자가 변경할 수 없다).

cGPSMapper Tab을 세팅한다.
TRE Size: 값이 크면 GPS에서 지도를 그리는데 시간이 많이 걸린다. default=500
RGN Limit: 한 TRE에서 그릴 Region의 갯수를 지정. GPS가 지도를 그리는데 영향을 주지 않는다고 하며 1024를 추천된다. 나는 500으로 선택.
Map is Transparent: Y 또는 S를 선택해야 한다. N이면 지도가 GPS에 표시되지 않는다. S는 cGPSMapper 095 이전 버전에서는 선택할 수 없다.
Preprocessing: Generalization만 선택하면 작업 시간을 30% 줄일 수 있다. topo map인 관계로 intersection을 굳이 처리하지 않아도 된다.
아울러, Tools->Generalize->Nodes of All Polylines & Polygons 가 cGPSMapper의 generalization과 같은 역할을 하는 듯.

MapEdit의 File->Export 메뉴로 cGPSMapper를 실행하거나, 도스 커맨드 라인에서 실행한다. 전자는 변환이 간편한 대신 여러 개의 파일을 변환할 때 시간이 오래 걸린다.

작업 시간이 엄청나게 오래 걸리는 까닭에, 커맨드 라인에서 여러 개의 .mp 파일을 변환하기 위한 .bat 파일을 아래와 같은 형태로 만들어 밤에 걸어 두고 푹 자는 것이 바람직해 보인다.

run.bat의 예제:

cgpsmapper N33-34.mp
cgpsmapper N35.mp
cgpsmapper N36.mp
cgpsmapper N37.mp
cgpsmapper N38.mp

배치 파일을 실행할 때는 cgpsmapper.exe와 sendg.dll 파일이 같은 디렉토리에 있어야 한다.
cGPSMapper를 실행하기 전에 Windows에서 불필요한 프로그램을 종료해 둔다.
cGPSMapper는 엄청난 양의 메모리를 사용하고 변환에 시간이 많이 걸리는 프로그램이다. 따라서 메모리가 적은 시스템에서는 가상 메모리의 크기를 늘려주어야 할 수도 있다.
AND 브리즈번 4200 2.4GHz, 2GB(가상 메모리는 4GB)에서 한반도 전체를 변환 했을 때 6시간 가량 걸렸다. 097c 버전은 094 버전에 비해 2배 이상 속도가 향상되고 중간에 뻑나던 것들이 사라졌다 -- 예전에는 변환 안되던 것이 지금은 된다. -_-

변환이 끝나면 .img 파일이 생성된다. 변환된 파일들은 sendmap20.exe에서 불러들여 gps에 넣을 수 있다. gps에 기존에 있던 파일은 지워진다.
Garmin MapSource 최신 버전에는 원래 GPS 장치에 있는 세계 지도보다 좀 더 정밀한 세계지도(basemap)가 포함되어 있다. img를 생성할 때 이 파일을 함께 합치면 해안선과 고속도로, 주요 도로 및 도시명(POI) 검색이 가능하다. 보통 c:\garmin\TRIPWPT4\TRIPWPT4.img 파일이다.
버튼 중 'Create GMAPSUPP.IMG'을 선택하면 GPS 없이 GMAPSUPP.IMG 파일을 생성한다. GPS를 USB Storage Mode로 전환하고 GMAPSUPP.IMG 파일을 GPS의 \garmin 디렉토리에 복사할 수도 있다.
기존에 있는 파일을 그대로 놔두고 추가하려면 MapWel 프로그램(http://www.mapwel.biz/)의 Mapwel uploader를 사용한다.

변환된 파일을 Garmin MapSource에서 보려면 MapsetToolkit을 실행하여,
.img 파일이 있는 디렉토리를 선택하여 add한다. 이때 .img 파일들은 파일이름이 숫자 8자리로 지정되어 있어야 한다. (예: 34000000.img)
Mapset Directory는 img 파일을 정리하여 저장할 디렉토리를 선택한다(Garmin 디렉토리 아래가 좋고, 하나 생성)
Family ID는 Mapset Installed에서 겹치지 않는 id를 선택하거나 기존 것을 삭제하고 지정한다.
TYP Files는 공란으로 남겨둔다. 그외 나머지는 알아서 적당히 세팅한다.
Options에서 Install in Mapsource와 Balnk overview maps를 선택한다.
Start 버튼을 누르면 해당 디렉토리에 여러 파일들이 생성된다.

MapsetToolkit을 실행하여 생성된 파일들

Garmin MapSource에서 본 지도의 모습 (지형도에 나타난 덕유산 종주 코스)

작업에 걸린 시간: (AMD 브리즈번 4200 2.4Ghz, 2GB)

.hgt -> .mp 변환: 30분 가량 (CSF Contour Simplification Factor에 영향을 받는다)
gpsMapEdit로 .mp 파일 수정: 40분 가량.
.mp -> .img 변환: 1시간 20분 가량

생성하여 합성한 전체 지형도 파일 크기: 100~110MB

Dem2Topo의 Contour Simplification Factor에 따른 영향 평가

CSF=20: 817MB (한반도 전체 .mp 파일 크기), 112MB (생성된 .img 크기)
CSF=0: 873MB, 120MB

GPS에서 본 화면. 왼쪽이 CSF=20, 오른쪽이 CSF=0. 차이가 미미하다.

CSF=0일 때 외곽선 각이 약간 더 부드럽지만 그렇다고 큰 차이가 나는 것은 아니다.

왼쪽부터 CSF가 10,20,0. Dem2Topo가 추천하는 값은 10인데 그 값 그대로 사용해도 무방할 듯.

◀ PREV : [1] : NEXT ▶

Cosmic Background Noise

TAG LIST

Recent Post

COMMENTS

TRACKBACK

CATEGORY

글 보관함