Сбор организаций с пяти карт в Dubai Mall

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

Обычный сценарий кажется достаточным: открыть известную карту, поставить максимальный масштаб и собрать всё видимое. Карта объединяет несколько каталогов и алгоритмов. Одни организации появляются только через карточку здания, другие — в категорийном поиске, третьи — после отрисовки маркеров. Даже формально завершённый статус (terminal) не гарантирует, что был раскрыт нужный слой.

Мы проверили это на Dubai Mall с помощью CrawlRover. Сначала для каждой из пяти карт собрали сильный воспроизводимый профиль, затем повторили попытки и отдельно поискали уже известные организации на других картах. Главный результат оказался коммерчески важнее простого рейтинга: комбинация источников и методов дала Google 1059 дополнительных внутренних идентификаторов карты (native ID) сверх сохранённого контроля 449, а Bing — 638 сверх контроля 291. Строго внутри исходного контура находились 840 и 504 дополнительных ID соответственно.

Это не оценка полного каталога Dubai Mall и не число действующих арендаторов. Это измеренный ответ на практический вопрос: сколько проверяемых записей остаётся за пределами лучшего сохранённого сценария, если использовать сигналы других карт.

Три результата, которые меняют стратегию сбора

Ценность CrawlRover — проверяемый реестр, в котором для строки можно восстановить карту, метод, исходную карточку, границу попытки и причину ручной проверки. Такой результат можно принять по критериям и повторить, а не просто поверить итоговому числу.

Материал особенно полезен трём типам команд:

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

Что именно сравнивалось

У опыта три разных уровня, и смешивать их нельзя.

Первый — наблюдаемый профиль карты: сколько пригодных карточек даёт конкретная конфигурация на фиксированном контуре. Второй — вклад механизма: какие записи внутри одной карты впервые дали search, render или building. Третий — перекрёстная проверяемость: находится ли уже известная группа на другой карте и каким terminal-исходом заканчивается поиск.

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

Как устроен опыт

Контур состоит из 19 вершин. Его SHA-256 — 5f3474ff215276fe4f7b0e94da76e13f13c0cc3bfa4155a224510b254c6d5c31. Для Яндекса и Google использован z21, для 2ГИС и Apple z20, для Bing z19. Каждое доступное плечо запускалось дважды; на попытку действовал предел 90 минут. Рабочий бюджет составлял 24 800 POI, ещё 6200 POI нельзя было затрагивать (C-EXT-15).

Плечо A включает площадные методы карты без явного запроса. Плечо B отдельно перебирает полный поддерживаемый набор категорий у Яндекса, 2ГИС и Google. Такое разделение не умножает дорогой render или обход здания на десятки запросов. У Apple и Bing внутренний категорийный перебор уже входит в площадной путь, поэтому второй идентичный B им не нужен.

Сначала мы заморозили сырые карточки, native ID и журнал методов. Только после этого построили 20 направлений source → target (C-EXT-06). Одинаковая canonical group ищется на одной целевой карте один раз, даже если связана с несколькими исходными строками. Так сохраняется логика всех направлений и не расходуется квота на дубликаты.

Попытка считается полной, когда все запланированные методы дошли до terminal. Limited означает, что сработал заранее заданный предел времени или доступности. Такой результат остаётся полезным для планирования, но не сравнивается с полным как равный по экспозиции.

Почему карты нужно комбинировать: пять разных ролей

Ни одна карта в этом опыте не оказалась лучшей по всем нужным свойствам. 2ГИС дал масштаб через каталог здания, Apple — хорошо заполненные адреса и контакты, Google — отдельные слои категорий и render, Яндекс — organization/house-каталоги, Bing — дополнительный фронтир и структурированные поля при направленном поиске. Практическое решение состоит не в выборе одного победителя, а в назначении каждой карте роли и контроле её ограничений.

2ГИС: основа объёмного реестра через здание

Площадной запуск 2ГИС на z20 завершился за 260,1 секунды и сохранил 1930 unique native rows. Со старым опытом на z17 совпали 1857 ID; 73 появились, 64 не повторились, Jaccard равен 0,9313 (C-EXT-01).

