Сегодня про 13 раздел ГИСОГД isogd.geosamara.ru - особенности ведения.

Основным "рабочим" разделом для пользователей ГИСОГД Самарской области является 13 раздел - "Дела о застроенных и подлежащих застройке земельных участках (ЗУ)". Там максимальное количество различных типов документов (38) и самих документов (десятки тысяч). При этом многие документы должны быть связаны друг с другим, либо одни документы зависят от наличия других. Например, Разрешение на ввод (РВ) не может существовать "само по себе", его появлению в системе предшествует не только Разрешение на строительство (РС), но и технический план ОКС, схема расположения ОКС, различные заключения и экспертизы. Или "уведомление об окончании строительства" никак не может появиться раньше, чем "уведомление о планируемом строительстве" и ГПЗУ.

Итоги на сегодняшний день, для операторов:

1) Все документы 13 раздела имеют обязательную привязку к графическому объекту - контуру земельного участка, ОКС или ППТ/ПМТ.

2) Для каждого документа проработаны правила верификации и проверки данных, наличия обязательных и условно-обязательных полей, документов и связей. Правила сформированы на основе нормативки и постоянных консультаций и согласования с отделом контроля качества Минстроя Самарской области. Очень сильно снизились претензии в сторону ОМСУ по "неправильности ведения ГИСОГД" - система не позволяет этого сделать.

3) Разработаны упрощенные процедуры связывания, по кнопке "схема связей", позволяющая найти и связать вновь вносимый документ с нужными документами, относящимися к тому же ЗУ.

4) Из любой карточки документа можно автоматически заказать в ЕГРН выписку на ЗУ или ОКС, если они не загружены в систему.

5) Созданы специальные выгрузки, позволяющие пользователям найти документы с ошибками - внесенные в систему до включения верификаторов или когда требования связей были не обязательны, дубли, документы без ЭП (да, мы прикрепляем ЭП к карточке документа в ГИСОГД, "сворачивая" в хэш заполненные поля ), с прочими несоответствиями, а затем быстро исправить такие данные.

Результат для нас/заказчика:

1) Пользователи сначала "пищали", но потом привыкли что данные надо вносить "корректно" и с дополнительными документами, связями, прикреплениями и т.д.

2) Очень высокое качество данных, которые вводят сами пользователи - более 80% документов в Разделе соответствуют требования 433 приказа. И количество мусора и "дублей" постоянно уменьшается.

3) Можно легко отслеживать все документы от ГПЗУ до РВ или уведомления - то есть выстраивать "историю" градостроительного изменения.

В конце надо какую-нибудь тупую мораль 😊. Будьте жесткими и мягкими одновременно и с самого начала, соблюдайте баланс! Если вы просто ужесточаете требования для пользователей, получаете лютое сопротивление, поэтому надо облегчить им жизнь больше, чем величина допработ.

По вторникам будут общие мысли про ГИС и геоданные. Этого добра 💩 у нас - хоть лопатой отчерпывай.
----
В 90-е 💾 основные деньги делались на картографии и простых ГИС-вьюерах. Достаточно было показать карту в компьютере заказчика - ты король 🦍 Гуглмапс похоронил этот простой рынок.

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

"Десятые" 📱 - время геопорталов и "единых баз данных". Время "студентов с геосервером", которые из дерьма и палок ваяли прототипы, а потом растворялись на просторах стартапья. Банковали те, кто "держал объем". Основная прибыль в нулевые и десятые была у владельцев уникальных данных.

Сейчас данных очень много, и производители их в жёсткой конкуренции. В первой половине двадцатых основная прибыль будет у тех, кто сможет грамотно объединять и анализировать большие геоданные. Очень удобно - небольшая контора, умеющая делать 1+1=3 и красиво это упаковывать в сервисы 📈. Контора почти без собственного производства, живёт "на эти 2 про‌цента".

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

Конечно эти "слои" и темы накладываются, кто опережает, кто отстаёт. Я про мейнстрим.
-----
Потом примерно по кругу, потому что для сложных моделей будут нужны другие данные другого качества.

Расскажем про мониторинг и контроль нарушений границ отводов недр в нашем проекте "Комплексная система дистанционного мониторинга" (подсистема "Недра" КСДМ), ровно неделю назад писали про анализ лесоизменений.

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

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

