Спасибо за вопрос про такой интересный вид транспорта! Навигатора по водным путям для частного передвижения у нас действительно нет. Зато у нас есть водные маршруты для тех, кто пользуется водным общественным транспортом. Недавно мы как раз выпустили новость про 300 водных маршрутов в Картах. Они включают в себя как внутригородские (например, электросуда в Моксве), так и внутрирегиональные (например, в Ярославльской области), и даже межрегиональные (например, из Нижнего Новгорода в Казань).
Как я написал в тексте, технология ещё очень молода и только развивается. Популярные варианты вело проезда и прохода пешком действительно генерируются только в самых оживленных местах, где есть достаточно много данных. Мы работаем над тем, чтобы научить алгоритм оценивать комфортность даже там, где люди ходят не так часто.
Тут, на самом деле, бывают разные варианты. Один из популярных – неправильно определился маршрут автобуса. Таким образом, мы пытаемся привязать его к трассе этого маршрута, при том, что сейчас он едет по другому, возможно, даже по соседней улице.
Транспортные средства (ТС) на одном маршруте могут ездить по разным трассам. При этом набор информации, которая приходят от поставщиков, действительно различается – в некоторых случаях такие ТС разделить без эвристик на стороне сервиса невозможно, отсюда и появляется эта задача.
Наша автоматика следит за подозрительными изменениями в объемах данных и их качестве. В некоторых случаях действительно возникает необходимость коммуникации с партнером. Тогда мы делаем все возможное, чтобы проблема была устранена как можно быстрее
JSON и XML – в данном случае, примеры форматов исходных данных, которые поступают на вход сервису приема сигналов. А основной челлендж с производительностью у нас возникает позже, на этапе обработки (привязки, прогнозирования). Все взаимодействие между сервисами внутри нашей системы, конечно же, происходит в бинарном формате :)
Действительно, не самая удачная формулировка! По факту речь о фильтрации очевидно некорректных данных – отрицательных координат, времени из будущего и т.п. Поправим, спасибо за фидбек!
Спасибо за вопрос про такой интересный вид транспорта! Навигатора по водным путям для частного передвижения у нас действительно нет. Зато у нас есть водные маршруты для тех, кто пользуется водным общественным транспортом. Недавно мы как раз выпустили новость про 300 водных маршрутов в Картах. Они включают в себя как внутригородские (например, электросуда в Моксве), так и внутрирегиональные (например, в Ярославльской области), и даже межрегиональные (например, из Нижнего Новгорода в Казань).
Как я написал в тексте, технология ещё очень молода и только развивается. Популярные варианты вело проезда и прохода пешком действительно генерируются только в самых оживленных местах, где есть достаточно много данных. Мы работаем над тем, чтобы научить алгоритм оценивать комфортность даже там, где люди ходят не так часто.
Ого, кейс действительно необычный – похоже на ошибку в данных. Уже передал в чат ответственным за автомобильные маршруты!
Это логикой занимаются коллеги из разработки Такси, но, насколько я подозреваю, логика примерно такая, да
написал один из возможных вариантов в комментариях :) эту проблему, в определенной степени, мы, конечно, пытаемся решать
Тут, на самом деле, бывают разные варианты. Один из популярных – неправильно определился маршрут автобуса. Таким образом, мы пытаемся привязать его к трассе этого маршрута, при том, что сейчас он едет по другому, возможно, даже по соседней улице.
Транспортные средства (ТС) на одном маршруте могут ездить по разным трассам. При этом набор информации, которая приходят от поставщиков, действительно различается – в некоторых случаях такие ТС разделить без эвристик на стороне сервиса невозможно, отсюда и появляется эта задача.
Наша автоматика следит за подозрительными изменениями в объемах данных и их качестве. В некоторых случаях действительно возникает необходимость коммуникации с партнером. Тогда мы делаем все возможное, чтобы проблема была устранена как можно быстрее
JSON и XML – в данном случае, примеры форматов исходных данных, которые поступают на вход сервису приема сигналов. А основной челлендж с производительностью у нас возникает позже, на этапе обработки (привязки, прогнозирования). Все взаимодействие между сервисами внутри нашей системы, конечно же, происходит в бинарном формате :)
Действительно, не самая удачная формулировка! По факту речь о фильтрации очевидно некорректных данных – отрицательных координат, времени из будущего и т.п. Поправим, спасибо за фидбек!