Concurrent 방식의 QuadTree 생성

[Seungeon-Kim]

구현내용

Concurrent 방식의 QuadTree 생성

• 전체 데이터에 대해 하나의 트리를 생성하는 것이 아닌, 다수개의 트리를 병렬로 생성하여 사용하도록 수정
  (한반도 전체 기준 영역(Bounding Box) 분할)

 Key:  BoundingBox,  Value: QuadTree

• onTileChanged 이벤트 발생 시, 해당 타일의 영역에 Overlapped 되는 키를 찾아서 QuadTree 검색 및 탐색

[이미지 1]
한반도 전역 약 370만개 데이터를 25개의 트리로 관리했을때, CPU 사용량

[이미지 2]
한반도 전역 약 370만개 데이터를 25개의 트리로 관리했을때, 실행 화면

논의사항

QuadTree의 장점

탐색 속도가 매우 빠르다. (logN)

QuadTree의 단점

트리 생성이 느리다.

단점을 보완하기위해 여러개의 트리를 동시에 병렬로 생성을 하면 시간이 단축될 수 있지않을까 생각을 함.

초기 실행이 느려지는 일이 발생하는데, Coredata로부터 Fetch를 분할된 화면만큼 실행해서 느려지는 것으로 생각됨

fetch는 전체 데이터를 한번만하고 얻어진 데이터를 filter 하는 방법을 확인해볼 예정

[beggu84]

한반도 전체를 쿼드 트리로 만들었군요. 👍

트리 구축하는 게 너무 느리면, 줌 레벨 별로 그리드 인덱스를 구축하는 것도 대안이 될 수 있겠어요.
줌 레벨이 하나 증가할 때 마다 타일이 네 개로 쪼개지는 개념은 같으니깐요.
그러기엔 너무 많이 진행되어 버렸나..;

[Seungeon-Kim]

한반도 전체를 쿼드 트리로 만들었군요. 👍

트리 구축하는 게 너무 느리면, 줌 레벨 별로 그리드 인덱스를 구축하는 것도 대안이 될 수 있겠어요.
줌 레벨이 하나 증가할 때 마다 타일이 네 개로 쪼개지는 개념은 같으니깐요.
그러기엔 너무 많이 진행되어 버렸나..;

@beggu84
https://navermaps.github.io/maps.js.en/docs/tutorial-1-maptypes-tilecheck.example.html
위 내용을 보면서 그리드 인덱스에 대해서 알아보는데, 사실 잘 감이 안잡힙니다.. 😭
어떤 방식으로 그리드를 관리하는지 혹시 조금 설명을 해주실 수 있을까요?

생성이 느린 부분은 위에 filter말고 다른 방식도 생각을 했는데, 사실 아직 구현이 될지 몰라 확인 후 추가하도록 하겠습니다!

[rnfxl92]

LGTM

[beggu84]

이해를 돕기 위해 지구의 가로 길이만 생각해 봤을 때.
지구 지름을 L(km) 라고 했을 때, 줌 레벨 1에서는 지구 전체를 하나의 타일이라고 생각하면 그 타일 하나의 길이는 L 이 될 거예요.
줌 레벨이 하나 증가할 때마다 타일이 두 개로 쪼개지고 타일 하나의 길이도 L / 2가 될 거예요.
줌 레벨 n 이 되면, 타일의 개수는 2^n 이 되고, 타일 하나의 길이는 L / 2^n 이 될 거예요.
여기서 각 줌 레벨 별로 타일 하나의 길이를 저장해 놓고 있으면, (L / 타일 길이)로 현재 좌표가 몇 번째 타일 안에 있는 지 알 수 있을 거예요.
이거를 세로도 적용해 보면,.. 각 줌 마다 가상의 타일 인덱스가 생겨나는 거죠. 그 인덱스로 현재 좌표가 어디에 위치에 있는지 알 수 있고요.

쿼드 트리랑 비슷하지 않나요?

[beggu84]

그리드 인덱스는, 그냥 한 번 고려해 보시라 하는 거니, 부담 갖지 마세요. 이미 쿼드 트리로 많이 진행하셨으니깐요.

[Seungeon-Kim]

이해를 돕기 위해 지구의 가로 길이만 생각해 봤을 때.
지구 지름을 L(km) 라고 했을 때, 줌 레벨 1에서는 지구 전체를 하나의 타일이라고 생각하면 그 타일 하나의 길이는 L 이 될 거예요.
줌 레벨이 하나 증가할 때마다 타일이 두 개로 쪼개지고 타일 하나의 길이도 L / 2가 될 거예요.
줌 레벨 n 이 되면, 타일의 개수는 2^n 이 되고, 타일 하나의 길이는 L / 2^n 이 될 거예요.
여기서 각 줌 레벨 별로 타일 하나의 길이를 저장해 놓고 있으면, (L / 타일 길이)로 현재 좌표가 몇 번째 타일 안에 있는 지 알 수 있을 거예요.
이거를 세로도 적용해 보면,.. 각 줌 마다 가상의 타일 인덱스가 생겨나는 거죠. 그 인덱스로 현재 좌표가 어디에 위치에 있는지 알 수 있고요.

쿼드 트리랑 비슷하지 않나요?

그리드 인덱스는, 그냥 한 번 고려해 보시라 하는 거니, 부담 갖지 마세요. 이미 쿼드 트리로 많이 진행하셨으니깐요.

@beggu84
감사합니다! 완벽히는 아니지만, 어느정도 이해가 되었습니다!
z축을 child node로 관리하는 트리와는 다르게 줌레벨에 따라 인덱스로 관리 하는것이 현재 구현된 쿼드 트리와 비슷하지만 차이가 있네요 😀