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으로 작업했다.
OSM2IMG를 개정했다. mkgmap.jar가 실행중 에러가 발생했을 때 에러 코드를 리턴하지 않기 때문에 사실 맵이 제대로 만들어졌는지 확인하기가 좀 힘들다. console output을 캡쳐해서 다만 에러 메시지만이라도 확인할 수 있게 했다. 또, MapSource에 설치할 때 registry에 자동 기록하고 registry 파일을 만들게 했다. 그리고 MapSource에 설치될 때 tile cache를 삭제해서 MapSource에 이상한 표시가 나오지 않도록 했다. OSM2IMG가 이제 썩 쓸만한 프로그램이 되었다. 이 김에 제대로 만들어서 배포할까?
한강 작업 때문에 메르카토르를 사용해 보고 어느 정도 쓸만하다 싶어 북한산 트래킹 코스 작업을 해봤다. Potlatch에서는 작업중 데이터를 날려 먹어 귀중한 3시간을 허비했다. JOSM에서는 WMS로 야후 맵을 출력하는 속도가 워낙 느려 답답했다. 메르카토르에서 두어 시간 작업하다가... 황당하게 프로그램이 다운되었다. 뭘 해도 쉽지가 않네? 간단한 작업에나 사용할 수 있을 듯. 메르카토르는 태그 에디팅이 좀 많이 불편한 편. 다음 버전 나올 때까지 기다려보자.
지도를 만들다 보니 한강이 이상하게 꼬여 있어 무슨 일인가 싶어 확인했다. 한강이 망가져 있다. 어떤 작업자가 한강을 수정하다가 날려 먹은 것 같다. 이번에는 좀 심각하다. 사실 그 작업자의 잘못은 아니고, 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로 야후 맵을 출력하는 속도가 워낙 느려 답답했다. 메르카토르에서 두어 시간 작업하다가... 황당하게 프로그램이 다운되었다. 뭘 해도 쉽지가 않네? 간단한 작업에나 사용할 수 있을 듯. 메르카토르는 태그 에디팅이 좀 많이 불편한 편. 다음 버전 나올 때까지 기다려보자.