Геоинформационные сервисы *

Привет, Хабр!

Март прошёл результативно: на площадке в Марфино завершена пусконаладка контейнерного ЦОД, прибыло оборудование холодоснабжения, состоялась приёмка оборудования системы энергоснабжения и т. д. Параллельно продвигается проект в Мытищах — там на повестке проектная документация и переговоры с городской администрацией.

Если вы с нами с самого начала — благодарим за внимание! А если только присоединяетесь, вот архив: раз, два, три, четыре, пять, шесть, семь, восемь, девять, десять, одиннадцать, двенадцать, тринадцать.

В Ташкенте курсируют около 1 800 активных автобусов на 170 маршрутах. Их GPS-координаты поступают каждые 10 секунд. В сутки это составляет порядка 15 миллионов координатных пингов. Но объём – не самая сложная часть.

Настоящая проблема в том, что отдельный GPS-пинг сам по себе ничего не значит. Координата автобуса на заданной широте/долготе не отвечает на вопросы:

80k RPS и 25 Гбит/с трафика тайлов с одного сервера — звучит как мечта для картографического сервиса? На самом деле это реально — если ваш способ отдачи тайлов спроектирован для этого.

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

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

Навигатор при построении маршрута решает масштабную оптимизационную задачу на графах — он работает с дорогами не как с линиями на карте, а со структурой из миллионов рёбер и вершин. Учитываются ограничения движения, текущие и прогнозные скорости, качество дорог и многое другое. 

Недавно в дополнение к самому быстрому и оптимальному мы добавили ещё один вид маршрута — «лёгкий маршрут», наименее стрессовый для водителя. Минимум сложных перекрёстков, поворотов налево и перестроений. 

В статье рассказываем, как мы строим маршруты в целом и как новый вид вписывается в текущую архитектуру маршрутизации.

Baidu Maps — китайский картографический сервис с собственным API. Он активно используется внутри КНР и поддерживает стандартные сценарии: отображение карты, маркеры, полигоны, кластеры.

На первый взгляд интеграция выглядит как обычно. Но при работе с реальными данными появляются отличия. Используется система координат BD-09. Мир не повторяется по долготе. Поведение геометрии отличается от Google Maps и Яндекс Карт.

Привет, я Екатерина Плаксина, фронтенд-разработчик Далее. В этой статье разберу каждую проблему отдельно и поделюсь своими решениями.

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

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

И один лишь рынок особой категории геоданных, именующих себя детьми лейтенанта Шмидта, находится в хаотическом состоянии. Анархия раздирала корпорации вроде Гугла… Ладно, я увлёкся. Но в самом деле…

В первых двух статьях мы разобрали основы спецификации STAC (SpatioTemporal Asset Catalog), её объектную модель и философию, превращающую разрозненные архивы геоданных в единую, машиночитаемую «библиотеку». Мы увидели, как STAC описывает каталоги (catalog), коллекции (collection), элементы (item) и их ресурсы (assets), создавая универсальный язык для работы с геопространственной информацией.

В комментариях были затронуты две темы, которые просили рассмотреть в новых статьях — семантическая паутина и универсальные браузеры, которые требуют постепенного перехода от теории к практике. Действительно, какая польза от идеально структурированного каталога, если с ним неудобно или невозможно работать? Поэтому, прежде чем углубиться в онтологии, мы рассмотрим инструменты взаимодействия с STAC.

Эта статья посвящена клиентской стороне экосистемы — STAC-браузерам, а также ключевому аспекту их работы в корпоративной среде — безопасному доступу к данным через STAC-API. Мы разберём, как устроен универсальный браузер, и представим нашу реализацию стека STAC-сервера с распределённой системой управления доступом IAM (Identity and Access Management), где каждый запрос, от просмотра метаданных до скачивания тайла, проходит через цепочку авторизации.

Работая над архивными фотографиями Сочи, я заметил, что на Pastvu люди иногда годами обсуждают в комментариях, откуда сделан тот или иной снимок. Мне стало интересно: можно ли это вычислить математически? Оказалось, что да. Если на снимке видны три узнаваемых объекта и известны их координаты, задача решается через алгоритм PnP (Perspective-n-Point). Я собрал браузерный инструмент, который делает это автоматически. Первый тест на реальном снимке Сочи дал совпадение с точностью до улицы.