Категорийное плечо принесло 322 строки, но 320 из них уже были в площадном наборе. Полный первичный профиль вырос только до 1932 native rows (C-EXT-14). Для этого объекта основной масштаб 2ГИС дал building-путь, а широкий поиск добавил мало новых идентификаторов.

Есть существенная оговорка. В первичной попытке 1172 строки были эксклюзивно связаны с building_inside, ещё четыре — с карточным методом. Историческая методная провенанс покрывала 100% строк, но observation именно текущего запуска — 62,2%. Поэтому мы можем объяснить провайдера и native ID каждой строки, а метод этого запуска — только для измеренной доли (C-EXT-07).

Яндекс: видимый слой может скрывать каталог организации

Первичный площадной запуск Яндекса прошёл пять сегментов и 1118 ячеек, но сохранил ноль seed-карточек. Обход здания не стартовал, потому что ему неоткуда было получить исходный адрес или организацию. Это не означает, что каталог Dubai Mall в Яндексе пуст. Результат говорит точнее: render на z21 не сформировал входной фронтир для следующей фазы (C-EXT-02).

Категорийное плечо дало 197 уникальных карточек и завершило 33 из 33 запросов. В повторе встретились те же 197 ID, Jaccard равен 1,0000, хотя одна дочерняя сессия закончилась partial и сравнение осталось описательным (C-EXT-10, C-EXT-11).

Эти 197 — замороженный результат категорийного плеча B, а не лучший возможный выход Яндекса по Dubai Mall. После проверки прямой ссылки «Внутри» выяснилось, что DOM показывал 197 уникальных ссылок на организации, тогда как структурированный SSR- каталог содержал 1233 записи с 1233 уникальными OID. Видимое рядом число 550 относилось к фотографиям.

Диагностика обнаружила системный дефект в CrawlRover: parser читал прежний envelope response.items, но не текущий results.items.fullPlaces, а обход карточки сохранял house-route и отбрасывал прямой organization-inside route. Мы добавили оба пути, оставили закрытым недоказанный fallback по обычным ссылкам и повторили продуктовый замер.

Для честной проверки исправления использован тот же пользовательский 20-вершинный контур, z17 и набор render+building без поиска. До исправления сессия 348 дала 363 строки. После исправления сессия 351 завершилась за 46,0 секунды и сохранила 1605 строк. Внутри результата было три organization-контейнера и восемь house-targets; каталог Dubai Mall добавил на checkpoint все 1233 OID. У 1200 строк сохранилась атрибуция этого organization-контейнера, ещё 33 совпали по native OID с более богатыми house-карточками и были объединены (C-EXT-17).

Коррекция не подменяет замороженную таблицу FMX-20260912: там был другой, 19-вершинный контур и z21. Число 1605 описывает дедуплицированный выход выбранной территории, включая соседние organization- и house-контейнеры; 1233 описывает каталог по точной ссылке Dubai Mall. Ни одно из чисел не является независимой оценкой действующих арендаторов.

Самый сильный урок дал повтор A. Первичная попытка вернула ноль, повторная — 828, Jaccard равен нулю (C-EXT-10). Одинаковый terminal сам по себе не доказывает устойчивость состава. Для коммерческого сбора Яндекс стоит сочетать категорийный поиск, render и доказанные organization/house-каталоги, а результат подтверждать повтором с сохранёнными native ID и маршрутами происхождения.

Google: render и категории открывают разные части каталога

Площадной профиль Google на z21 оказался дорогим. В первом полностью завершённом сегменте grid добавил 13 записей, render — ещё 95, а обход 175 зданий не дал новых. Оставшиеся сегменты не получили равной экспозиции, поэтому весь A имеет статус limited (C-EXT-03).

Категорийный primary успел пройти только первый из 32 запросов, но сохранил 369 карточек. Объединённый профиль A+B содержит 476 строк: 346 встречены только в B, 107 — только в A и 23 — в обоих плечах (C-EXT-14). Если оставить один поиск или один render, клиент потеряет другую наблюдаемую часть реестра.

Повтор категорийного плеча сохранил 368 строк; его Jaccard с primary равен 0,9759 при статусе descriptive_limited (C-EXT-10). Это не оценка всего словаря категорий: обе попытки ограничены первой достигнутой частью очереди.