Мы обнаруживаем такие нарушения по космическим снимкам (разрешение 1-2м) 📡 а для выяснения нецелевого использования земельных участков (или использования неоформленных участков) сравниваем с кадастровыми данными. Контуры и описание найденных нарушений заносим в КСДМ и передаём на верификацию. Выходами за границы отвода занимается управление государственного экологического надзора МинЛесХоза, нарушения земельного законодательства отрабатывают отделы муниципального земельного контроля (МЗК). Заполняют статус: достоверно нарушение или ложно, для этого при необходимости выезжают на место, выясняют что происходит, прикладывают фотографии с помощью мобильного приложения КСДМ.

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

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

Четверг - технический день 💡

В проекте Робот-Картограф rk.geosamara.ru мы впервые применили в качестве основного хранилища геоданных NoSQL-СУБД MongoDB.

Главная причина - вычислительная эффективность. Масштабирование технологии от большого города ко всей России угрожало загнать нас в тупик по производительности. Вторая причина - в ближайшей перспективе мы хотим перенести решение в облаке. Использование реляционной СУБД типа MS-SQL в нем очень дорогое, а с MongoDB тарифицируется по минимальной ставке , фактически как файловое хранилище.

В этой необычной СУБД:
- не таблицы четкой структуры, а коллекции JSON-документов с произвольной иерархической структурой полей (поля-массивы, поля-объекты);
- геометрия как поле GeoJSON-формата, есть некоторые пространственные операторы;
- индексы по полям любого уровня вложенности, в том числе есть пространственные индексы;
- свой синтаксис запросов на основе JSON;
- вместо сложных SQL-запросов - "пайплайны" обработки данных из элементарных операций фильтрации, проекции, объединения, группировки;
- поддержка облачными платформами, драйверы для любых современных языков программирования.

Алгоритмы робота-картографа анализируют графы и на самом деле не требуют сложных объединений таблиц. Основные операции с данными: выборка по индексированным полям, добавить/удалить записи, редко - изменить записи по ID. Но при этом - сотни таблиц, сотни миллионов записей, сотни Гб.
Первые версии алгоритмов были рассчитаны на реляционные БД, и когда мы декомпозировали их на элементарные операции и переложили на MongoDB, ускорение составило от 8 до 12 раз.

Визуализация геоданных тоже не представляет трудностей: импорт/экспорт в GeoJSON, построение MVT-кэша, индексация для адресного поиска просты в реализации. Не для всего хватает операторов MongoDB. При этом Postgre+PostGIS в системе тоже есть, ради возможности сложную логику обработки геометрии держать в хранимках. Это требуется в тематических моделях, которым дозволено работать с не самой высокой скоростью.

Если вам придется обрабатывать большие объемы не очень структурированных геоданных, присмотритесь к этой СУБД. Ну и пишите - звоните по роботу-картографу.

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

По выходным - "легкое чтиво" на подумать. Придуманные нами ситуации для технологии "Управленческих поединков", где у каждого своя правда, и нет единственно верного решения. По минимуму, эта ситуация объясняет: "ну почему директор не может поднять мне зарплату, что ли фирма разорится от лишней десятки в месяц?"
———-
А нам?

В фирме "IT-Ветерок", занимающейся настройкой, адаптацией и разработкой программного обеспечения, работает директор и 10 человек. Дела идут неплохо, но рост выручки и прибыли весьма средний, а работы много, люди заняты на 100 процентов. Директор Валера ищет возможности для роста, так как конкуренты не дремлют, и довольно случайно встречает давнего знакомого Гошу, занимающегося подобной темой, компетентного специалиста.

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

Гоша начинает работать у Валеры и, действительно, в первые 2 месяца выполняет свои обязательства, хотя возрастает нагрузка и на других специалистов, правда не сильно. Через 2 месяца к Валере приходит его ведущий специалист Артур и "от лица коллектива" говорит, что ему и всем не доплачивают, так как Гоша получает вдвое больше (как они узнали - ну узнали), а работать больше приходится им. Артур предлагает повысить зарплату ему и всему коллективу хотя бы на 20%. Валера не соглашается, так как такое увеличение зарплаты принесет ему дополнительных расходов в 400 тысяч и -200 вместо +200 по итогу в месяц.

Роли и интересы:

Валера - сохранить свой коллектив, так как на рынке сложно быстро найти таких специалистов и оставить возможность роста.

Артур хочет повысить себе и товарищам зарплату, в крайнем случае уволить Валеру или уменьшить ему зарплату (так будет справедливо).

Гоша хочет получать оговоренное бабло и приносить доход, он выполняет обязательства.

"Историзм" и сравнение графических данных градостроительной документации. #ГИСОГД

