1000 объектов, React и Claude: как я сделал интерактивную карту завода не будучи программистом

С чего всё началось

Полтора года назад я устроился в компанию на газохимический проект. Масштабы стройки произвели на меня большое впечатление. Стал постепенно осваивать новую для себя сферу деятельности. В плане цифровизации, приятно удивил уровень оснащения рабочих мест. Хорошие офисные ноутбуки, разного рода программные комплексы, в целом удобные и достаточно быстрые системы управления проектами. Впервые увидел систему Sarex. Первое время разглядывал аэрофотоснимки за разные периоды в обнимку с генпланом и пытался понять, где что находится. Стало понятно, что объектов непросто много, а очень много, к тому же они достаточно плотно расположены. Стоит отметить, что благодаря Sarex сложилось более или менее четкое визуальное представление о заводе и его масштабах. Разработчикам этой системы отдельное спасибо. Но проблема поиска местоположения объектов обозначилась сразу.

В целом работа шла хорошо, до того момента, пока не звонил телефон. Часто при разговоре могло звучать название объекта, либо его цифровая маркировка.

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

Тут и выявилась проблема отсутствия единого понимания о расположении объектов на территории завода. Которую, как уже упоминалось выше, можно было выразить вопросом: «Где это находится?». Вопрос как выяснилось непростой и важный, особенно для предприятия площадью несколько квадратных километров с множеством объектов, в режиме круглосуточной стройки, словно муравейник, с числом строителей, как в небольшом провинциальном городке нашей необъятной страны.

Поиск объекта осуществлялся по генпланам, выгрузкам excel с названиями объектов, звонкам специалистам. При этом процесс поиска растягивался во времени.

Руководитель поставил задачу: сделать удобный инструмент для поиска объектов. Так все и началось.

Перед повествованием, хочу отметить ощущение, которое время от времени сопровождало меня в недавнем прошлом. Это ощущение в формате: «это кто-то должен был уже сделать» -, или: «Как так, важный объект, всё вроде есть, а такой простой и нужной программы/инструмента с территориальной информацией - нет, а должна быть. Где?».

Первая идея: PDF-шахматка и почему она не сработала

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

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

Попытались нанести обозначения объектов, так называемые титулы (они в виде нескольких цифр) на шахматку. От данной идеи также пришлось отказаться по ряду причин:

1. Большое количество объектов на единицу площади. Получилось, что можно нанести только крупные объекты, либо зоны. Об отметках оборудования, допустим рядом с сооружениями, речи вообще не идет.

2. Трудности с оформлением. Это было до знакомства с QGIS, поэтому как красиво оформить, даже не стал разбираться.

3. Обновление изображения (подложки). Объекты на заводе росли как грибы. Замена подложки до окончания строительства – периодический процесс. В случае с PDF, мне показался трудоемким в части качественного переноса на новое изображение сетки и обозначений объектов. Хотя опять же с применением геоинформационных систем, типа QGIS, или АrcGIS, данный вопрос снимается.

4. Размер PDF. Качественное изображение такой площади с векторной информацией весит около 300 мегабайт. При том, даже версия в 30 – 40 мегабайт грузится достаточно долго и может зависать.

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

6. Трудности в отображении удаленных объектов от территории предприятия. Нужно рисовать отдельные окна.

7. Поиск объектов предполагает две операции:

• поиск титула по названию в таблице Excel;

• поиск по титулу местоположения, который нанесен на PDF.

Этих аргументов мне было достаточно, чтобы оставить формат PDF только для печати готовых экземпляров территории завода, или отдельных производств размером А0 и А1.

Знакомство с ГИС: QGIS, ArcGIS, NASA WorldWind

Внимание переместилось на ГИС приложения. Постепенно более четко стали оформляться и требования к будущей карте. В прошлом я имел дело с геоданными. Выгружал их с навигатора, заливал в Google Earth и другие приложения. Было некоторое смутное представление о том, что изображение (карта) может формироваться в зависимости от масштаба, что существуют тайлы, что точка на карте может содержать некоторую информацию, помимо координат и названия.

Поиск снова осуществлялся исходя из парадигмы готового решения. Без какой-либо стратегии и системного подхода изучал программы: QGIS, ArcGIS, NASA WorldWind.

Как-то следуя по навигатору, размышлял о том, как разработчики смогли создать Google карты, Yandex карты, 2GIS. С этими мыслями я обратился к ИИ.