Apple: сильная база адресов и контактов

Apple на z20 сохранил 1803 unique native rows. Search наблюдался у 1730 строк, building_inside — у 359, render — у пяти. Эксклюзивный вклад составил 1443, 72 и одну строку соответственно. Со старым z17 совпали 470 ID, появились 1333 и выпали 791; Jaccard равен 0,1812 (C-EXT-09).

Для клиентской таблицы особенно важны поля: имя заполнено у 100% строк, адрес и категория — у 99,9%, телефон — у 79,8%, сайт — у 64,5% (C-EXT-14). Apple выглядит полезным источником контактов, но низкое совпадение со старым набором запрещает называть весь прирост улучшением. Профиль limited, а его состав заметно изменился.

Bing: обнаружение через render, затем проверка деталей

Bing на z19 сохранил 224 строки. Render наблюдался у 212, search — у 24; эксклюзивно они дали 200 и 12 строк. Со старым z17 совпали 83 ID, добавились 141 и выпали шесть; Jaccard равен 0,3609 (C-EXT-08).

Категория и координаты заполнены у 100% строк, но имя и адрес — у 25,4%, телефон — у 10,3%, сайт — у 10,7% (C-EXT-14). Роль Bing в таком проекте — расширить список кандидатов. Для самостоятельного контактного реестра его строки требуют проверки на другой карте или вручную.

Что изменилось после проверки алгоритмов на живой карте

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

Apple C5 на z20 сохранил 1785 карточек: 811 впервые пришли из поиска, 669 — из рендеринга, 305 — из каталогов зданий. Метод render наблюдался у 730 карточек и самостоятельно добавил 37; building самостоятельно дал 195. Все 304 render-ячейки прошли, 80 из 81 адресного seed проверены exact-запросами, а каждая из 1785 строк получила сессионный след происхождения. Первичные пять render-карточек оказались следствием ошибки привязки видимого слоя к viewport. Географическую границу тоже уточнили: найденные только поиском записи за контуром лежат в пределах 9,66 м; каталог здания, пересекающего зону, содержит и организации вне контура. Для реестра их надо помечать как членство в здании, а не как точку строго внутри полигона.

Bing C4 на z19 сохранил 291 карточку: 212 впервые получены из render, 79 — из поиска. Контроль 86 render-ячеек завершился без ошибки. Ранее 24 адресные проверки попадали в mismatch без единого fallback-запроса; после исправления запросы заработали, но первый пакет вытеснял проверки следующих адресов. Теперь все 13 доказательных адресных seed проходят exact до 31 ограниченного recovery-запроса. Числовые grid-подписи больше не принимаются за улицу и дом. Поиск внутри зданий пока не добавил организации: Bing не подтвердил эти адреса с нужной точностью и дистанцией, а бюджет закончился. Для клиента это значит, что Bing стоит использовать для обнаружения кандидатов и независимой проверки на другой карте, с явным статусом неподтверждённого адреса.

Google C2 завершил на z21 первый сегмент с 110 карточками: 13 впервые нашёл поиск по сетке, ещё 97 — render. У всех 110 строк сохранён метод именно этой попытки; 115 render-ячеек подтвердили покрытие без сбоя, а завершающий счётчик показал 110 вместо ошибочного нуля прежней версии. Проверка 175 адресов в зданиях не дала новых карточек. Полный grid-обход зоны прогнозировался в 288,7 минуты уже после первых 20 ячеек при установленном лимите 90 минут. Поэтому мы завершили все методы первого сегмента, а четыре оставшихся остановили по заранее заданному правилу. Это завершённый сегмент и ограниченный профиль всей зоны; его 110 строк не называют всем каталогом Google для Dubai Mall.

В ходе этого же прогона родительская задача была ошибочно отмечена как зависшая через две минуты, хотя дочерний сегмент продолжал собирать строки и завершился. Причину нашли в стороже: он учитывал прогресс детей не для каждого вида сегментированного запуска. Логика исправлена и проверена на реальном хранилище задач. На финальной версии 5.623.162 родитель повторного короткого запуска остался рабочим и после 166,8 секунды собственного простоя при живом дочернем сегменте; всю группу штатно остановили. Эта ошибка статуса не потеряла ни одной из 110 строк завершённого исследовательского сегмента.