Эта фича позволяет оценить на картографической основе изменения и состояние на определенную дату при согласовании и использовании граддокументации.
В нижней части окна - шкала времени 🎚, позволяет "отмотать" граддокументацию на определенную дату с учетом всех изменений. В правой части - состав слоев для фильтрации по крупным блокам (транспорт, инженерка, функциональные зоны...). Сам экран может быть разделен "шторкой" 🌓 для сравнения актуального варианта графической части граддокументации с планируемым (при согласовании проектов) или наоборот с архивным.

Сейчас инструмент работает для генеральных планов, ПЗЗ и общей ситуации с земельными участками и территорией. Для ППТ/ПМТ пока ограниченно, так как нет единого классификатора, сравнивать достаточно сложно.
Простой внешне, не очень простой внутри и полезный девайс. Как часы 😊

Вторник - день вольных рассуждений про геоинформатику.

Предположим, Вы очень крутой спец в области геоданных, хотите замутить стартап и всех победить. И начинаете искать предметную область ну или хотя бы сегменты рынка ("в средней полосе" России, чтобы без экзотического Севера).

Смотрите на B2C (для граждан). Хм, там плотно Яндекс и 2ГИС. А больше чем поиск по адресу, интересным местам, навигатор с пробками и прогнозами общественного транспорта - вроде как обычному жителю и не надо. Потребность "ориентироваться в пространстве" в целом закрыта.

ОК, давайте посмотрим на B2B. Кому нужна "точная картография", чтобы ежедневно - еженедельно.
Геомаркетинг? Крупные ритейлеры имеют свои отделы, а мелкие не доросли.
Лес? Очень "кривой" рынок.
Кадастровые работы? Оценщики? Разработка граддокументации? Все мелковато и масса конкурентов...
Ресурсоснабжающие организации? Интересно, но все под естественными монополиями, туда фиг проберешься.
Сельхозка? Да!! Низкая база (по первости хватает простой оцифровки полей, компоновки по ним данных снимков, метеорологии и почв), растущий рынок в целом, много независимых потребителей (можно 1 раз сделал - много раз продал). Но там миллион стартапов - все туда и рванули.

Ок, B2G. Но под B2G стартап денег не очень-то и дают. Ну и региональная информатизация потихоньку "вымывается" на федеральный уровень. Так же как 5-10 лет назад это произошло с муниципальной информатизацией - она фактически осталась только в крупных городах (миллионниках), да и то не всех. К тому же, B2G это жесткие регламенты, которые пока не очень-то и заточены на цифровые методы.

Читаете отчеты и презентации Роскосмоса и Росреестра двухлетней давности - там экзотика (типа маршрутов оленей) или "результаты будут востребованы широким кругом потребителей в различных отраслях народного хозяйства".
——
Останавливаетесь, напиваетесь с горя, похмеляетесь и идете по второму кругу, с подробным анализом. И оказывается, что в складочках, в швах и соединениях много чего притаилось. И жители не только и не столько ищут ближайшую аптеку и смотрят пробки... И бизнес не такой тупой как кажется. И данные всем нужны, но только на порядок качественнее, чем есть на рынке. И в сегменте B2G есть куча интересантов, куча желания и стремления к цифровизации, надо только понять "правила игры".

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

Удачи нам всем!

Расскажем про очередную подсистему проекта КСДМ (Комплексная система дистанционного мониторинга) - мониторинг мест размещения отходов в Самарской области.
Слово руководителю проекта Михаилу. Он у нас очень подробный чел, поэтому текст длинный.
-----
Места размещение отходов бывают двух видов
1) Полигоны размещения отходов.
2) "Места несанкционированного размещения отходов" (проще говоря "свалки")

Полигоны размещения отходов это официально выделенные места, куда эти отходы можно вывозить.
Пока работаем только с полигонами ТКО/ТБО (твёрдых коммунальных/бытовых отходов), с полигонами промышленных отходов - в ближайших планах, по ним сложно найти официальный реестр.
В Самарской области 11 действующих полигонов ТКО (16 шт всего).

Первым делом мы нанесли границы этих полигонов на карту по кадастру, а потом по космическим снимкам нашли места, где полигон выходит за установленные границы - выявили возможные нарушения. Затем, следуя регламенту КСДМ, для каждого возможного нарушения создаётся карточка верификации, в которой пользователи должны проставить статус: достоверное нарушение или ложное. Выполняют камерально или "в поле" (при выезде на место) в нашем мобильном приложении с прикреплением фото.

Собственно на этапе выездов и выяснилось, чем куча нелегального мусора обычно отличается от абсолютно легитимной кучи камней при взгляде из космоса: ничем не отличается.То есть часть обнаруженных нами нарушений ожидаемо оказались ложными. Зато другая часть подтвердилась, информация была передана в Росприроднадзор, который даже вычислил возможные штрафы, и начал контрольно-надзорные мероприятия (КНД).

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

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