Так началось моё погружение в мир нейросетей, приобретение навыков разработки кода с помощью ИИ без глубокого знания языка программирования (вайбкодинг) и поиска архитектурного решения для будущего ГИС приложения. Погружение не было ровным и плавным. Оно было зигзагообразным, с психами и частыми разочарованиями. Проблески маленьких успехов, мгновениями мелькали в ледяном океане суровой реальности и тут же угасали.

Работа по поиску архитектурного решения была продолжена. Для расширения знаний в области создания карты завода я использовал нейросети. Начал с отечественных: Алиса и GigaChat. Параллельно использовал DeepSeek. Также просматривал видео в YouTube.

На данном этапе внимание было сосредоточено на ГИС программах: QGIS, ArcGIS, GeoServer и NASAWorldWind. Был проведен сравнительный анализ. По его итогам, рабочей средой для составления содержимого карты и создания тайлов, стало приложение QGIS. Причины выбора: открытая лицензия, бесплатное использование (сделал небольшой донат в знак уважения команде разработчиков), есть понятные материалы на YouTube, множество поддерживаемых форматов, возможность работать офлайн.

Подготовка данных в QGIS

В QGIS в качестве подложки добавил Satelite googleMap. Позже для нарезки тайлов использовал Yandex Satellite, так как там есть более поздние спутниковые снимки местности. К этой подложке привязал ортофотоплан завода, взятый из Sarex. Получилась фотография завода на спутниковой подложке.

Несколько слов о подложках. Satelite googleMap и OpenStreetMap были выбраны в качестве «базовых» слоев по причине того, что они бесплатны и не возникало проблем с отдачей тайлов. С Yandex Satellite ситуация совсем другая. Определенное количество запросов бесплатное, а дальше нужно платить. Esri (Environmental Systems Research Institute) также условно бесплатная, но по информации из интернета при коммерческом использовании есть ограничения. Также важно обращать внимание на системы координат. Забегая вперед, отмечу, что для работы в приложении были выбраны именно Satelite googleMap и OpenStreetMap, потому что ни разу не возникло проблем отдачей тайлов. При подключении Yandex Satellite, тайлы переставали загружаться уже через несколько минут плюс к этому у Yandex используется другой подход в системе координат.

Пришла идея пришить генплан к ортофотоплану завода по точкам, сделав его полупрозрачным. Для этого, генплан в формате .dwg, я перевел в формат .dxf и попытался натянуть на подложку. Из этого ничего не получилось. Не по 6, не по 26, не по 46 точкам, объекты на генплане никак не хотели вставать вровень с объектами на подложке. С переносом названий и обозначений тоже возникли трудности.

Названия и обозначения на генплане формата .dxf в nanoCad отображались вполне удобно и читабельно. Но при попытке переноса в QGIS, названия превращались в точки, которые нормально отобразить на подложке так и не удалось. Поэтому эту идею пришлось тоже оставить.

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

Следующим этапом, стало нанесение точек в QGIS в соответствии с генпланом. Cлева на экране был генплан, а справа приложение QGIS с определенной областью. Процесс этот был непростой. Оказалось, что на генплане объекты как бы все, но обозначения есть только на части зданий и сооружений. Если бы они были нанесены все, то понадобился бы микроскоп. Часть объектов пришлось собирать с локальных планов рабочей документации.

Все эти точки составляли слои, они же базы данных. Порядок их был таким. Для зданий и сооружений был создан векторный слой «Объекты». Для ключевого и крупноузлового оборудования слой «Оборудование». Для эстакад соответственно слой «Эстакады горизонтальные», которые расположены с запада на восток и «Эстакады вертикальные», которые расположены с севера на юг. Для дорог, слой «Дороги». Нарисовал сетку с квадратами, буквы и цифры к ней, как на шахматной доске. Сразу стоит отметить, что называть слои нужно латинскими буквами. В дальнейшем при «обёртывании» в react и сборке в приложение, это облегчает жизнь и уменьшает количество возможных ошибок. В атрибутах можно писать все что угодно, но названия баз данных должно быть на английском языке. Для дальнейшего использования, все слои были сохранены в формате GeoJSON.

Для каждого слоя, я сделал свое оформление. Позже узнал, что можно делать оформление самому в формате svg и загружать его в QGIS. Но на тот момент, я использовал функционал QGIS.