Девятого марта исполнилось бы 92 года со дня рождения человека, который сказал: «Поехали!» - и навсегда изменил историю. В преддверии дня рождения Юрия Алексеевича Гагарина студенты, преподаватели и сотрудники Российского нового университета отправились в Музей космонавтики, чтобы узнать, что привлекает современных молодых людей в эпохе первых полетов.

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

В США NASA выделяет десятки миллионов долларов даже двухлетним стартапам. В России старт космического стартапа почти всегда заканчивается банкротством: SR Space, Dauria Aerospace, КосмоКурс, Lin Industrial, S7 Space… Мы не просто теряем компании: мы теряем огромную возможность войти в новую индустриальную волну, где космос – это не «госпроект с нулевой отдачей», а мощный экономический драйвер с потенциалом рынка более чем 2 ТРЛН долларов к 2035 году.

Каждый доллар, вложенный в космос, возвращает десять — через связь, навигацию, данные ДЗЗ, новые материалы, точное сельское хозяйство — общеизвестный факт. Но российские стартапы не доживают до момента, когда могли бы этот мультипликатор сгенерировать. Интересуясь космосом и являясь инициатором проекта, связанного с космосом, хочу структурировать проблемное поле Deep-Tech проектов.

Так почему же космические стартапы не выживают? Ответ — в системных барьерах.

Моя диагностика: 5 ключевых причин, почему стартапы в российском космосе не выживают

Когда вы прокладываете маршрут в горах в 2ГИС или рассматриваете вид на дом в 3D, вы вряд ли задумываетесь, что под капотом карты происходит серьёзная вычислительная работа. За каждой формой рельефа — тысячи треугольников, интерполяции и алгоритмы, которые превращают цифровую модель местности в реалистичную поверхность.

Впервые рельеф мы добавили в веб‑версию 2ГИС в 2022 году. С тех пор мы не останавливались на достигнутом: доработали алгоритмы, улучшили качество исходных данных, научили дороги и здания влиять на поверхность. А недавно мы выкатили рельеф и в мобильное приложение.

В этой статье расскажем, как мы пересмотрели подход к данным, зачем нам понадобился нерегулярный меш, что общего у RTIN с Делоне и почему даже рельеф иногда приходится «чинить».

 Всем привет! Представьте типичную ситуацию: у вас на руках схема подземных коммуникаций с условными метками. На местности свежеуложенный асфальт, газон и пять потенциальных точек, где нужный колодец может быть в радиусе 5–10 метров — стандартной погрешности GPS. Что делаем? Копаем наугад, тратим часы, портим покрытие, нервничаем.

Проблема не в том, что «карта неверная». Проблема в том, что у нас никогда не было инструмента, чтобы актуализировать ее с точностью до сантиметра. Традиционно такой разрыв закрывался человеко-часами и удачей. Но что делать если у вас под управлением сотни тысяч инфраструктурных объектов в условиях постоянно меняющейся городской среды? 

Меня зовут Оксана Эйнеш, я руковожу направлением «Высокоточное позиционирование» в МТС. И сегодня мы с вами разберем технологию, которая превращает поиск колодца подземной инфраструктуры из лотереи в точную инженерную задачу. 

Речь пойдет о комплексном решении с применением высокоточных ГНСС-контроллеров с поддержкой кинематики реального времени (Real Time Kinematic, RTK). Ниже я расскажу о переходе из плоскости «где-то здесь» к точке «вот здесь».

Делюсь своим опытом и показываю как лучше всего визуализировать данные на картах. Рассказываю про логику цвета и особенности датавиза на нестандартных картах, на примере карты РФ и данным по объявлениям Авито.

Ханты-Мансийский автономный округ (ХМАО) – это не только 50% российской нефти, но и 530 тыс. кв. км лесов. Развитие инфраструктуры месторождений и интенсивные заготовки требуют жесткого контроля вырубок. С 2014 года здесь ведут мониторинг по снимкам со спутников, собрав базу из 15000 записей, включающих информацию о выявленных лесных рубках, но есть проблема: ручное дешифрирование происходит слишком долго и дорого.

