Инвентаризация систем наружного освещения (СНО) в ZuluGIS глазами предпринимателя

Инвентаризация систем наружного освещения (СНО) в ZuluGIS глазами предпринимателя

Предисловие

        Всем привет! С момента написания предыдущей статьи («Инвентаризация систем наружного освещения (СНО) в ZuluGIS глазами ГИС-Инженера») прошло почти 5 лет и настало время на некое продолжение. За это время было сдано немало подобных проектов, два из которых были крайне интересными. Первый - инвентаризация освещения ГО Ялта, в котором я был уже не сотрудником, а руководителем своего предприятия. Второй проект был поделен пополам между двумя фирмами, использующие разные геоинформационные системы.

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

В этой статье пойдет речь о преимуществах ZuluGIS для задач инвентаризация уличного освещения именно в техническом плане.

  
Рисунок 1. Сети освещения ГО Ялта.

Что у других?

        На протяжении 8 лет работы я всегда задавался вопросом, а есть ли другие геоинформационные системы, которые лучше подойдут для решения задач по инвентаризации СНО, чем Zulu? К сожалению, в интернете очень мало информации на эту тему. Однако, в ходе выполнения работ я сталкивался с «конкурентами» и имел возможность обменяться опытом и попробовать их продукты. Всегда это были решения собственной разработки. Отвечая на вопрос выше, могу сказать, что хотя собственные разработки и могут похвастаться местами лучшим функционалам и удобством, но что касается вопроса гибкости и скорости, то тут они сильно проигрывают.

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

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

Уже в начале проекта посыпались вводные: добавить поля, занести значения в справочники, создать новые режимы, создать новый слой для сопутствующих задач, где-то поменять логику отрисовки сети и так далее… Если в Zulu с этим проблем не возникло, все решалось буквально сразу, то у второй команды начались проблемы. Основное неудобство собственных программ – это необходимость порой вносить существенные изменения в код для решения простых задач, что иногда требует непозволительно много времени. Соперникам потребовалось 3 недели, чтобы сделать светильник отдельным объектом от опоры. Ранее, это был один объект, где заполнялась вся нужная информация, но визуально понять есть ли на опоре светильник, сколько их и какие они было невозможно.

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

Автономность мобильной версии

Оффлайн режим

        В предыдущей статье я указал, что в мобильной версии есть возможность наносить сети без интернета. Однако, по-настоящему прочувствовать все ее прелести я смог только в 2025 году. Во время инвентаризации частым явлением было отключение мобильного интернета. Подождать пока включат обратно – не вариант. Решением данной проблемы было создание слоя дублера, который был бы всегда в офлайн режиме (без интернета уже не получится переключиться в офлайн режим). В данном случае, при отключении интернета, обходчики самостоятельно переключались на другой слой. Далее, после возвращения на базу надо было загрузить данные с офлайн слоя на сервер, и перенести все в рабочий слой. Ничего сложного нет, данная операция проводилась не один десяток раз.

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

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

Говоря о темпе, хочу отметить существенный рост производительности труда по сравнению с первым проектом, который был в 2018 году. Тогда хорошим днем считался, если обходчик нанесет 60-80 опор. В 2025 году удалось добиться максимальных показателей в 300 опор в день, а средние значения колебались между 150 и 250 опор. Такое ускорение было достигнуто благодаря нововведениям в самом Zulu, таких как: офлайн режим, копирование, отложенная загрузка файлов, а также оптимизацией и автоматизацией основного слоя и рабочего процесса. При этом качество работы только улучшилось.

Локальные подложки.

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

И главная мысль здесь в том, что просто иметь знание — этого иногда недостаточно, важно еще и уметь это использовать, и понимать в каких ситуациях. Таких случаев в моей карьере было много, когда знания вроде имелись, но сложить 2 + 2 сходу не получалось.  

  
Рисунок 2. Создание файла mbtiles для локальной подложки.

Гибкость ZuluGIS

Изменения на ходу

        Как уже было сказано выше, инвентаризация СНО – это не типовая работа. В первый же день обхода сетей в ГО Ялта выяснилось, что существует провод АВТ, и он используется массово. За 8 лет я больше нигде такого провода не встречал и, соответственно, в структуре слоя такой провод, как «режим» отсутствовал. Ехать обратно к компьютеру не пришлось. Зайдя на сервер через удаленный рабочий стол с мобильного телефона, мне потребовалось пару минут, чтобы добавить нужный режим. После сохранения настроек слоя, данный режим сразу появился в мобильной версии у всех обходчиков. Мне не потребовалось тратить время на написание кода, обновление мобильного приложения и так далее…

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

  
Рисунок 3. Множество записей моделей светильников в одном объекте.

Срезание углов

        Несмотря на описываемую гибкость программы, не всегда следует пытаться «подогнать» структуру слоя под все случаи. В каждом проекте, который я делал, были ситуации, которых не должно быть (рисунки 4 и 5), но в силу разных причин они встречаются. Пытаться изменить слой для таких редких случаев бессмысленно. Что еще более бессмысленно, так это что-то вписывать в поле “Примечание”, в него никто никогда не смотрит. Как показала практика, лучше всего — это ставить рядом некий знак, например, желтый восклицательный, а в карточке самого объекта ставить в справочнике “Иное”.

  
Рисунок 4. Да – это светильник, и да – это пивная фляга.

  
Рисунок 5. Часть команды, часть корабля.