Завершив работу со слоями, было ощущение, что работа подошла к концу. В мыслях мелькали восхищения коллег, признание и повышенная премия. Но это было очередное заблуждение. Насмотревшись видео с красивым результатами, я совсем поверхностно, а иногда совсем не читал документацию, т. е. руководство пользователя на модули. Оказалось, что QGIS это не пылесос, а нейросети не дают исчерпывающего ответа на любой вопрос и руководство пользователя читать нужно, если ты хочешь сделать что-то за неделю, а не за полгода.

В моем случае я думал, что модуль в QGIS Export to web map с кликом на пункте Leaflet волшебным образом сделает мне карту. Естественно, этого не произошло. При попытке создать карту программа просто зависала и ничего не происходило. В итоге, как работает данный модуль мне известно только по видео. Причина этого скорее всего в том, что ноутбук, на котором я начинал, был слабым и такая задачка для него оказалась слишком тяжелой, учитывая количество данных.

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

Выбор архитектуры: React + Leaflet

Нужно было действовать дальше. Решил изучить историю развития 2GIS. Вычитал, что в один из этапов своего развития, разработчики стали использовать картографические библиотеки Leaflet. Посмотрел рейтинг, почитал описание. Спросил у нейросети, каким образом можно с помощью Leaflet сделать карту с поиском. Узнал подробнее про React.

Так сформировалось архитектурное решение для проекта – React Leaflet. С этого момента началось погружение в вайбкодинг. В YouTube на канале для программирующих географов посмотрел классное видео о том, как лучше начать работать.

Для работы над проектом установил Visual Studio Code. Создал проект с помощью npm. Установил библиотеки React Leaflet. Начал разбираться с компонентами. Брал код и спрашивал у нейросети. Писать код благодаря этому не научился, но представление о компонентах определенное получил. Например, как работают стили, элементарно поменять цвет букв, рамки, отрегулировать прозрачность дорог, добавить координаты очередной точки, добавить дополнительное поле с информацией к точке. Постепенно освоившись, стал писать, сделай то, сделай это.

Путь через нейросети: от GigaChat до Claude Code

Немного о нейросетях. С самого начала пользовался Deepseek. Пробовал Алису, GigaChat. Отечественные нейросети, в том виде, в каком я их использовал, честно особо не помогли, в основном только советами. Но дело, как мне кажется в том, что я их неправильно использовал.

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

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

Какие получились промежуточные результаты? Главное - отображение карты, ортофотоплана и слоев с обозначениями. Нашел точку привязки и оптимальный зум. Теперь при загрузке приложения, отображался центр завода при зум 15.

Настроил оформление обозначений объектов. Все они первоначально были в красной рамке, внутри с белым фоном, черными буквами.

Встал вопрос по организации поиска. Это была целая отдельная история. Но обо всем по порядку.

К моменту, когда приложение более или менее стало работать, код разросся в размерах до такой степени, что за раз DeepSeek его уже не мог переварить из-за ограничений по размеру сообщений. Выявилось две проблемы. Первая заключалась в том, что сам диалог был ограничен определенным количеством сообщений. При переходе в новый диалог, история предыдущего не считывалась. Нужно было формировать краткое содержание и продолжать новый диалог, что вызывало большие трудности. Вторая проблема была в том, что в загружаемый блокнот, можно было сохранить около половины кода, вторая половина умещалась во втором блокноте и DeepSeek все чаще говорил, что размер файлов слишком большой, дроби на большее количество частей и вообще код точечно меняй сам. Это повышало мои знания в области кода, но разработка проекта буксовала.

Начались поиски других нейросетей. Выделил отдельный бюджет на это дело в пределах 15 тысяч рублей. Позже бюджет значительно расширился. Попробовал Chat GPT с подпиской за 20 долларов. Оказалось, что очень быстро исчерпывается лимит по запросам. Параллельно попробовал Grok. Приобрел подписку, тоже за 20 долларов. От них отказался по причине лимитов и качество кода мне показалось хуже, чем DeepSeek.

Своего рода находкой, был Copilot. Лимиты больше, качество кода лучше. Хотел приобрести подписку, но что-то не пошло. В итоге попробовал еще пару нейросетей, Manus и Gemini. Они тоже не устроили.

Думал уже оставить приложение в том виде, в каком удалось сделать. И тут мне улыбнулась удача. Бродил по просторам интернета и кажется, на Хабр попалась статья про Claude. Посмотрел, изучил, решил попробовать. Приобрел подписку за 20 долларов. Сначала по прежней схеме с копированием кода продолжил улучшать приложение. Через какое-то время изучил подробнее инструменты и подключил Claude Code в терминал Visual Studio Code.

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

