Единый реестр скамеек, фонарей, урн и покрытий: какую структуру данных выбрать

Сначала решите, что считаете «активом», а не выбирайте таблицу

Любой реестр начинается не с полей, а с определения того, что мы учитываем. Для скамейки, опоры освещения или урны активом логично считать конкретный физический экземпляр с местоположением и историей обслуживания, а не «скамейку вообще». Это совпадает с логикой систем управления активами (типа RAMP в Шотландии), где уличное оборудование ведётся как национальный набор точечных данных, обновляемый ежегодно.

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

• Составьте перечень категорий (по аналогии с классификацией малых архитектурных форм в методических рекомендациях Минстроя): мебель, освещение, озеленение-оборудование, ограждения, коммунально-бытовое оборудование, покрытия.
• Уточните, что именно входит в «покрытия»: тротуарная плитка, асфальт, резиновое покрытие детских площадок — это разные активы с разным сроком службы.
• Определите уровень детализации: учитываете ли вы каждую урну отдельно или группу оборудования как комплекс объектов.

Одна геометрия не подходит всем: точки против площадей

Главное решение — как хранить положение. Скамейка, фонарь, урна, опора, стол — это точечные объекты: у каждого одна координата и своя карточка. Именно так построены открытые наборы уличной мебели в Торонто (точечный слой с картой полей) и национальный набор street furniture в Шотландии, помеченный как point.

А покрытия — асфальт, плитка, резиновое покрытие площадок — нельзя честно описать точкой: это площадные (полигон) или линейные (тротуар как линия) объекты. Для них нужна сегментация: разбиение на однородные отрезки/участки, чтобы по каждому можно было хранить возраст, материал и оценку состояния отдельно.

Международный стандарт CityGML разделяет похожим образом: предметы городской мебели — отдельный класс с геометрией уровня детализации LOD1–LOD4, а поверхности проезжей части и тротуаров в модели транспорта описываются отдельными зонами с указанием материала покрытия. Поэтому практичный ответ — не «один слой на всё», а «один реестр с согласованной моделью», где геометрия выбирается по типу объекта.

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

Ядро атрибутов: идентификатор, жизненный цикл, ответственный

Чтобы разные службы сходились в отчётах, у каждой записи должен быть стабильный уникальный идентификатор. В ГИС ЖКХ при создании общероссийского реестра дворовых и общественных территорий закладывался принцип «каждому двору и каждому объекту — уникальный идентификатор и оценка состояния». Этот же принцип переносится на городской уровень.

Дополните идентификатор обязательными полями жизненного цикла. В CityGML у городской мебели есть атрибуты creationDate (дата создания объекта в модели) и terminationDate (дата удаления), а также ссылка на внешние системы. В практическом реестре это превращается в даты установки и демонтажа или последней замены, ответственного владельца и подрядчика, тип и материал.

• asset_id — уникальный, неизменяемый при переносе между системами.
• geometry / координаты и привязка к территории (адрес, зона, двор).
• type и subtype — коды типа объекта по справочнику.
• install_date, removal_date, warranty_end — жизненный цикл.
• responsible_org, contractor — кто владеет и кто обслуживает.
• status: действует, требует ремонта, списан.

Кодовые списки вместо свободного текста

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

CityGML хранит для мебели класс, функцию и назначение как отдельные контролируемые списки кодов. Для российского реестра удобно взять за основу классификацию малых архитектурных форм и уличной мебели из методических рекомендаций Минстроя и развести её на уровни: категория → тип → вариант. Например: категория «уличная мебель» → тип «скамья» → вариант «скамья со спинкой для двора».

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

Состояние и история работ: поля, которые делают реестр полезным

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

Не дублируйте историю в тексте — связывайте реестр с заявками и нарядами на работы по идентификатору актива. Тогда диспетчер видит, что у «скамьи №1021» вчера заменили спинку, и не отправляет бригаду повторно.

• last_inspection_date и next_inspection_date — периодичность осмотра по типу объекта.
• condition_grade — единая шкала (например, отлично/удовлетворительно/требует ремонта).
• work_order_ids — ссылки на заявки и наряды, а не пересказ работ текстом.
• photo_url — фотография актива и дата съёмки, критична при приёмке от подрядчика.

Кто ведёт реестр и как он остаётся живым

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

Российский контекст даёт и публичную составляющую: в ГИС ЖКХ по проекту «Формирование комфортной городской среды» публикуются перечни объектов, сроки, виды работ, подрядчики и суммы. Единый внутренний реестр становится источником для таких публичных отчётов, а не отдельной бумажной ведомостью.

• Назначьте единственного ответственного (структурное подразделение или оператор ГИС).
• Определите регламент: полная инвентаризация раз в год, точечные изменения — по факту работ.
• Свяжите реестр с открытыми данными и публичными отчётами, чтобы он не расходился с тем, что видит житель.

Ограничения, типичные ошибки и план запуска

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

Помните о точности: точечный слой в масштабе 1:50 000 (как в шотландском наборе) показывает наличие и грубое положение, но не годится для геодезической привязки. Для площадных покрытий укажите, по какой съёмке оцифрованы границы. И разделяйте юридический статус (чьё это имущество, на чьём балансе) и технический учёт: не всё, что стоит на муниципальной земле, является муниципальной собственностью.

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

• Не смешивайте «геометрию» и «учёт»: точку мебели можно привязать к площадному участку территории ссылкой.
• Фиксируйте точность и источник координат (съёмка, по кадастру, по фото).
• Не храните в одном поле и тип, и состояние, и ответственного — разносите по справочникам.
• Неделя 1–2: реестр категорий, владелец данных, регламент.
• Недели 3–6: пилотная инвентаризация пилотного района с фотофиксацией.
• Недели 7–10: справочники, контроль уникальности ID, проверка полноты.
• Недели 11–12: публичная выгрузка и внутренние отчёты, план следующего цикла.