OSRM Match API로 러닝 코스 데이터 좌표 보정하기

프로젝트 초기에 러닝 코스 데이터를 수집하는 과정에서 구글 어스를 이용했다. 해당 방법은 직접 좌표를 찍어가며, 해당 좌표들을 모아 kml 파일로 추출하여 러닝 코스 데이터를 만드는 방법이었다.

하지만 해당 방식은 경로를 각 좌표마다 직선으로만 이어주었기 때문에 직선이 많지 않은 실제 도로에서는 사용하기 어려웠다. 또한, 곡선을 표현하기 위해 들여야 하는 에너지가 많이 소모됐다.

그래서 다른 방법을 찾았고, 이는 다른 외부 서비스 (스트라바, 가민 등)을 이용하거나 블로그, 외부 커뮤니티를 찾으며 실제 러닝을 뛴 사람들의 기록을 gpx 파일로 추출하여 삽입하는 방법이었다.

이 방법을 통해 기존 kml 파일보다 품질이 좋은 러닝 코스 데이터를 수집할 수 있었다. 하지만 해당 방식은 측정하는 사람의 기기에 따라 측정 성능이 차이나는 치명적인 문제가 존재했다. 이러한 측정 기기 간의 러닝 코스 정확도를 효과적으로 해결해야 했다.

그래서 처음에는 팀원들과 다 같이 '수동'으로 문제를 해결하고자 했다. 어드민 페이지를 구성하였고, 각 러닝 코스들의 튀는 좌표들을 리스트업 하며 직접 수정했었다.

하지만, 러닝 코스마다 적어도 약 300개 이상의 좌표가 존재했고, 많으면 5만 개까지 존재했다. 이러한 러닝 코스 좌표들을 일일이 수작업으로 수정한다는 게 쉬운 작업도 아닐뿐더러 시간, 에너지 소모가 컸다. 그래서 이러한 수고를 덜어야 했다.

먼저 지금까지의 문제를 정의해 보았다.

1. 러닝 코스 파일에 존재하는 정확하지 않은 경로를 수정해야 한다.
2. 정확하지 않은 경로의 수정을 수동이 아닌 '자동'으로 이뤄내야 한다.

이 두 가지 문제를 효과적으로 해결할 수 있는 방안이 존재했다. 그 방안은 Map match API를 이용하는 것이다. 해당 API는 좌표들을 넘겨주면 지도상 가까운 도로에 자동으로 매칭해 준다. 이러한 기능을 제공하는 서비스가 몇 가지 있었는데 각 MapBox, OSRM, GraphHopper 등이 있다.

이 중 인지도와 문서화 수준을 놓고 보면 적합한 서비스는 MapBox와 OSRM이 후보로 추려진다. 하지만, MapBox의 경우에는 10만 번 이상 호출 시 비용이 발생하고, 기존에 OSRM 서버를 구성해 놨기에 OSRM을 이용하기로 했다.

OSRM을 선택하고, match API를 이용하는 서비스 코드를 작성했다. 하지만, match API를 이용해도 좌표가 제대로 매칭되지 않는 문제가 발생하는 것이다.

애초에 매칭되는 경로가 없다는 것이다. 하지만, 바로 옆에 도로가 존재하고 있기에 매칭되는 경로가 없는 건 말이 안 되는 것이다. 그래서 해당 문제와 관련해서 공식 문서 및 Github를 찾아보았고, match api에는 주요한 파라미터가 두 개 더 존재한다는 것을 알았다.

이는 radiuses, timestamps 파라미터이다. 해당 파라미터들을 같이 주게 된다면 매칭의 정확도가 더 높아진다는 것이다. radiuses 파라미터는 특정 좌표가 인근 도로 구간에 매칭될 때 허용되는 최대 거리(미터 단위)를 지정한다. timestamps의 경우에는 지도 매칭 알고리즘이 지점 간 이동 속도와 시간을 고려할 수 있게 해 준다. 이를 통해 잡음이 있는 경로에서 매칭 품질을 크게 향상한다.

파라미터 두 개를 따로 지정해주지 않으면, radiuses는 5m로 지정되고 timestamps 기본값이 없다. radiuses는 각 좌표 별로 15m를 지정해 주었고, timestamps는 각 좌표 간 소요 시간을 5초로 지정해 주었다.
gpx 파일에 존재하는 시간 데이터를 사용하면 더 좋았겠지만, 이미 많은 데이터들이 삽입된 상태라 추후 고려해 보는 게 좋을 거 같다.

이것으로 NoMatch 문제가 해소되었고, 이전보다 훨씬 높은 정확도를 보여주었다. 하지만, 문제는 여전히 '도로'에만 매칭된다는 문제가 남아있었다.

그래서 이러한 공원길에 매칭되지 않는 문제의 원인을 열심히 찾아보았다. 하지만 어디에도 이와 관련한 레퍼런스가 없어서 원인을 한번 추측해 봤다.

OSRM 서버가 OSM 데이터를 사용하고 있어서 해당 맵 데이터에 저 공원길 자체가 없다는 추측이었다. 그래서 이를 증명하기 위해서 OSM에 접속해 해당 공원길을 찾아보았는데, 길이 아예 없는 것은 아니었다.

위 그림처럼 footway라는 이름으로 길이 존재하긴 했다. 그래서 이러한 상황과 함께 Claude 및 GPT의 도움을 받아 문제가 발생할 수 있는 원인을 대표적으로 두 가지 알 수 있었다.

 

• OSM 맵 데이터 자체의 문제

하지만, 이는 이미 증명되었다. 적어도 저 길에는 매칭이 되어야 했다.

• OSRM profile이 foot이 아닌 car로 되어있는 문제

이건 새롭게 안 사실인데, url에 `/match/v1/foot/~`으로 썼다고 해서 OSRM에서 foot으로 무조건 처리하는 게 아닐 수 있다는 것이다. 이는 OSRM 서버 구성 중 어떤 profile로 데이터를 전처리 했느냐에 따라 달라진다고 한다.

그래서 빠르게 로컬에서 OSRM을 foot.lua로 전처리하도록 한 후 테스트를 진행했다.

 

그러자 어느 정도 공원길에 매칭되는 것을 확인할 수 있었다! 하지만, 이 또한 완벽하게 매칭되는 것은 아니었다. 그도 그럴 것이 OSM 데이터를 보면 카카오맵과 다르게 공원길이 구성되어 있는 것을 알 수 있다. 그래서 완벽하게 카카오맵에 맞게 매칭하지는 못할 것이다..

 

결과적으로 현재는 공원길에 대해서는 수작업을 통해야 하지만, 적어도 도로에 대해서는 API 호출을 통해 해소하도록 했다.

 

앞으로의 계획

OSM 데이터를 커스텀하는 방법을 찾아보거나, 또는 OSRM의 커스터마이징이 자유로운 만큼 이러한 부분들에 대해서 더 공부해 보고 적용하는 과정들이 필요할 것 같다.