При переходе из эксель к ГИС очень важно сильно не усложнить пользователям жизнь. Сделать удобный редактор карточек объектов с переходом на карту и возможностью выгрузки обратно в Эксель.
В прошлом году геокодировали и сделали карту свалок, с этого года подключили муниципалов (все 37), и они сами внутри КСДМ ведут реестры, обновляют информацию, цепляют фото и т.д. По пути сильно уменьшилось количество собираемых отчётов - они просто не нужны, все выгружается из системы.

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

Если площадь "космического мусора" для существующей свалки заметно отличается от заявленной в документах, то это проверяется на месте, так как эта площадь потом пересчитается в размер выделяемых средств на его вывоз.

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

Сейчас в реестрах 321 существующая свалка и 325 ликвидированных, но космомониторинг обнаружил около 41 из ликвидированных свалок что-то похожее на пятна мусора (2 дня назад, будем проверять).

Четверг - технический пост.
Слово нашему техлидеру Николаю, мастеру короткой прозы и абстрактных картинок.
——-
«Редактирование MVT»

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

Первая реакция пользователей после внедрения MVT: мы только что нарисовали, где он на общей карте???
Путей решения может быть несколько:
- пытаться вместо тайлового кэша преобразовывать данные в MVT на лету из базы данных. Попробовали. Нагрузка на сервер БД 100% примерно всегда. Не подходит.
- пытаться обновлять кэш при обновлении записей в БД, применяя либо триггеры, либо другие событийные механизмы. Попробовали. Так как кэш мультимасштабный, обновление одного объекта даже самого маленького ведет к пересчету всех тайлов с ним, включая, например, тайл (0, 0, 0). Операции INSERT, UPDATE, DELETE выполняются долго, сервер также загружен на момент обновления. Не подходит.

В итоге остановились на следующем варианте.
Рассматриваем ситуацию spatial таблицы в базе данных, которая только дополняется, т.е. записи в таблице никогда не удаляются. К примеру, практически все данные в ГИСОГД идут по такому принципу. Документы не удаляются, а помечаются как недействующие. Земельные участки не удаляются, а меняют статус на «Снят с кадастрового учета». Количество добавленных или измененных данных за день не велико и сильно меньше общего объема данных в таблице.

Источники геоданных публикуются по 2 маршрутам:
/collections/LandPlot/items - OGC API Features, напрямую из БД.
/collections/LandPlot/tiles/{tileMatrix}/{tileRow}/{tileCol} - OGC API Tiles, данные из тайлового кэша.
Особенностью новых стандартов является поддержка «из коробки» мультивременных данных. Это означает, что каждый источник на уровне запросов может поддерживать параметр datetime, определяющий за какой промежуток времени запросить данные. Например, открытый интервал: 2022-10-27T00:00:00Z/..
Таким образом для Features API мы можем запрашивать данные с момента последнего обновления тайлового кэша.

Синхронизируем на клиенте. К примеру, для OpenLayers наследуемся от класса ol/source/VectorTile, перегружаем tileLoadFunction и делаем параллельный запрос к OGC API Features с учетом даты последнего обновления тайлового кэша, объединяем данные по идентификаторам. По итогу с точки зрения клиента слой остается один, стиль отображения также един, но данные берутся из 2 источников.
Поход чем-то близок по духу к Lambda Architecture:
- горячие (Hot) данные по ветке OGC API Tiles. Запрашиваются быстро, часто, регулярно, большой объем.
- холодные (Cold) данные по ветке OGC API Features. Запрашиваются медленнее, содержат полную информацию (как графику, так и семантику объектов).
Ну и фактически подход объединения геоданных разной степени «прожарки» может быть применен для источников не на основе OGC API. Главное – синхронизация по времени.
——-
Слово обратно менеджеру Андрею.

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

Традиционная абстрактная картинка, которая должна пояснять, но увы - мало поясняет текст. Пока ищем свой неповторимый стиль...

Хорошую новость принес вечер, поэтому нафиг правила - второй пост за день.
Консорциум в составе МИИГАИК (головной), Самарский университет и еще несколько компаний, универов и НИИ стали Центром компетенций Национальной технологической инициативы (НТИ) по геоданным.

История началась в 2018 году, когда мы (точнее - я лично) очень захотел быть в НТИ со своим проектом. Четыре с небольшим года усилий, десяток документов (концепций, стратегий, проектов и программ разной степени завершенности) , 12 групп в телеге по теме, пару-тройку десятков зумов, несколько "окончательных" решений бросить все нафиг - и, наконец, какой-то результат. Но и это только начало.

