작업 영역이 전방위적이라 정신 사나워서 중간 정리의 필요성을 느꼈다. 사실상 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
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"
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]]
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
