Але у мене виникло кілька запитань: — Навіщо так заморочуватися з оптимізацією збереження траекторії, якщо compression під капотом робить з данними приблизно те саме. Я маю на увазі що спільний префікс bt 1323001030 для кількох bt 1323001030 11, 1323001030 22, 1323001030 33, буде представленний як скажімо AA, самі ж bt будуть записані у вигляді AA11, AA22, AA33
— Можливо я трохи не уважний, але у фінальному SQL inner join відбувається по truncated hour, так само array_intersect використовує trajectory_main в якому знаходиться truncated minute. Тобто запит нам дає осіб які бували в одному і тому ж місці в одну й ту ж годину, але можливо не в один й той самий день/місяць/рік і маршрути яких збігаються у тому що вони були у одному tiles у одну й ту ж хвилину більше 10 разів за сессію. А отже цей запит буде давати багато false positive. Наприклад, особи подоружували одним потягом в різні дні, tiles достатньо великі, а потяг йде за розкладом так що tiles співпадають до хвилин.
Крута і цікава стаття, дякую!
Але у мене виникло кілька запитань:
— Навіщо так заморочуватися з оптимізацією збереження траекторії, якщо compression під капотом робить з данними приблизно те саме. Я маю на увазі що спільний префікс bt 1323001030 для кількох bt 1323001030 11, 1323001030 22, 1323001030 33, буде представленний як скажімо AA, самі ж bt будуть записані у вигляді AA11, AA22, AA33
— Можливо я трохи не уважний, але у фінальному SQL inner join відбувається по truncated hour, так само array_intersect використовує trajectory_main в якому знаходиться truncated minute.
Тобто запит нам дає осіб які бували в одному і тому ж місці в одну й ту ж годину, але можливо не в один й той самий день/місяць/рік і маршрути яких збігаються у тому що вони були у одному tiles у одну й ту ж хвилину більше 10 разів за сессію. А отже цей запит буде давати багато false positive. Наприклад, особи подоружували одним потягом в різні дні, tiles достатньо великі, а потяг йде за розкладом так що tiles співпадають до хвилин.