Від правової норми до відкритого просторового протоколу
Норма — це ще не процедура
Я працюю з геопросторовим аналізом, але дедалі більше мене цікавить ширше питання: як перетворити публічне правило на процес, який люди можуть перевірити, повторити та вдосконалити?
Правова норма може визначати відстань, поріг або обмеження. Проте залишається практичний розрив. Які дані слід використати? Як представлена берегова лінія? Як виміряно рельєф? Чи може інший аналітик повторити результат? Якщо ці рішення залишаються всередині закритої експертної процедури, громадськість бачить межу, але не бачить, як її отримано.
Моя пропозиція доволі проста: якщо правило має вимірювані просторові параметри, його реалізацію можна опублікувати як відкритий протокол — інструкції, дані, алгоритм, програмну модель, метадані, тести, обмеження та історію версій, необхідні для перевірки розрахунку.
Чому саме прибережні захисні смуги?
Водне та земельне законодавство України описує мінімальну ширину прибережних захисних смуг і умову рельєфу, за якої мінімальна ширина подвоюється. Чинні офіційні тексти доступні у Водному кодексі України та Земельному кодексі України.
Це робить тему зручною для перевірки відкритого протоколу: правило містить вимірювані поняття, але його просторове застосування залежить від якості даних, масштабу, геометрії берегової лінії та явної процедури розрахунку.
Представлений результат є аналітичним шаром попередньої перевірки. Це не офіційно чи юридично встановлена межа; він не визначає прав на землю та не замінює документацію із землеустрою або рішення компетентного органу.
Що саме я перевірив
Для цього прикладу на порталі я використав легший із двох реальних тестових наборів, щоб увесь процес можна було виконати на неттопі, а файли залишалися зручними для завантаження:
- територія аналізу площею 5,457 км²;
- цифрова модель рельєфу з розміром пікселя 1 м;
- 42 полігональні та 10 лінійних водних об’єктів;
- діапазон висот від 128 до 216 метрів;
- вихідна система координат EPSG:5564 (УСК-2000 / зона 6 Гаусса–Крюгера).
Атрибути водних об’єктів не містять юридичної класифікації кожного об’єкта. Тому я використовую 50 метрів як видимий тестовий параметр, що відповідає збереженому прикладу в моделі, а не стверджую, що саме 50 метрів є належною нормативною шириною для кожного об’єкта цього набору.
Дослідити результат
Як працює розрахунок
Опублікований похідний шар відтворює метод, описаний у вихідному репозиторії:
- Полігональні водні об’єкти та буферизовані лінійні об’єкти перетворюються на спільне представлення берегової лінії.
- Для кожного коректного пікселя рельєфу визначаються найближчий піксель берега та його висота.
- На кільці 50 м висота рельєфу порівнюється з висотою найближчої точки берега.
- Позначаються пікселі берегової лінії, пов’язані з підйомом, більшим за тангенс кута 3°.
- Усюди зберігається базова аналітична смуга 50 м, а там, де спрацьовує перевірка рельєфу, вона вибірково розширюється до 100 м.
- Результат публікується як класифікований GeoTIFF і як вектори GeoPackage та GeoJSON.
Розрахунок сформував 0,756 км² аналітичної зони нормативної ширини та ще 0,411 км² розширення через ухил. Ці цифри описують саме цю версію вхідних даних і ці параметри, а не універсальний юридичний результат.
Оригінальна модель QGIS поширюється без змін. Вона використовує ProjectCrs та @project_folder, тому для відтворення з командного рядка потрібен проєкт QGIS у EPSG:5564. Для вебпохідного шару я також публікую швидший сценарій на основі масивів, який реалізує задокументовані кроки відстані, висоти та порогового значення.
Від експертного результату до спільної інфраструктури
Йдеться не про те, щоб алгоритм замінив публічну владу. Держава й надалі визначає норму, її юридичний зміст, вимоги до офіційних даних, процедурні гарантії та способи оскарження.
Корисна зміна полягає в тому, що операційний рівень стає перевірюваним. Аналітики можуть заперечити параметр. Держателі даних можуть поліпшити вхідні шари. Громади можуть побачити, де виникає невизначеність. Розробники можуть повідомити про програмну помилку. Кожне виправлення створює нову відстежувану версію, а не непояснену заміну.
Саме це я називаю відкритим просторовим протоколом: не врядуванням за допомогою програми, а спільним технічним об’єктом, навколо якого може відбуватися публічне обговорення.
Дані, інструменти та джерело
Повний запис ресурсу містить вихідний архів, окремі файли ЦМР і водних об’єктів, похідний растр і вектори, модель QGIS, теоретичну записку, метадані, контрольні суми та сценарій відтворення.
Робоче джерело методу, покрокові пояснення та історія обговорення залишаються у GitHub-репозиторії oleksaboiko/pzs_method.
Атрибуція: метод, публікація даних та інструмент QGIS — Олексій Бойко і Юлія Максимова, версія 1.0.0, ліцензія CC BY 4.0.