전용 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인 데이터다.
다음 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/
) 그래도 오차폭이 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 압축을 만들지 않아 데이터 전송량이 클 경우 전송 자체만으로도 꽤나 많은 시간을 소비한다는 점이다.
위성이 무려 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>
<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에 경로 그리기 메뉴가 추가되었다.
새로운 API에 맞춰 만들어놓은 간단한 프로그램들의 OSM broker 소스를 개정해야 하는데... 좀 귀찮아서 관뒀다.
그동안 Potlatch 한글화를 했다. 메시지 한글화에 큰 의미는 없어 보인다. wiki 페이지도 한글화할까 하다가 누군가가 해 놓은 한글화만으로도 충분하다고 생각했다.
mkgmap과 srtm2osm 따위 프로그램을 사용해 지형도와 스트릿 맵을 완샷에 작업하는 스크립트를 짜느라 하루 정도 시간을 보냈다. 결론은, 참 쓸모가 없고 시간과 노력만 허비했다. 기존에 만들어놓은 지형도 데이터보다 정밀도나 해상도는 떨어지지만 시간은 좀 단축시킬 수 있다. 스트릿맵이야 원래와 같으니까 상관없다.
별도로, Wikiloc에 경로 그리기 메뉴가 추가되었다.
사실 정말 필요한 것은 gpx 업로드해서 gpx를 분석하고 트랙로그를 지도와 연동해 화면에 표시해주는 것 보다, 자전거 여행할 때 구글 맵이나 다음 맵 따위를 배경에 깔고 저것처럼 경로를 그려준 다음 gps에 업로드해 행복하게 트랙백을 하는 것이다. 그 정도 작업을 하려면 아무래도 웹 프로그래밍을 배워야 할 것 같은데 어째 시간이 많이 걸릴 것 같아 누군가 해주겠지... 아니면 구글 뒤져보면 누군가 만들어 놓았겠지 하는 막연한 생각만 들었다.