OSM 컨테스트에서 격찬을 받은 Open Cycle Map 은 등고선 지도와 자전거 경로를 결합한 아이디어가 꽤 훌륭하다. 그래! 바로 이거다 싶을 정도다. 다음이나 네이버에서 지도를 가지고 개최 하는 사용자 매시업 프로젝트들처럼... 음... 시시껄렁하지 않다. 또는 google mymaps처럼 바보스러워 보이지도 않는다.
OSM의 구현에서 엿보이는 simplicity는 무척 마음에 든다. 그래서 누가 이런 좋은 것을 만들었는지 뒤져봤다.
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 를 사용했다.
노드 중 내가 작업한 것들'만' 가져오는 방법은 아래와 같다.
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일 걸렸다.
구글이 web robot를 사용해서 웹 사이트를 수집하듯이 아주 갖은 지랄을 다 한 끝에 온갖 사이트를 검색하여 법적 하자가 없을 것으로 추측되는 9만 여개의 고유 명칭을 얻었다. 이 작업이 거의 7일 걸렸다.
POI 좌표 얻어오기
그리고 yahoo poi api는(한국 야후 만세!) 하루 5만건으로 제한하긴 했지만, 고유명칭을 알고 있으면 WGS84 좌표를 얻을 수 있다. 다만 야후에서 POI 검색으로 얻은 결과에 '야후에서 얻었음'이란 말을 달기만 하면 된다. 그러고보니 소프트웨어를 무료 공개해 인류 공영에 이바지 한다는 구글을 통해서는 뭐 하나 얻은게 없는데(얻으려 애썼지만 성과가 '0'이다) 야후는 구글처럼 떠벌리지도 않으면서 인류 공영에 이바지 하고 있다는 생각이 든다.
OSM 지도 그리기에 크나큰 도움을 주는 slippery map을 야후에서 제공하고 POI 검색도 야후에서 제공한다. 명칭 수집과 병렬로 진행된 이 작업은 5일이 걸렸다.
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가 가장 낫다.
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를 올린다는 것이 시나리오다. 이들 자료는 나중 관리 목적으로 별도의 태그를 하나 더 붙일 예정이다.