Однако, это все работает только в одном случае – если это не массовое явление. Одним из примеров массовых “случаев” является наличие кронштейна при отсутствии светильника (рисунок 6). Текущая структура слоя не подразумевает кронштейн, как отдельный графический объект (информация по нему находится в карточке светильника). Для решения данной проблемы пришлось создать новый режим у светильника “Отсутствует” и поменять код подсчета сводных данных, чтоб такой режим не считался как светильник, а кронштейн учитывался. Данную проблему можно решать разными способами, например, вынести кронштейн в опору или в отдельный графический тип… можно, но будет потеря в скорости отрисовки или усложнение самого слоя.

  
Рисунок 6. Кронштейн есть, светильника нет.

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

Рабочий слой

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

В пример хочу привести переосмысление способа отображения светильника: в первых проектах был просто один режим «Светильник», далее для удобства один режим был разбит на множество исходя из типа светильника (ЖКУ, РКУ, LED…). Такая разбивка упростила и ускорила процесс инвентаризации, в первую очередь за счет того, что в карточке автоматически проставлялся тип светильника исходя из его режима, да и просмотр самой карты стал более информативным. Но на этом переосмысление не закончилось, в данный момент мы используем разбивку не по типу светильника, а по источнику света (ДНаТ, ДРЛ, КЛЛ…) – это более правильный подход, который позволяет решает проблемы, связанные с формированием правильной марки светильника.

  
Рисунок 7. Разные режимы светильников.

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

Также стоить отметить, что многое зависит от знаний и опыта самого ГИС-инженера. Какая бы хорошая не была геоинформационная система, ей надо уметь пользоваться и знать, на что она способна. Конечно, все это приходит с опытом и, порой, занимает достаточно много времени. Однако, этот процесс можно ускорить: - работа над ошибками после проекта, а также разного рода эксперименты и тесты; - работа над переосмыслением текущего подхода в принципе… Отдельно хочу выделить два момента. Первый – это развитие навыков программирования и работы с базой данных, в 2026 году уметь просто работать в ГИС уже мало. И второе – это чтение документации по Zulu. Тут мысль состоит в том, чтобы лучше понять возможности программы. Некоторый функционал вы использовать сразу не будете, он будет ждать «своего часа». У меня такое было много раз, когда полученная информация из документации стала полезной спустя годы.  

Резервное копирование

        Еще один совет начинающим ГИС-инженерам, да и не только, который хочу дать – это обязательное резервное копирование рабочих слоев. С момента предыдущей статьи в самом Zulu в этом плане ничего не поменялось, но лишним не будет об этом рассказать.

Казалось бы, очевидная вещь - делать бэкапы рабочих слоев, но поверьте, много людей (да и я сам иногда) либо забывают их делать, либо в принципе не умеют это автоматизировать. Всякое бывает и терять полностью или частично проделанную работу – это больно и затратно. Не повторяйте моих ошибок). После одного такого случая, пару лет назад, я стал делать 3 отдельных бэкапа: раз в неделю, раз в сутки и каждый час. Кто-то может сказать, что это слишком, но время показало, что решение было верное. Делать бэкап раз в сутки – признак хорошего тона, раз в неделю – удобно смотреть исторические данные, а раз в час – это гарантия того, что вы вряд ли потеряете много.

  
Рисунок 8. Папка с бэкапами одного из проектов.

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

Сопутствующие темы 

            Далее хочу затронуть две темы, которые напрямую не относятся к Zulu, но считаю, что их важно проговорить. Все-таки они влияют на качество проекта в целом.

Самое главное – это команда.

        Подобные проекты, где «самому не справиться», подразумевают наличие сотрудников, от которых будет зависеть качество всей работы. И, чтобы в конце проекта не стоять и не краснеть у заказчика, вопрос команды, её компетенции и профессионализма должен быть решен еще в начале работ. Оказывая услуги другим компаниям, в качестве ГИС-инженера, я не раз наблюдал к чему приводит слабая подготовка обходчиков. В моем случае, со мной работали люди, которые не один год занимаются освещением, и мне требовалось обучить их работе в мобильном приложении ZuluGIS Mobile, а также провести организационные работы. Обходчики должны не просто уметь наносить сети на карту, а именно «исследовать» их. Сколько раз приходилось топтаться на месте по 15-20 минут, чтобы разобраться в ситуации, а разобраться надо, нас же не просто так наняли…

  
Рисунок 9. «Тяжелая» ситуация.

Фотографии

        Смотря на чужие проекты, и не только по освещению, я заметил, что мало кто уделяет должное внимание фотографиям. Если они и есть, то зачастую не самого лучшего качества. Да, там видно основной объект съемки, однако приблизить и рассмотреть детали не всегда можно из-за посредственного объектива. Возможность не выезжать на место, порой экономит очень много времени, особенно, когда что-то надо посмотреть здесь и сейчас. Также хочу отметить, что делать несколько фотографий объекта тоже плохая идея. Давно, при инвентаризации освещения, была практика делать фото опоры со светильником, чтобы все было в одном кадре и отдельно фото самого светильника, обосновывая это тем, что будет лучше видно сам светильник и провода в верхней части опоры. Сейчас же мы делаем лишь одну фотографию на телефон с хорошим разрешением и при этом стараемся делать фотографии по определенным правилам, ведь ракурс тоже важен. Качественные фотографии – это не только практическая польза, описанная выше, но и эстетика, вы же не смотрите видео в интернете в низком качестве)

  
Рисунок 10. Качественная фотография.

  
Рисунок 11. Некачественная фотография.

Заключение

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

ИП Рябика Леонид Игоревич

giszuludepartment@gmail.com

См. также: «Инвентаризация систем наружного освещения (СНО) в ZuluGIS глазами ГИС-Инженера»