13 февраля глобальное сообщество отмечало День радио. Этот знаменательный праздник на мировом уровне начали отмечать совсем недавно, с 2011 года, согласно резолюции 36 C/63 Генеральной конференции ЮНЕСКО. У нас в стране его празднуют вот уже более века, а сама дата приурочена к 25 апреля (7 мая) 1895 года, когда российский физик Александр Степанович Попов на заседании Русского физико-химического общества продемонстрировал «прибор, предназначенный для показывания быстрых колебаний в атмосферном электричестве».

Если обратиться к традиции русской сказки или мифа, можно обнаружить несколько «гаджетов-путеводителей» и смежных с ними «устройств»: волшебный клубочек, яблочко на блюдечке, сапоги-скороходы, нить Ариадны. Человек на протяжении многих веков нуждается в ориентирах, которые помогут ему не просто передвигаться в направлении, но и делать это безопасно и с экономией ресурсов (чтобы быстрее добраться до тридесятого царства, сносить меньше железных сапог, сгрызть меньше хлебов и т.д.). Времена и технологии меняются, а потребности всё те же: как максимально эффективно объехать точки клиентов, доказать, что ты действительно работал и сразиться со злым драконом в случае необходимости доказать, что клиент врёт в ожидании возврата оплаты по принципу «а вдруг прокатит», потому что вот, факт нахождения на точке зафиксирован, фото поломки и факта ремонта приложены. Одними картами здесь не обойтись: нужно приложение, которое будет удобно работать с заказами, заявками, маршрутами и поможет человеку в самых неожиданных ситуациях.  

Раньше маршруты на Картах ранжировались по времени в пути: работал принцип «самый быстрый — самый первый». Но в реальном мире скорость не всегда равна удобству и пользователь мог оказаться в ситуации, что маршрут вроде бы позволяет добраться до конечной точки быстрее, но придётся долго разбираться, а куда вообще ехать. 

Теперь ранжированием маршрутов занимается ML‑модель, которая обучена на реальном поведении пользователей. Она учитывает не только время, но и то, по каким маршрутам водители доезжают до конца. Поэтому сейчас первый вариант — тот, который вы, скорее всего, выбрали бы сами.

Я Илья Хохлов, руководитель службы разработки сервисов маршрутизации. Наша команда отвечает за ключевые алгоритмы навигации в Картах и в Навигаторе: маршрутизацию, прогноз времени в пути и позиционирование. В этой статье я расскажу о том, как мы переосмыслили ранжирование маршрутов в навигации на Картах и в Навигаторе: как именно ML‑модель понимает, какой маршрут предлагать первым, и как это решение повлияло на количество сходов с маршрута.

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

В мировой практике ДЗЗ в построении архитектур наземных сегментов (НС) космических систем можно условно выделить три периода:

1) 1990s: One-Off System (условно, НС под конкретный КА) - Уникальные, "штучные" системы. Каждый спутник имел свой собственный, специально спроектированный наземный сегмент: уникальные приемные станции, центры обработки, формат данных, ПО. Нет совместимости. Типичный пример: ранние миссии Landsat, SPOT, ERS.

2) 2000s: Common Ground Architecture (условно, НС под серию КА) - Единая базовая архитектура. Появление стандартов (например, CCSDS). Агентства (как ESA с их "Generic Ground Segment") создают повторно используемые компоненты и инфраструктуру, на базе которых можно относительно быстро разворачивать сегменты для новых миссий. Снижаются затраты и сроки. Многие миссии ESA и NASA этого периода строятся на общих принципах и программных компонентах.

3) 2010-2020s: Mission Independent Architecture (многоцелевые унифицированные) - Архитектура, независимая от миссии. Это концептуальный скачок. Вместо того чтобы адаптировать наземный сегмент под миссию, данные миссии адаптируются под универсальную, уже существующую наземную платформу. Ключевые принципы: виртуализация (абстрагирование от физического "железа"), сервисно-ориентированная архитектура (SOA), стандартизация интерфейсов и метаданных (чтобы любая миссия могла "подключиться" к платформе). Цель: Обрабатывать данные от множества разнородных миссий на одной инфраструктуре, обеспечивать гибкость, масштабируемость и быстрый доступ пользователям.