Что дало подключение Claude Code? Начнем с отсутствия лимитов по запросам. В рамках своего проекта, к какому-то пределу ни разу не приблизился. Качество и уровень кодинга на порядок выше. Нельзя сказать, что допустим DeepSeek хуже, но в таком варианте использования, время внедрения и опробования какого-либо модуля уменьшается в разы. Причем работоспособность кода можно проверять тут же, обновлением страницы.

Система поиска: транслитерация и релевантность

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

Работа над системой поиска заняла определенное время с поэтапным опробованием и доработкой. Claude создал файлы с кодом SearchBar.jsx и NormalizeText.js, которые определяют логику поиска по объектам карты.

Результатом стал поиск с нормализацией, по множеству полей объекта: титул, название, позиция, производство, описание, квадрат сетки. Claude внедрил функцию умного поиска. В коде эта штука называется normalizedIncludes. Как это работает? Первый шаг: сначала осуществляется прямой поиск без транслитерации, т. е. убираются регистры, пробелы, дефисы. Работает для русских слов. Второй шаг: с транслитерацией, если ничего не было найдено на первом шаге, то происходит конвертация кириллицы в латиницу и поиск производится снова. Пример: есть оборудование с обозначением 51-РК-1101. Все названия в документации по умолчанию на латинице. Кто-то об этом знает и помнит, кто-то забывает, а есть те, кто об этом не подозревает. При поиске сотрудник может вводить как на русской раскладке, так и на английской, маленькими, большими буквами, либо в вперемешку. Оказалось, что это достаточно серьезный момент и ему было уделено внимание. На текущий момент сотрудник может вводить обозначение условно в любом виде, русскими буквами, английскими, с дефисами, или без, либо по названию. 51-РК-1101 допустим является бойлером пара высокого давления. По любой из «зацепок» объект, или единицу оборудования можно найти.

Следующим важным элементом является сортировка по релевантности - результаты сортируются по приоритету:

• Точное совпадение по квадрату сетки (например, А-5)

• Квадрат начинается с поискового запроса

• Точное совпадение по титулу или названию объекта

• Титул или название начинается с поискового запроса

• При равных условиях — более короткие названия выше

Есть история поиска. При фокусе на пустом поле показываются последние выбранные объекты (через searchHistory утилиту). Можно удалить отдельный элемент или очистить всю историю.

Организована подсветка совпадений - в результатах выделяется тегом <mark> найденный фрагмент текста.

Есть навигация с клавиатуры - ↑↓ для перемещения по списку, Enter для выбора, Esc для сброса. Также для удобства настроен сброс выделения - кнопка ✕ рядом с полем сбрасывает поиск и снимает выделение объекта на карте (вызывает onClearSelection в MapComponent).

Логика транслитерации:

// Транслитерация: кириллица → латиница
// РК → PK, ТК → TK, Ж → ZH и т.д.
const TRANSLIT_MAP = { 
  А: "A", Б: "B", В: "B", К: "K", 
  Р: "P", С: "C", Т: "T", Ж: "ZH" 
  // ... и другие
};

export function normalizeText(text) {
  let normalized = text;
  // 1. Транслитерация кириллицы → латиница
  for (const [cyrillic, latin] of Object.entries(TRANSLIT_MAP)) {
    normalized = normalized.replace(new RegExp(cyrillic, "g"), latin);
  }
  // 2. Нижний регистр
  normalized = normalized.toLowerCase();
  // 3. Удаляем пробелы, дефисы, точки
  normalized = normalized.replace(/[\s\-_.]/g, "");
  return normalized.trim();
}

Логика поиска:

export function normalizedIncludes(text, search) {
  // Шаг 1: прямой поиск без транслитерации
  // Работает для русских слов: "насос", "цех", "КПП"
  const directMatch = normalizeForSearch(text)
    .includes(normalizeForSearch(search));
  if (directMatch) return true;

  // Шаг 2: с транслитерацией
  // Работает для смешанных обозначений: "26-РК-1501" найдёт по "26-PK-1501"
  return normalizeText(text).includes(normalizeText(search));
}

В итоге работает все так. Сотрудник вводит в строке поиска нужный объект, как правило это титул, например 6619. В поле ниже выходят результаты поиска (квадрат расположения, титул и название объекта), точное совпадение подсвечивается желтым цветом. Клик мышкой, или нажатие клавиши Enter – происходит фокусировка на объекте. Он позиционируется в центре экрана, квадрат, в котором он располагается подсвечивается, из точки объекта выходит окно с информацией. На данный момент в окошке отображается информация: квадрат расположения, титул, название. Можно добавить, допустим категорию взрывопожароопасности, наличие сред, или материалов и т. п.

