Как стать автором
Обновить

Комментарии 4

Какое-то двоякое чувство… С одной стороны интересные алгоритмы могут получаться. А с другой стороны программисты сами своими руками создают будущее цифровое рабство.
Дальше будет хуже. Распознавание лиц на улицах в и публичных местах, обязательное отслеживание местоположения каждого… автоматические штрафы уже придуманы…
Куда идем?

Тут, мне кажется, как с атомной бомбой. Задержка технологического прогресса в целом и конкретных технологий в частности не решит проблем, которые этот прогресс и эти технологии потенциально могут породить. Скорее даже наоборот, усугубит. На этот счет есть много доводов: табуирование технологий провоцируют однобокое их развитие (те, кому очень нужны эти технологии, всё равно будут их разрабатывать и применять, а остальные будут в уязвлённом положении); чем раньше мы ворвёмся в технологическое будущее, тем больше у нас будет времени эффективно разрабатывать решения проблем, прежде чем мы убьём себя старыми технологиями.


Идём вперёд. Не остаёмся в стороне. Не даём нечистым на руку органам и структурам без нашего разрешения оперировать нашими данными.
Я понимаю, что это "ящик пандоры", но мы его приоткрыли ещё со времён первой идеи использовать палку, чтобы достать бананы. Теперь у нас нет выбора: нужно выбираться в космос и огребать проблемы поважнее и поинтереснее, чем тотальная слежка и реализация антиутопии на отдельно взятой планетке.

Касательно написанного в статье.
Ваши треки из примера совсем не тянут на секундную и метровую точность. Люди летают у вас как орлы, а допущения делают эту задачу ну уж слишком лабораторной и высосанной из пальца.


А ведь можно было бы сделать шажок в сторону практики и реальности, и всё бы заиграло куда более интересными красками.
Итак, у вас есть "треки" без временной привязки. Вы на их основе сделали себе фейковые тестовые данные протрассировав во времени и пространстве. Окей, ничего не имею против.
Записать пару реальных треков в городе не сложно, но сложнее, чем их сочинить. С другой стороны, нужно всего лишь попросить коллег прокатиться/пройтись домой/на работу с включенным трекером. Можно также взять треки маршрутов по городу с ресурсов вроде такого (первый нагуглившийся, но их много). Можно задвинуть их по датам в рамки одного или нескольких дней. Это даст вам реалистичные данные, а не такие, как у вас.


В любом случае процесс подготовки тестовых данных стоило как-то вынести за скобки основного повествования о задаче, хотя в образовательном смысле он тоже интересен.


Следующим этапом я бы порезал треки по таймаутам: если трек не писался пару десятков минут, то мы не можем что-то предполагать по поводу точной траектории агента.
Я бы выделил непрерывные сегменты (далее "Сегменты") треков в отдельную таблицу, возможно зачем-то стоило бы сохранить и эти "пробелы" (далее "Разрывы"). Делается это с помощью оконных функций, например.


Далее, чисто для оптимизации, разбил бы Сегменты на Чанки, выровненные по временнОй сетке, например, десятиминутной или часовой (подобрать эмпирически по соображениям эффективности индексации и джойна). Каждый такой Чанк получил бы у меня AA-BB границы, немного "раздутые" пропорционально максимальной скорости в рамках чанка. Это чтобы не потерять коллизии на концах из-за точности.


Далее можно делать джойн таблицы Чанков на себя пересекая Чанки геометрически в рамках своего тайм-слота. Таким образом мы достаточно быстро и эффективно найдём все потенциальные коллизии. По-хорошему, конечно было бы обработать две серии чанков, чтобы вторая была сформирована со сдвигом на пол периода сетки. Но это уже детали.


Получив все коллизии, можно склеить обратно, а лучше вырезать по новой из оригинальных треков куски в рамках краевых временных точек коллизии.


Вот эти вот куски треков уже можно без ущерба для вычислительных ресурсов трассировать и пересекать по радиусу, тоже джойном и оконными функциями с ограничением окна по времени и минимальному расстоянию между точками внутри окна.


Альтернативой трассировки можно предложить решение системы параметрических уравнений: каждый промежуток между двумя точками траектории имеет трёхмерные координаты краёв (x, y, t). Определяем метрику в пространство-времени для оценки сближения этих отрезков и получаем некий пространственно-временной эллипсоид контакта. Именно этот эллипсоид получит дознаватель для перекрёстного допроса нарушителей карантина=).


Ещё совершенно напрасно не рассмотрены важные корреляции, которые можно отследить по трекам:


  1. признаки перемещения агентов в одном транспортном средстве: можно потом найти на дорожных камерах наблюдения ТС и записать в Контактные его водителя;
  2. признаки пребывания в одном помещении: если в точке длительного пребывания агентов мало иных мест возможного длительного пребывания за исключением кафе, заправки или других POI, следует добавить в Контакт это POI и запросить записи с релевантных камер наблюдения.

UPD:
Забыл добавить про Разрывы. Их тоже следует добавлять в отчет, чтобы дознаватель мог отдельно опросить агентов об их перемещениях в этих промежутках. Иначе эти временные интервалы могли остаться забытыми, а между тем COVID-положительный и опасный человек мог ехать несколько перегонов в метро и заражать всех подряд в вагоне.

Интересно кто и как в реальном мире и стране не называющейся Китай добудет закрытую медицинскую информацию о диагнозе человека по которому писался трек?

Кто понесёт административную и уголовную ответственность за последствия недостоверного предупреждения о заражении? Допустим какому-то чувствительному человеку придёт письмо о его возможном заражении и это приведёт к печальным последствиям.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий