boostcamp-2020/Project17-C-Map

K 계수 결정 문제

A-by-alimelon opened this issue · 3 comments

기존의 방법은 데이터의 수에 따라 클러스터링 개수가 비례적으로 늘어나는 방식이지만
줌 레벨을 고려해서 저 레벨 -> 고 레벨으로 클러스터링 개수가 늘어나야 한다
이 점을 고려해서 k 계수를 적절히 결정해야 한다

기존의 방법은 데이터의 수에 따라 클러스터링 개수가 비례적으로 늘어나는 방식이지만
줌 레벨을 고려해서 저 레벨 -> 고 레벨으로 클러스터링 개수가 늘어나야 한다
이 점을 고려해서 k 계수를 적절히 결정해야 한다

K 계수가 왜 줌레벨을 고려하면 개수가 늘어나야 하나요?
화면 사이즈는 고정입니다. 그런데 줌 레벨에 따라서 반드시 늘어나야 되는 개념은 아니지 않나요?

기존의 방법은 데이터의 수에 따라 클러스터링 개수가 비례적으로 늘어나는 방식이지만
줌 레벨을 고려해서 저 레벨 -> 고 레벨으로 클러스터링 개수가 늘어나야 한다
이 점을 고려해서 k 계수를 적절히 결정해야 한다

K 계수가 왜 줌레벨을 고려하면 개수가 늘어나야 하나요?
화면 사이즈는 고정입니다. 그런데 줌 레벨에 따라서 반드시 늘어나야 되는 개념은 아니지 않나요?

고 레벨에서 저 레벨로 갈 때 클러스터가 병합되는 느낌을 주고, 한반도 전체를 봤을 때 k=1 인게 자연스럽다고 생각 되어서 고 -> 저 로 가면서 클러스터 개수가 적어져야 한다고 생각했는데,
화면에 클러스터들이 얼마나 뭉쳐있지 않아야 할 지를 먼저 생각해 보아야 할 것 같습니다! 다시 고려해 보겠습니다🙇🏻‍♀️

  1. 그룹 내 거리와 비교하여 다른 그룹간의 분리 정도의 비율로 계산하는 DBI 검증을 통한 K 계수 결정
  2. 각 데이터와의 거리의 결합도, 분리도를 따져 -1 부터 1 (숫자가 1에 가까울 수록 결합도가 높다고 판단) 까지 표현하여 K 계수 결정
    하지만, 적절한 k 값을 찾기위해 n <= k <=m 범위 내의 모든 값을 구한 후 최적의 값을 찾아야 하므로 다소 시간이 오래 걸림.
    따라서 k-means로 클러스터링을 구현하기 보다는 quad tree로 클러스터링을 구현하는 것이 우리의 목표인 속도 측면이나 지도 서비스 측면에서 낫다고 판단하였음