Подробные сессионные числа и хэши исходных выгрузок приведены в analysis/apple-bing-google-post-fix-correction.json. Они являются отдельной коррекцией и не изменяют исходные 1803/224/130, объединение пяти карт и результаты направленного поиска. Разные масштабы и методы не позволяют называть отношение 1785/291/110 рейтингом полноты карт.

Большой счётчик без повтора вводит в заблуждение

Повторы измерялись по совпадению native ID внутри одной карты и одного плеча. Jaccard 2ГИС A равен 0,9674, Apple A — 0,9842, Bing A — 0,9032, Google A — 0,6947, Яндекс A — 0. Для категорийных плеч 2ГИС получено 0,8736, Яндекс — 1,0000, Google — 0,9759 (C-EXT-10).

Высокое значение ещё не превращает partial в полный профиль. Оно показывает стабильность наблюдавшегося ядра. Низкое значение не всегда означает плохую карту: причиной может быть изменившаяся экспозиция метода, динамическая выдача или разный входной фронтир. Именно поэтому CrawlRover сохраняет ID, метод, статус и границу попытки, а не только итоговый счётчик.

Самая ценная проверка: что Google и Bing находят по сигналам других карт

Площадной сбор отвечает на вопрос «что показала карта в этой конфигурации». Направленный поиск проверяет более близкий к клиентской задаче сценарий: если организация уже известна по 2ГИС, Apple или Яндексу, найдёт ли её Google или Bing и какие собственные поля целевая карта добавит в реестр.

Мы не стали переносить проценты маленькой выборки на всю территорию. Для Google и Bing исполнили все шесть направлений 2ГИС / Apple / Яндекс → Google / Bing по протоколу FMX-DL-20260915. Площадной повтор Яндекса расширил заморозку до 6678 физических запросов и 8622 логических позиций. Все 6678 задач получили terminal: 2069 завершились succeeded, 639 связей уже существовали к исполнению, 3187 дали not_found, 753 направлены человеку и 30 нельзя было запросить без имени.

Повтор A дал 828 Yandex OID, категорийный B — 197; пересечение равно 72, объединение — 953 OID, из которых 897 образовали организационные canonical-группы. Поэтому 197 нельзя считать лучшим результатом Яндекса по этой зоне.

Исходные карты пересекаются: одну карточку Google или Bing могли подтвердить сразу несколько источников. После дедупликации Google получил 1059 разных native ID сверх сохранённого контроля A∪B из 449 ID. Из них 840 имеют координату Google строго внутри контура, 218 — снаружи, у одной точка не измерена. Bing получил 638 разных native ID сверх контроля C4 из 291 ID: 504 внутри, 133 снаружи, одна без измеренной точки. Внутренний слой увеличивает наблюдавшийся набор Google с 449 до 1289 ID, Bing — с 291 до 795 ID. В коммерческом проекте внешний слой передаётся отдельно, а не подмешивается в территориальный результат.

Множественные источники подтвердили 536 дополнительных Google ID и 345 Bing ID — их можно проверять раньше одиночных сигналов. Среди дополнительных Google-карточек собственные поля Google дали имя для 1058 ID, адрес для 452, категорию для 564, телефон для 385 и сайт для 337. У Bing имя, адрес и категория есть у 637, телефон у 582, сайт у 504. Google сильнее расширил наблюдаемый фронтир, а найденные через Bing строки чаще сразу содержали структурированные контакты.

Это сравнение показывает прирост относительно лучших сохранённых запусков инструмента. Оно не превращает карту-цель в эталон и не оценивает полноту её каталога. Not_found означает отсутствие результата конкретного поиска, а не отсутствие организации в реальности.

Почему этим исходам можно доверять