Дополнительные функции

В проект были нарисованы и импортированы элементы дорожной сети. Дороги сделаны кликабельными. Нажал, посмотрел, что за дорога и ее расположение на предприятии.

По просьбам коллег были интегрированы:

1. Компонент MeasureTool для замера расстояния по точкам. Нажимаешь на кнопку инструмента, далее левой кнопкой мыши кликаешь на место откуда начинается измерение, ставишь следующую точку, следующую и так до конечной. Правой кнопкой мыши завершается измерение и выводится результат. Суть инструмента заключается в том, что формируется полилиния и рядом с ней значение расстояния в метрах.

2. Кнопки зума. В приложении при входе по умолчанию настроен зум 15. Для представления, в браузере это область на карте по горизонтали - 5,5 км, по вертикали - 3 км. Самый дальний зум, кратностью - 12, максимальный зум - 20. На максимальном зуме в зависимости от качества изображения, можно разглядеть вагончики, автомобили, коммуникации, если присмотреться, то и людей можно найти. При обновлении подложки, нарезка тайлов в QGIS производится соответственно с зум 12 по 20. Важно отметить, что оптимальный формат для тайлов – webp. Размером они меньше, чем jpeg, или PNG, при этом не уступают по качеству. Функционал QGIS позволяет напрямую в приложении создавать тайлы в формате webp без какой-либо конвертации. Для сравнения, тайлы в формате jpeg изначально весили от 3 до 3,5 гигабайт, в зависимости от размера ортофотоплана. В формате webp, размер снизился до 500 мегабайт.

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

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

6. Ниже, под значком сторон света, расположен компонент - динамическая линейка. Он помогает визуально определять условное расстояние по карте в зависимости от зума.

Сборка и развёртывание

После приведения в порядок данных и настройки, была проведена сборка приложения:

• на персональный компьютер. Запуск .exe файлом;

• APK для смартфонов с операционной системой android;

• организован сайт с входом по учетным данным (логин/пароль).

Владельцы девайсов с ОС Android при необходимости скачивают APK и устанавливают. В таком варианте приложение полностью автономно. Базы данных и тайлы предприятия находятся внутри APK. Интернет нужен только для загрузки спутниковой подложки Google, либо карты OpenStreetMap вокруг предприятия. В общем, если нужна информация по предприятию, то интернет не нужен.

С приложением для ПК ситуация та же, что и с приложением для Android.

Корпоративные политики в области информационной безопасности запрещают использовать «левое» программное обеспечение служебном компьютере, но при наличии выхода в интернет, приложение доступно через сайт. У кого смартфоны iPhone, также без проблем могут использовать приложение через сайт.

Таким образом, все сотрудники, кто нуждался в этом приложении, получили доступ.

Бюджет проекта

Бюджет приложения по статьям расходов выглядит так:

• GigaChat – 2990 рублей. Работает в рамках подписки СберПрайм.

• Алиса Про – кажется около 2000 рублей.

• ChatGpt – 20 долларов.

• Grok – 20 долларов.

• Claude Code – 347 долларов и 45 центов.

• Домен .ru – 119 рублей.

• Виртуальный сервер для сайта – 159 рублей в месяц.

• Виртуальный сервер для организации VPN – 259 рублей в месяц.

• Облако – около 2000 рублей в год.

• Ноутбук Asus TUF Gaming A16 – 121000 рублей. Покупка ноутбука была в планах, работа над приложением ускорила этот момент.

• Личное свободное время. Оно бесценно, поэтому посчитать трудно. Практически все свободное время в течение нескольких месяцев уходило на работу с приложением.

Итог и эффект

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

Сам продукт получился полезным, коллеги пользуются и благодарны. Эффект от использования таков:

1. Поиск объекта и определение его местоположения занимает не больше 10 секунд, вместо 10 минут до создания электронной карты. В случае нештатных ситуаций, вопрос времени критически важен.

2. Единое информационное поле для всех сотрудников. Не нужно тратить время на объяснения, привязываться к каким-либо ориентирам. Достаточно назвать квадрат, титул, или название.

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

4. Автономность. Отсутствие интернета не является фатальным для коммуникации. При работе с пожарными предприятия, или заводской скорой помощью технические сбои в части отсутствия интернета не являются помехой, так как есть приложение на Android и персональный компьютер.

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