Начнем рассказывать еще об одном нашем проекте - Комплексная система дистанционного мониторинга (КСДМ), с которым мы в этом году победили на ПрофИТ.

Мы считаем, что суть любого проекта надо уметь объяснить в двух словах "на пальцах"👌.

Что такое региональная геоинформационная система (РГИС) в двух словах?
Это набор тематических слоев, +/- согласованных по координатам (на одной основе), с ответственностью за предоставление данных. Ключевое тут ответственность, поэтому в РГИС надо меряться не количеством слоев, к примеру, а количеством слоев с регламентами на их изменение.

Что такое КСДМ в 2 словах? Дополнение к РГИС, которое дает возможность дистанционно мониторить текущую ситуацию и сравнивать с декларативным описанием, чтобы находить возможные нарушения. Ключевым является наличие "официального" цифрового описания (иначе - что мониторить?), дешевизна и простота мониторинга и встраивание в процессы управления. А то все любят заниматься мониторингом без ответственности: тут перемониторил, здесь недомониторил - всегда можно свалить на качество исходных данных 😊.

Чем мы отличаемся от подобных систем (например, космического мониторинга от федеральных компаний)?
а) комплексностью - стараемся иметь полную картину по всем направлениям. Сейчас их 5: сельхозка, лес, карьеры, отходы, недвижимость, на подходе памятники природы, объекты культурного наследия, вода, потребрынок и др.
б) "дистанционный мониторинг" понимаем в широком смысле - получение любыми неконтактными методами информации об объектах и процессах. Поэтому там намешаны ДДЗ, внешние информационные системы, системы обратной связи с населением и пр.
в) четкие процессы на одной технологической платформе:
цифровое описание ➡️ мониторинг ➡️ камеральная и полевая верификация ➡️ контрольно-надзорные действия 🔙.

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

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

Небольшая презентация https://disk.yandex.ru/d/odTH38NPju-QOA с ПрофИТ. Про КСДМ и ее отдельные направления будем рассказывать тут, возможно уже завтра. Тема и платформа готовы к тиражированию, пишите - звоните.

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

Тем не менее, внутри у нас 3 процесса:
1) Мониторинг и верификация лесоизменений
2) Установление границ лесного фонда и лесная амнистия по 280-ФЗ.
3) Учет и мониторинг состояния лесов (ну например, у всех лесников в навигаторах есть карта лесных кварталов и выделов, они ее используют при выездах), госуслуги (автоматизируем выписку из лесного реестра) и пр.
Сегодня про первый процесс.

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

Исходные данные:
Космические снимки за текущий и предыдущий год (мы используем снимки разрешения 10 м).
Список плановых/законных рубок из Минлесхоз.
Оцифрованные слои лесных выделов/кварталов/лесничеств.

Этапы:

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

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

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

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

5. Информация о незаконных лесоизменениях передается в соответствующие органы, результаты контрольно-надзорной деятельности сохраняются в КСДМ.
——
В 2020 году всего было выявлено более 200 лесоизменений, в 2021 - около 300, мониторинг 2022 года завершим в ноябре. Незаконных вырубок из них - единицы (но даже заведено 1 уголовное дело), ложных обнаружений - менее 1%.

Четверг - день технического сообщения 💡.

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

На простом уровне:
- вместо XML теперь везде JSON;
- REST;
- OpenAPI (Swagger) для метаданных.

Часть стандартов переделаны и переименованы:
Для растров WMS -> Maps
Для векторных данных WFS -> Features
Для покрытий WCS -> Coverages
Для тайлов WMTS -> Tiles (и теперь в векторе в том числе).

А часть новые, и их много:
Records - для доступа к документам, привязанным к пространственным объектам;
Processes - для вычислительных и бизнес-процессов над объектами;
EDR - для метеоданных и всего что связано с климатическими моделями;
Styles - стилизация объектов на клиентах (Mapbox Style как json-формат описания стилей, но SLD тоже можно, если очень хочется);
Routes - для описания маршрутов;
Joins - для объединения данных из разных источников;
Moving Features - для публикации движущихся объектов, таких как общественный транспорт, сельхозтехника и др.