Самарская часть заявки и программы (примерно 1/3 от общего объема в 700 млн.руб. на 5 лет) - работа по трем ключевым проектам
1) "Робот-картограф" и Геохаб
2) "Цифровой двойник территории" (решение задач "если-то" на цифровых моделях на геоданных)
3) "Автопривязка данных ДЗЗ"
Попробуем как можем поддержать и общественную энергию того, что раньше называлось "ГИС-ассоциация".

Конкурентами у нас были коллеги из Иннополиса. У них была очень сильная заявка и очень хорошие оценки экспертов! Респект.

Ключевую роль сыграла поддержка Росреестра и Роскартографии, Роскосмоса, пяти рынков NET, Правительства Самарской области, Полпредства ПФО.

Теперь не облажаться бы.

По выходным - "лёгкое чтиво", ситуации для управленческих поединков

«Мелкие, но вонючие»

Мы поставили ПО на 100 тысяч рублей для вновь образовавшейся землеустроительной фирмы ООО «Ветерок». Обучения не было, так как туда перешла от нашего прежнего заказчика сотрудница Глаша, которая знакома с нашим софтом и сказала, что «ничего не надо». Директор ООО «Ветерок» - брат чиновника из Администрации, который влияет на крупные бюджеты, при начале сотрудничества от него были звонки с просьбой помочь его брату. Через месяц после поставки звонит Глаша и говорит, что ничего не может сделать, так как по прежнему месту работы у нее была база данных, все настроено, а тут «ничего этого нет», а ей срочно сдавать работу по оцифровке крупной территории.

Роли и интересы

Землемеров Иван Карлович (Директор ООО «Ветерок») - выполнить договор по оцифровке, наладить дальше техпроцесс, не платить дополнительных денег за софт нам, в крайнем случае – надавить через брата.

Глаша – сделать работу по оцифровке, обеспечить себе комфортные условия работы «как на прежнем месте»

Чернов (наш руководитель) – не потерять Заказчика ООО «Ветерок», разрешить ситуацию себе не в убыток, сохранить репутацию перед Администрацией.

Маша (наша сотрудница) – не делать дополнительной работы по-возможности, «проучить Глашу», так как на этапе заключения договора она демонстрировала всезнайство и пренебрежение, отказалась от наших разумных предложений.

ГИСОГД. Как обеспечить качество и непротиворечивость данных.

Приказ 433 регламентирует правила ведения ГИСОГД в части корректности и полноты заполнения данных.
Большинство требований достаточно простые типа:
- поле ХХХ является обязательным;
- в папку "Утверждающий документ" должен быть прикреплен файл формата *.doc или *.pdf вместе с ЭПЦ *.sig";
- у РС должна быть ссылка на документ ГПЗУ или ППТ/ПМТ.
Есть более сложные условия, типа "не требовать тех. плана для РВ, если РВ выдан ранее 13.07.2015".
Программистам в коде их реализовать не сложно, но когда условий становится больше сотни, и еще не надо их менять под законы и требования, нужен специальный инструмент.

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

В результате пользователи системы (операторы из ОМС) не могут ввести "кривые" и неполные данные, которые не будет соответствовать информационной модели 433 приказа и требованиям градкодекса.

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

Не сильно "веселый" и не сильно красивый пост - мораль тоже скучная, как этот дождливый понедельник. Все что может ввестись неправильно - введется неправильно, поэтому тщательно и нудно надо с самого начала обеспечивать непротиворечивость данных , такими простыми и понятными верификаторами. Иначе потом будете несколько лет выгребать и никогда не выгребете.

Дорогие друзья, подписчики! С Новым Годом! Мы, конечно, месяц пошумели, а потом подзависли на целых 2 месяца из-за сдачи проектов. Очень извините нас! После каникул, конечно, продолжим.
Желаем вам мира и добра в новом году!

Друзья, рассказываем,что 2023й год у нас на столько плодотворный, что немного подзабыли про наш канал.
А нам есть чем поделиться с вами😊. Например, сегодня наши коллеги побывали с деловым визитом в Минске и встретились с директором РЦТТ Александром Успенским и замом директора по производству УП «Геоинформационные системы» НАН Беларуси Игорем Страшко.
В ходе данного мероприятия обменялись опытом и обсудили состояние и перспективы реализации процесса Дорожной карты научно-технического сотрудничества между Национальной академией наук Беларуси и АНО «Институт регионального развития» управляющей компанией научно-образовательного центра мирового уровня «Инженерия будущего» на 2022-2025 гг.
Подробностей будем ждать от наших коллег по возвращении домой😊.
_____
На фото презентуем КСДМ.