Карты и геотеггинг в вебе
Как научить модель понимать пространство по одному уличному снимку и переводить перспективу в измеримые величины?
В статье исследуем этот вопрос на примере ширины тротуаров: восстанавливаем глубину сцены, строим 3D‑представление поверхности и проверяем, насколько точно машинное обучение может описать привычную городскую среду.
Привет, Хабр! Я Павел Молчанов, Data Engineer из группы обработки гео- и медиаданных Big Data компании МТС Web Services. Наш продукт «ГеоЭффект» занимается расчетами различных геостатистик на основе телеком-данных (например, по туризму).
У нас есть ежедневно обновляемая инфраструктурной командой витрина-источник с событиями (точками нахождения абонентов) на основе мобильной сети по всем регионам присутствия МТС. За сутки на каждого абонента приходится в среднем порядка 200 геособытий, общий объем данных в витрине — около 11 млрд записей в сутки. Однако в витрине-источнике не было привязки геособытий к административно-территориальной информации «Регион РФ / район», что критически важно нам как продуктовой команде, решающей бизнес-кейсы в интересах заказчиков.
Отсюда и появилась задача — дообогатить витрину дополнительными атрибутами на основе координат геособытий. Так что в этом материале по мотивам доклада для Highload++ поделюсь, как мы это сделали, а еще ускорили джойн датафреймов с геоданными.
Пара слов по технологическому стеку: сейчас мы активно проводим подготовительные работы по переходу на Data LakeHouse, но пока что основная рабочая лошадка — Spark на старом добром Hadoop-кластере с HDFS и Hive Metastore. Так что повествование будет идти в контексте технологий Spark on YARN + Sedona + HDFS + Hive.
Мне нужна была рекомендация хорошего ресторана, поэтому я поступила как любой нормальный человек: выполнила скрейпинг всех ресторанов в Большом Лондоне и собрала модель машинного обучения.
Всё началось со вполне логичной задачи: меня утомило блуждание по Google Картам в попытках отделить места с действительно хорошей едой от тех, которые мне сегодня решил всучить алгоритм. Где-то в процессе проект вышел за пределы простого поиска перекуса и превратился во что-то чуть более сумасшедшее, став исследованием того, как цифровые платформы незаметно перераспределяют возможность экономического выживания.
Как только начинаешь смотреть на ресторанный бизнес Лондона через призму данных, перестаёшь видеть все эти милые новые местечки и громкие анонсы об открытии, и начинаешь видеть алгоритмический рынок, на котором узнаваемость подпитывает сама себя, спрос создаёт эффект лавины, а жизнью и смертью заведений всё больше управляет код.
Яндекс.Навигатор ещё один продукт у которого ухудшается UX и создаётся впечатление, что некоторые сотрудники просто сами не сидят за рулём, ну и точно не через iPhone.
Привет! Меня зовут Мария Минакова, я Senior Product Manager и я разбираю только те продукты, над которыми сама хотела бы поработать, так как ими пользуюсь, люблю и вижу, где есть потенциал роста. Мне драйвово искать для них решения, которые выводят продукт на новый уровень не только по деньгам, но и по UX и любви пользователей. Мои предыдущие разборы: Как я искала точки роста для «Звука»: догонять рынок или создавать новый? и ВкусВилл: UX, который покоряет, и ложка дёгтя в офлайне.
Сегодня я поделюсь мнением о своём любимом продукте - Я.навигаторе: о том, как деградирует UX за рулем, и каких фичей мне, как водителю, не хватает.
В навигации есть ситуации, которые невозможно честно проверить, не выходя в «поле». Можно написать код, прогнать тесты, собрать метрики — и всё равно получить кейс, когда в жизни геопозиция «зависла», позиция «улетела», а ведение по маршруту начинает жить своей жизнью.
Мы уже рассказывали, почему геопозиция бывает нестабильной и как 2ГИС помогает пользователям в такие моменты. Сегодня выпустили ещё несколько обновлений для улучшения навигации в зонах c нестабильной геопозицией — в том числе внедрили сенсорную (инерциальную) навигацию. В этой статье расскажем, как нам в этом помогли полевые проезды.
Спуфинг и подмена координат превращают gps треки в мусор. За год разработки бэка для сервиса GPS‑мониторинга я прошёл путь от наивных порогов по скорости и высоте до конвейера из двух десятков фильтров.
В статье разбираю эволюцию воздействий: телепорты, заморозка координат, подмена timestamp, самосогласованный спуф с честными скоростями и высотами. Плюс разберу «коллегию адвокатов» для точек по принципу презумпции невиновности — лучше пропустить ложную точку, чем убить реальную и почему конвейер пришлось учить не только резать, но и восстанавливать срезанное.
У меня есть физический радар детектор — коробочка на стекле. И есть купленное приложение-антирадар. Что общего у них двух? В каждом чего-то не хватает. В одном не нравится одно, в другом другое. Годами я ловил себя на мысли, вот бы взять лучшее из обоих, а раздражающее просто не тащить.
В какой-то момент я перестал мечтать и сел писать своё. Наивно думая, что это несложно Ну что там, показывай точку из базы да пикай при подъезде. (Спойлер) Я ошибался почти в каждом своём предположении. Эта статья про то, как «тут же нечего делать» превратилось в фьюжн сенсоров, счисление пути в тоннелях, геодезию проездов и краудбазу с криптозащитой. И про то, чему меня научила каждая набитая шишка.
Приветствую, Хабр!
В этой статье хочу описать практический кейс, который выглядит не как единичная ошибка на карте, а как системная проблема в работе навигационного сервиса от Яндекса. Речь идет о маршрутах в городе Дербент, где одна из дорог была перекрыта еще в марте 2026 года в связи с ремонтными работами (строительство сегмента центральной набережной города). Сейчас уже 23 июня 2026 года, прошло почти 4 месяца, но навигатор продолжает строить маршруты так, как будто проблемы не существует.
На первый взгляд это может показаться локальной городской неудобностью: где-то перекрыли дорогу, где-то маршрут стал длиннее, кто-то потратил лишние несколько минут. Но в реальности проблема серьезнее. Если навигатор отправляет водителей по маршруту, которого физически не существует, или ведет по дороге в таком состоянии, что там можно оставить колеса и всячески игнорирует попытки пользователей внести в маршрут корректировки - это уже не просто неточность данных. Это вопрос безопасности, качества сервиса и способности платформы реагировать на обратную связь.
Дисклеймер: автор делится личным опытом и практическими наблюдениями. Упоминание сервисов и инструментов не является рекламой, продвижением или призывом к использованию.
Я не рассчитывал, что через две недели буду сидеть и писать текст про то, как маркетинг сложнее программирования — звучит как банальность, которую все и так знают. Но когда сам через это проходишь, банальность перестаёт быть банальностью, она превращается в конкретную проблему, у которой нет решения ни в одной документации.
Расскажу с самого начала, заодно покажу цифры и то, что получилось собрать.
Привет, сообщество! Уже долгое время я отмечал на для себя на карте бесплатные парковочные места в центре города; Этот список быстро начал "ходить по рукам" среди друзей и знакомых. Мне пришла в голову идея, а что если развить "списочек для друзей" в какой-то более общественно полезный проект? И с какими техническими челленджами придется столкнуться при попытке навайбкодить мало-мальски production-ready приложение?
Фонд Национальной технологической инициативы реализует проект технологических конкурсов Up Great — открытых соревнований для инженерных команд. Здесь преодолевают технологические барьеры России и мира, чтобы решать задачи, с которыми ещё никто не справлялся.
Один из текущих конкурсов — «Экспедиция. Data Science» с технологическим партнёром Phystech.Genesis, который предоставляет платформу и маркетинг события. В конкурсе участники работают над системами ИИ по распознаванию археологических объектов на поверхности земли и глубине до 5 метров. Пока такую работу археологи делают вручную, что требует много времени и специалистов. Конкурс призван ускорить процесс и исключить человеческие ошибки, чтобы дать исторической науке новые возможности, а учёным — время на экспедиции и раскопки.
В рамках «Экспедиция. Data Science» — 3 конкурса отдельных заданий (КОЗ), а также финальный конкурс. С каждым следующим этапом команды берутся за более сложные задачи и пробуют новые подходы. Недавно организаторы объявили победителей второго из них — «Сканирование». На этом этапе команды создавали нейросети, чтобы искать археологические объекты в рельефе и под поверхностью земли.
В этой статье мы собрали заключения технических экспертов, комментарии профессионального археолога, а также поговорили с тройкой лидеров и одним из ведущих российских учёных по Data Science. Мы хотим рассказать вам, как технология и наука вместе развивают знание людей о мире в нашей стране.
История о том, как я стал туалетным сомелье Минска и создал карту всех местных уборных с расписанием, рейтингом и компасом.
Всем привет!
Одна из самых распространённых операций в сфере пространственной обработки и аналитики данных — это геокодирование. Если кратко, это когда вам необходимо по адресу объекта (например: Москва, Красная площадь, 1) или его названию (Государственный исторический музей) получить географические координаты, то есть понять, где находится это место, или же наоборот — получить адрес по координатам.
В интернете можно найти не одну и даже не один десяток статей, посвящённых сравнению этих сервисов между собой. Но обширных исследований, посвящённых точности возвращаемых результатов, мне найти не удалось. Зачастую проверка делается на небольшом количестве адресов 10–20. Понятно, что при такой выборке полученные результаты не могут претендовать на универсальность во всех случаях.
А даже если мы и определим сервис геокодирования, который в проведённом сравнении даст хороший процент корректных ответов, условно 90%, как при запуске на новых адресах понять, какие объекты были определены корректно, а какие нет? И какая доля корректных относительно всех переданных для геокодирования объектов?
И, честно сказать, это положение вещей меня угнетает…
В данной статье я постараюсь выяснить, какой из сервисов даёт наиболее точный результат в рамках Москвы на примере 2 000 адресов, а также предложу способ проверки полученных результатов.
Бэкенд кое-как держит нагрузку, но от нормальной монетизации автор отказывается из принципа — пока есть только донаты.
Традиционно 1 декабря в 2ГИС включается зимний слой — это особый режим карты, который превращает привычный город в зимнюю сцену: меняются цвета карты, появляются тематические 3D-модели, украшения и анимации. Мы обновляем новогодний слой каждый год, чтобы добавить карте праздничного настроения и создать то самое тёплое ощущение приближающегося праздника...
Можно подумать, а что это летом вдруг вспомнили про снег, ёлки и гирлянды. А всё потому, что готовить магию декабря мы начинаем задолго до морозов.
В этой статье — как переосмыслили новогодний слой 2ГИС. Если вы продуктовый дизайнер и ищете способ наладить совместную работу между дизайном и производством, наш кейс вам точно пригодится.
Это вторая попытка опубликовать статью-туториал, целью которой является знакомство простых пользователей рунета с соверменными возможностями автоматизации своих рутинных задач. Одним из способов решения данной задачи является создание Telegram-ботов. Об этом далее, собственно, и пойдет речь. Хочу отметить, что это только общая вводная часть, здесь не будет представлен код, а только будет рассказ о программном обеспечении, которые мы используем в своей работе. Кроме того, хочу отметить, что статья предназначена для людей, не погруженных в тему и не знакомых с терминологией.
(Всё упоминаемое программное обеспечение в статье не является рекламой, а описывается исключтельно потому, что мы на практике успешно его применяем).
Есть такая городская байка: если угадать правильную скорость, то можно проехать десяток светофоров подряд и ни разу не остановиться, поймав «зелёную волну». Водители из разных городов охотятся за этим ощущением десятилетиями. А мы взяли щепотку данных, немного технологической магии, дизайна и превратили эту байку в работающую фичу в навигаторе 2ГИС.
Меня зовут Даня. Я продуктовый дизайнер команды Транспорт и сейчас расскажу, как мы собирали зелёную волну: от первого скетча до запуска.
Геодезист с тахеометром стоимостью в несколько миллионов рублей приезжает на объект раз в месяц, квартал или год. Проводит все необходимые измерения, обрабатывает полученный результат и фиксирует отклонения, если они есть. А что происходит с башней между измерениями? Солнце нагревает одну сторону опоры и, в процессе деформации металла, отклоняется вертикальная ось. Или налетает штормовой ветер – и, в зависимости от высоты и конструкции башни, отклонения оси от вертикали могут достигать уже десятки сантиметров. При этом радиорелейная связь падает, качество сигнала деградирует, а вы продолжаете искать причину в помехах или оборудовании.
Помочь с этой проблемой может система непрерывного мониторинга, которая работает 24/7, передаёт данные с интервалом от 5 до 60 минут и показывает реальную динамику отклонений с точностью до миллиметра.
Меня зовут Оксана Эйнеш, я руководитель направления «Высокоточное позиционирование» в МТС. В нашей компании эксплуатируются тысячи антенных опор связи по всей России. Мы разработали для них собственную систему контроля деформаций. В этом материале я разберу, из чего она состоит, как работает и зачем вообще нужна, даже если у вас не вышка, а, скажем, дамба или ЛЭП.
Здравствуйте, уважаемые читатели Хабра!
В первой части мы рассказали, как решили задачу сегментации полигона дороги в PostGIS. А теперь рассмотрим сопоставление сегментов двух разных версий дороги для сохранения учёта историчности привязанных к ним событий.
В этой статье рассказываю, почему одной LLM оказалось недостаточно и как мы связали языковую модель с данными, API и интерфейсом геоаналитической платформы.