Эксперимент также обнаружил два системных дефекта Google-пути. Родительский таймер закрывал рабочую вкладку раньше завершения внутреннего render/reload цикла, а штатный экран пустой выдачи ошибочно считался неготовой страницей. В 5.623.169 вкладка живёт до возврата коллектора, Stop по-прежнему прерывает работу, а пустой результат признаётся только по собственному same-origin переходу Google Maps в /search?q=.... Все 26 прежних технических исходов повторены по исходным runId/unitId: 1 дал совпадение, 25 завершились доказанным not_found; новых retryable и обращений к закрытой вкладке нет.

Для Bing отдельно проверены 55 случаев, где после отрицательного matcher-исхода позднее появилась native-связь. В 29 физических задачах побочный discovery увидел её во время того же lookup; 29 случаев повторены на исправленной логике: 24 завершились без ошибочной связи, 5 направлены человеку. Ещё 6 связей появились в другой задаче или позже, а для 20 полный raw-механизм появления не установлен. Неизвестное происхождение не засчитывается как успех текущего поиска.

До сплошного census была зарегистрирована малая выборка: по 20 отсутствующих связей в каждом из 20 направлений. Все 399 уникальных физических задач получили terminal или reconciled identity outcome. Она показала сильную асимметрию направлений, но интервалы при 19–20 наблюдениях были слишком широкими. Поэтому выборка использована только для решения, какой полный прогон запускать, а не для маркетинговой экстраполяции (C-EXT-06).

Откуда карта получила данные

Здесь нужны два разных ответа. Первый: какую карту и какой метод CrawlRover наблюдал. Его дают provider-native row и acquisition observation. Второй: кто был первоначальным поставщиком конкретного поля. Его можно назвать только при явной атрибуции карточки.

Например, Apple публикует общий список поставщиков Maps, а Google требует обрабатывать per-place и photo attribution по политике Maps JavaScript API. Яндекс описывает attr:Attribution в структуре YMapsML, Microsoft ссылается на credits Bing в разъяснении об ODbL, 2ГИС — на проверку сведений, которые сообщают представители и пользователи, в справке о добавлении компании.

Общий список поставщиков описывает экосистему карты, но не позволяет приписать им адрес или телефон каждой строки. В опыте посчитаны только сохранённые externalProvider, ratingSource, host фотографии и другие явные связи. Если такого поля нет, источник поля остаётся неизвестным (C-EXT-13).

Такой строгий фильтр всё же находит конкретные связи. В Apple-карточках явно указаны, например, Foursquare у 183 строк, TripAdvisor у 122 и Zomato у 76. В Bing четыре рейтинга прямо связаны с Tripadvisor и один с Booking.com; для отдельных фотографий сохранены их host. Эти числа относятся только к явно размеченным карточкам и полям и не распространяются на остальной набор (C-EXT-13).

Что покупает клиент: проверяемый реестр с критериями приёмки

В таком проекте ценность создаёт не число строк само по себе. Нужен набор, по которому можно принять решение и объяснить каждую неопределённость. Для этого карты получают разные роли: 2ГИС формирует объёмный building-слой, Apple усиливает адреса и публичные контакты, Google добавляет категории и render, Яндекс раскрывает organization/house-каталоги, Bing расширяет и структурирует фронтир направленного поиска.

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

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

Для постановки пилота достаточно четырёх входов:

1. целевой объект или полигон;
2. обязательные поля и назначение реестра;
3. собственная исходная таблица, если её нужно проверить или дополнить;
4. допустимый объём ручной проверки и требуемая дата актуальности.

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

Граница вывода

Опыт проведён на одном контуре и в одной браузерной сессии. Четыре из пяти первичных профилей имеют ограниченную экспозицию, карты меняются во времени, а canonical match не является независимой истиной (C-EXT-04). Мы не проверяли офлайн-статус арендаторов и не называем результат полным каталогом Dubai Mall.

Зато эксперимент показывает то, что можно проверить и повторить: конфигурацию, native ID, вклад методов, заполненность полей, устойчивость, направленные поисковые исходы и границы каждой попытки. Именно из этих доказательств строится реалистичная поставка клиенту, а не обещание получить «всё» одной кнопкой.

Готовы попробовать на своей задаче?

Бесплатный тариф — совместимый пакет магазина, базовый экспорт, без карты

Связанное:

→ Кросс-карта: одна задача, несколько карт→ Найти готовую базу на других картах