Разработку ведем сами на .net и в опенсорсе. Почему?
- не хотелось тащить большое монолитное ПО, из которого нужна только часть функций, собираем софт из блоков на уровне кода;
- когда начинали, ни GeoServer, ни MapServer ещё не поддерживали новые стандарты
- проще управлять авторизацией, если нужно привязать доступ к объектам в существующей инфраструктуре распределения прав в приложении;
- стандарты в реальности сильно проще чем старые, основное - понять, что же имели в виду авторы;
- можно тренировать студентов на "внутренностях" ГИС-ов, web-стандартов.

Что уже сделали:

- Features

Part 1: Core - публикация данных в GeoJSON
Part 2: Coordinate Reference Systems by Reference - базовая поддержка нового вида описания систем координат
Part 4: Create, Replace, Update and Delete - операции по изменению данных.
Источники данных: Sql Server или PostgreSql/PostGIS, в ближайших планах - MongoDB, она идеально ложится на стандарт.

- Tiles 

Пока только MVT. Растры на будущее.
Источники данных: Sqlite (mbtiles), Sql Server, PostgreSql/PostGIS с формированием тайлов на лету.

Внедрили в наши продукты - ГИСОГД и ГИС АПК для градостроительства и сельхозки. Эффект - все сильно быстрее и сильно проще. Ну и редактор MVT сделали на их основе, о нем в следующий раз.
——
Переходите на эти стандарты! Ну и как вариант - берите нашу реализацию.

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

Пятница - день студентов.😇

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

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

1. Выделили три основные компетенции: программист, анализ данных, специалист по информационной безопасности (антихакер), по которым могут после окончания ВУза работать студенты.

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

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

3. Отправили программу всем ИТ-фирмам, получили фидбек, фактически "согласовали" программу с ними, понимая, что они основные работодатели.

4. Сделали спецкурсы силами аспирантов в уже существующем учебном плане (Питон, C# и пр.). Общая идеология: сначала спецкурс вне учебной программы, если есть интерес и прошло апробирование - вставляем в основную.

5. Как "хороший человек - не профессия", так "хороший и знакомый преподаватель - прочитай чего хочешь" - не ведет к системным знаниям у студентов. Поэтому либо ВУЗ платит преподавателю за "ТЗ на чтение курса", либо "читай что хочешь - но спецкурс во внеучебное время". Наши ребята выстроили по блокам сквозное ТЗ, чтобы закрыть компетенции. Расклад такой, что сейчас программирование читают только действующие программисты, блок анализа данных - научные работники, специализирующие на этом, ну и так далее.

Работа со студентами "планово-убыточная", и нам тяжело до усрачки 💀, вместо 2 групп два года назад - теперь их 4. Но есть и несомненные плюсы
- никого не надо учить выступать публично;
- внутреннее допобразование;
- общий движ;
- главное: приток кадров.

Приходите к нам учиться!

Краткая презентация по блоку "Программирование"

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

«Козельский район» - описание ситуации.

По заказу администрации региона мы разработали сложный хороший софт (пусть ГИСОГД) и внедрили его во все муниципалитеты. Один из муниципалитетов (Козельский район) против работы в системе, так как у них до этого стоял простой самописный софт и «их все устраивало». Мы обеспечили миграцию данных, но так как их программное обеспечение выполняет лишь часть функций, настояли на работе в нашем общем софте. На очередном совещании Губернатор отчитывает главу Козельского района за падение темпов выдачи документов и спрашивает причину. Глава Козельского района, ссылаясь на своих специалистов, говорит, что виноват наш новый софт, и то что раньше делалось час, сейчас делается 4 часа, и у их специалистов появилось много новой работы. Губернатор поручает разобраться профильному министерству.

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

1. Факир Игнатьевич (начальник департамента Козельского района) – остаться в своей привычной среде, так как им лень изучать новый софт и они думают, что для них будет много допработы, в крайнем случае – свалить на нас все свои недоработки.

2. Василий (руководитель проекта по внедрению ГИСОГД) – перевести район на свой софт, чтобы снизить издержки по техподдержке, миграции и обеспечить дисциплину всех муниципалитетов, сохранить свою репутацию.

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

Сегодня про 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. Главное – синхронизация по времени.
——-
Слово обратно менеджеру Андрею.

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

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