Как я построил городской справочник по типу 2ГИС с нуля: кейс AlexMap для Куско

Идея AlexMap возникла из простой бытовой проблемы: в Куско — городе с большим потоком туристов и активной локальной жизнью — не было ни одного удобного цифрового справочника заведений. Гость города не мог быстро найти ближайшее кафе, аптеку или прачечную самообслуживания на одной карте с фильтрами. Местные жители пользовались обрывочными данными из разных источников — где-то устаревший список в соцсетях, где-то рекомендации в чатах, где-то просто спрашивали у прохожих. Владелец идеи хотел собрать это в единую платформу, но с нуля, без готовой карты заведений и без опыта, как вообще устроен продукт такого масштаба технически.

Проблема: город без единого справочника заведений

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

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

Карта, кластеры и рубрикатор

Ядро платформы — интерактивная карта на Leaflet с кластеризацией заведений: когда точек много и они близко друг к другу, карта автоматически группирует их в кластеры с числом заведений внутри, а при приближении кластер распадается на отдельные метки. Это стандартный приём в сервисах типа 2ГИС, без которого карта с несколькими тысячами точек превращается в нечитаемое месиво меток.

Вокруг карты я построил рубрикатор из 24 топ-категорий (рестораны, отели, транспорт, медицина, красота, магазины и так далее) и 18 подрубрик внутри них для более точной навигации. Пользователь не листает бесконечный список всех заведений города, а сразу сужает выбор до нужной категории и подкатегории — это резко ускоряет поиск нужного места, особенно для туриста, который не знает город и не может сформулировать точный запрос.

Поиск, фильтры и геолокация

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

Быстрые фильтры решают конкретную практическую задачу: "открыто сейчас" отсекает заведения, которые в данный момент закрыты, экономя пользователю время на звонки и уточнения. Фильтры по удобствам — доставка, Wi-Fi, парковка, оплата картой и другие — позволяют сузить выбор под конкретную потребность, а не просто "показать все рестораны в районе".

Функция геолокации "где я" определяет текущее положение пользователя и показывает расстояние до каждого заведения в списке результатов, сортируя по близости. Для туриста, который ориентируется в незнакомом городе по телефону, это едва ли не самая используемая функция всего приложения — она превращает абстрактный список в конкретный маршрут "куда идти прямо сейчас".

Админка модерации и готовность к масштабированию

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

Самое важное архитектурное решение проекта — мультигород и мультиязычность заложены не как доработка "на будущее", а как часть структуры данных с первого дня разработки. Это означает, что база заведений с самого начала привязана к конкретному городу как отдельной сущности, а не жёстко зашита в код под Куско. Точно так же каждая карточка заведения и весь интерфейс поддерживают испанский, английский и русский языки на уровне структуры, а не как надстройку поверх готового интерфейса.

Практическое следствие этого решения: чтобы запустить AlexMap в новом городе, не нужно переписывать код платформы — нужно только наполнить базу данными нового города через ту же админку. Это принципиально отличается от ситуации, когда мультигород добавляют задним числом в систему, изначально спроектированную под один город, — тогда обычно приходится переделывать структуру базы данных и половину логики фильтрации.

Технически стек построен на связке FastAPI и асинхронного SQLAlchemy на бэкенде, React и Leaflet на фронтенде для публичного сайта и отдельной панели администратора. Такой выбор даёт достаточный запас производительности при росте числа заведений в базе и гибкость для добавления новых фильтров или категорий без переписывания ядра системы.

Результат для платформы

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

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

Кому подойдёт такое же решение

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

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

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

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

Частые вопросы

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

Как проверяется актуальность информации о заведениях — например, что оно всё ещё работает? За это отвечает процесс модерации: изменения от пользователей и партнёров проходят через админ-панель, где модератор подтверждает или отклоняет правки, прежде чем они появятся в справочнике.

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

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

Коротко о главном

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