ВІДКРИТИЙ ЛИСТ

ВІДКРИТИЙ ЛИСТ

 

Міністерству розвитку громад та територій України

01601, м. Київ, вул. Велика Житомирська, 9

 

заступнику міністра з питань цифрового розвитку, цифрових трансформацій і цифровізації

Олександру ДУДЧЕНКУ,

заступнику міністра розвитку громад та територій України Наталії КОЗЛОВСЬКІЙ

 

Щодо питань та пропозицій до структури бази геоданих містобудівної документації на місцевому рівні, затвердженої наказом Міністерства розвитку громад та територій України № 56 від 22.02.2022 (далі Наказ БГД)

 

 

Питання необхідності введення уніфікованої структури для продукування та обміну геопросторовими даними (наборами профільних геопросторових даних) в складі містобудівної документації є актуальним ще з 2011 року та визначається законом України «Про регулювання містобудівної діяльності» від 17 лютого 2011 р. N 3038-VI, де зазначається що “містобудівна документація розробляється ... як набори профільних геопросторових даних у ... єдиній системі класифікації та кодування об’єктів будівництва для формування баз даних містобудівного кадастру”.

Тому розв'язання питання щодо розроблення зазначеної в Законі України «Про регулювання містобудівної діяльності» системи класифікації та кодування вважаємо необхідним та важливим кроком для країни, який реалізовано через затвердження Наказу БГД, в тому числі на виконання пункту 2 постанови Кабінету Міністрів України від 09 червня 2021 року N 632 "Про визначення формату електронних документів комплексного плану просторового розвитку території територіальної громади, генерального плану населеного пункту, детального плану території" та з метою забезпечення реалізації абзацу другого частини першої статті 16, частини тринадцятої, абзацу другого частини чотирнадцятої статті 161, частини дванадцятої, абзацу другого частини п'ятнадцятої статті 17, абзацу другого частини сьомої статті 19 Закону України "Про регулювання містобудівної діяльності".

З метою практичної реалізації структури  бази геоданих містобудівної документації на місцевому рівні (далі БГД), затвердженої наказом Мінрегіону №56 від 22.02.2022, організовано краудсорсинговий проект, в якому на добровільних засадах беруть участь декілька десятків фахівців із просторового планування, землевпорядкування, екології, спеціалістів із баз даних.

Кінцевий результат, розроблений файл БГД, буде доступний для всіх бажаючих для вільного використання, модифікування і поширення.

 

В процесі першого етапу практичної реалізації та апробації в середовищі геоінформаційної системи затвердженої структури бази геоданих містобудівної документації на місцевому рівні (далі Структури БГД) було сформульовано ряд питань та пропозицій, викладених в додатках до цього листа.

Просимо розглянути викладені зауваження та пропозиції.

Додаток А. Ймовірні “механічні” помилки у Структурі БГД на 4 сторінках.

Додаток Б. Пропозиції із доповнення Структури БГД на 6 сторінках.

Додаток В. Щодо надання роз'яснень по використанню БГД на 7 сторінках.

 

 

 

Підписанти:
 

Стоян Богдана Богданівна ГАП  ТОВ "ПРО ЗЕМ", архітектор Івано-Франківська філія УДНДІПМ "ДІПРОМІСТО" імені Ю.М.Білоконя"  fb: https://www.facebook.com/dana.stoyan, email: stoyanbogdana37@gmail.com

Юлія Максимова, к.т.н., ас. каф. геоінформатики і фотограмметрії КНУБА, ГІС-спеціаліст консультаційна група Juliesdata, fb: https://www.facebook.com/profile.php?id=100006853998055, email: office@juliesdata.com

Олексій Бойко, спеціаліст із ГІС, співзасновник в Julie's Data, експерт із питань стратегічної екологічної оцінки громадської ради Міндовкілля

Піліпака Надія Володимирівна, провідний архітектор ПП "Землебудпроект" м. Рівне, fb: https://www.facebook.com/miriklli,  email: pilipaka.nadja@gmail.com

Володимир Мельник, головний архітектор проектів ТОВ "Херсонземпроект", facebook.com/MWW86

Пясецька Оксана Зіновіївна, ГАП ТзОВ "ПО"УкрЗахідУрбанізація",  fb:https://www.facebook.com/profile.php?id=100004658956873, email:12031992oksana@gmail.com

м. Полтава, заступник начальника управління з питань містобудування та архітектури, головного архітектора міста, начальник служби містобудівного кадастру Наталія Сирота, (0532)569533

Сметанюк Марія Іванівна, ТОВ "ПРО ЗЕМ", сертифікований-інженер землевпорядник, https://www.facebook.com/maria.smetanjuk

Кузишин Роман Ярославович. В.о. заступника директора-головний архітектор Івано-Франківської філії ДП УДНДІПМ «ДІПРОМІСТО» імені Ю. М. Білоконя

Заяць Василь Андрійович Начальник АПМ,  ГАП - Державне підприємство Український державний науково-дослідний інститут проектування міст «ДІПРОМІСТО» імені Ю.М. Білоконя Івано-Франківська філія zaiats1956@gmail.com

Янчук Віра Василівна, ДП "УкрНДПІцивіільбуд", керівник Сектору НМЗ ТП та ГІС, https://www.facebook.com/YanchukVira, email: yanchver@gmail.com, моб.т. 0932702703

Маркіна Марія Іванівна, сертифікований архітектор за напрямком розроблення містобудівної документації, старший викладач кафедри регіоналістики і туризму КНЕУ ім. В. Гетьмана,

к.т.н., начальник відділу ДЗЗ та аерокосмічного моніторингу ТОВ "Аналітика", Долинний Василь, https://www.facebook.com/profile.php?id=100002015883553, email: dolynnyivv@gmail.com

Журавель Богдан Максимович, спеціаліст-землевпорядник відділу земельних ресурсів виконавчого комітету Козельщинської селищної ради Кременчуцького району Полтавської області. Email: bogdan.zhuravel.00@gmail.com

Гандзюк Юрій, Сертифікований інженер-геодезист, email: ganzen@ukr.net

Кізілова Тетяна Богданівна, керівник групи АМП, ГАП Івано-Франківської філії ДП УДНДІПМ «Діпромісто» ім. Ю. М. Білоконя, ГАП ПП «Прикарпатський земельний центр»

Чачарський Максим Анатолійович, директор , головний Архитектор ТОВ «УКРГЕНПЛАН»

Тюрін Олександр Валерійович, м.Запоріжжя ТОВ "Інститут Ефективних Технологій - Гео" нач.відділу ТГВ, ГІС-спеціаліст email: TYurin.Alexander.zp@gmail.com

Скорик Микола Анатолійович, фізична особа-підприємець сертифікований інженер-землевпорядник. fb: https://www.facebook.com/mykola.skoryk email:m.a.skoryk@gmail.com
Головний архітектор проектів Ігор Саєнко, ФОП Саєнко

Олійник Павло Петрович, головний архітектор ТОВ "ПВІ "АГРОПРОЕКТ" м. Кропивницький

Гордієнко Олександр Вікторович, Інститут телекомунікацій та глобального інформаційного простору НАНУ, аспірант. Мала академія наук, методист, фахівець ГІС,

Агєєв Юрій Валентинович, директор ТОВ "Адміралті Офіс", проектувальник, м. Херсон

Возняк Марія Олексіївна, системний адміністратор групи ТЕХНІЧНОГО ЗАБЕЗПЕЧЕННЯ ВИПУСКУ ПРОЕКТІВ Івано-Франківської філії НДІ "ДІПРОМІСТО", email: mariavoznyak@gmail.com

ФОП Сорокін Артем Сергійович м. Запоріжжя, сертифікований інженер-землевпорядник, сертифікований інженер-геодезист,  email: dzk106zp@gmail.com https://www.facebook.com/dzk106

Новіцький Роман Григорович сертифікований архітектор за напрямком розроблення містобудівної документації, ФОП Новіцький Р.Г.

Мединська Ольга Василівна. Працюю у " майстерні комфорту " місто Львів

Тишкун Роман Юрійович, ФОП, експерт з управління земельними ресурсами та просторого планування

Голощапов Євгеній Миколайович, ТОВ "Інститут Ефективних Технологій - Гео", головний архітектор проектів.

ФОП Харлампова М.К.

директор ТОВ "ІНСТИТУТ МОДЕЛЮВАННЯ РОЗВИТКУ ТЕРИТОРІЙ"

Інженер-проектувальник (планування міст) ТОВ "ДЗК+" Олена Цвіль, fb:https://www.facebook.com/profile.php?id=100006261375498, email:m.elena_vladi@ukr.net

к.т.н., доцент кафедри автомобільних доріг, геодезії, землеустрою та сільських будівель НУПП, fb: https://www.facebook.com/profile.php?id=100060079237121, email: ir.v.tkachenko@gmail.com

Христина ФАМУЛЯК, директор ТзОВ «ПО « УкрЗахідУрбанізація», сертифікований архітектор, відповідальний виконавець окремих видів робіт (послуг), пов‘язаних із створенням об‘єктів архітектури - розроблення містобудівної документації

Романча Андрій Сергійович, директор ТОВ "Херсонземпроект", сертифікований інженер-геодезист, сертифікований інженер-землевпорядник, email: andreiromancha@gmail.com

О.Ю. Попович, Інженер-проектувальник (розроблення містобудівної документації), МКП "ВМЦМІА", https://www.facebook.com/alex.popovixh, insulmo07@gmail.com

к.т.н., доцент каф. міського господарства КНУБА, начальник майстерні ДП "ДІПРОМІСТО", головний архітектор проектів Ганна Айлікова, email: Aylikova@ukr.net

Крищук Юлія Василівна, інженер-землевпорядник МКП "ВМЦМіА", email: yulia.khursa@gmail.com

Ткаченко Ірина Володимирівна, к.т.н., доцент кафедри автомобільних доріг, геодезії, землеустрою та сільських будівель Національного університету "Полтавська політехніка імені Юрія Кондратюка" fb: https://www.facebook.com/profile.php?id=100060079237121, email: ir.v.tkachenko@gmail.com

Кухарська Христина, архітектор

ФОП Шикман Н. В.

Долженко Ірина Миколаївна, начальник управління містобудування та архітектури виконавчого комітету Олешківської міської ради, Херсонська область. k_strelets@ukr.net

Мамчур Дарина Миколаївна, землевпорядник, email: mamchurdaryna@gmail.com

Олександр Степаненко, архітектор, член НСАУ, НСХУ, академічний радник інженерної академії України, м. Херсон

керівник відділу архітектури, містобудування, земельних відносин та екології виконавчого комітету Новояричівської селищної ради

ГО «ПОСТГРЕС УКРАЇНА», ІТ-послуги та ІТ-консалтинг. Група для підтримки СКБД PostgreSQL спільноти

 

Додаток А. Ймовірні “механічні” помилки у Структурі БГД.

 

1. В розділі 1 “Класи та атрибути об’єктів” для класів просторових об'єктів (далі в листі класів) “main_oil_pipes” та “main_gas_pipes” атрибут з назвою “class” визначений два рази з різним семантичним значенням.  Один раз атрибут “class” визначений для обох згаданих класів як обов'язковий атрибут для всіх класів бази геоданих, а саме як “класифікаційний код”. Другий раз атрибут “class” визначений для класу “main_oil_pipes” у значенні “клас нафтопроводу”, а для класу “main_gas_pipes” у значенні “клас газопроводу”. Допускаємо, що це є “механічною” помилкою при укладанні структури бази геоданих, оскільки в межах одного класу не може бути атрибутів з однаковою назвою та різним семантичним значенням.
2. В розділі 1 “Класи та атрибути об’єктів” для класу  “power_plants” атрибут з назвою “source ” визначений два рази з різним семантичним значенням.  Один раз атрибут клас “source“ визначений як обов'язковий атрибут для всіх класів бази геоданих, а саме як “джерело даних”. Другий раз атрибут “source” визначений для класу “power_plants” у значенні “вид енергоносія”. Допускаємо, що це є “механічною” помилкою при укладанні структури бази геоданих, оскільки в межах одного класу не може бути атрибутів з однаковою назвою та різним семантичним значенням.
3. В розділі 1 “Класи та атрибути об'єктів” для класу  “railways_main” атрибут з назвою “sub_pro” визначений два рази (продубльований) з різним семантичним значенням, але однаковою назвою, а саме в одному випадку у значенні “інтенсивність руху приміських поїздів на довгостроковий період, пар/добу”, в іншому “інтенсивність руху приміських поїздів на середньостроковий період, пар/добу”. Допускаємо, що це є “механічною” помилкою при укладанні структури бази геоданих, оскільки в межах одного класу не може бути атрибутів з однаковою назвою та різним семантичним значенням.
4. В розділі 3 “Класи відношень” для класу відношень з назвою “m_irrig_nets_san_gap” визначено клас-джерело для цього відношення з назвою “main_irrigation_nets”, який відсутній в розділі 1  “Класи та атрибути об'єктів”. Назву класу потрібно визначити відповідно до розділу 1 Структури.
5. В розділі 3 “Класи відношень” для ряду класів відношень, наприклад “pub_trans_roads”, “pub_trans_streets”, “pub_trans_spec_r”, “pub_trans_forest_r”, “pub_trans_rail_m”, “pub_trans_rail_l”, “pub_trans_troll” визначено клас-джерело з назвою “public_transport_routes_l”, який відсутній в розділі 1  “Класи та атрибути об'єктів”. Передбачаємо, що це “механічна помилка” і для цих відношень передбачалося використовувати клас з назвою “public_transport_routes”.
6. В розділі 1 “Класи та атрибути об’єктів” для класу “function_zoning_pr” визначено деякі атрибути обов'язкові для введення при додаванні нового об'єкта до класу, які викликають певні суперечності. Доцільно обов'язковість введення (заповнення) значень для цих атрибутів переглянути. Наприклад, при додаванні нового об'єкта до класу “function_zoning_pr” із функціональним призначенням території (атрибут “type”) “території кладовищ та крематоріїв” або “території пляжів” та інші необхідно обов'язково заповнити (ввести) значення для атрибутів максимальна щільність населення в межах житлової забудови, осіб/га - “pop_dens”. У разі, якщо цей атрибут є обов'язковим для введення (заповнення) просимо надати роз'яснення щодо його коректного заповнення у випадках, викладених вище.
7. В розділі 5 “Таблиці”, де визначено таблиці для збереження метаданих про сам набір даних, не встановлено які “назви стовпчиків” (атрибути) цих таблиць є ключовими, що суперечить принципам проектування баз даних. Адже ці таблиці із метаданими є непросторовими таблицями БГД, а отже повинні мати визначені ключові атрибути. Просимо надати роз'яснення щодо того як із такими таблицями працювати та чи допускається довільне призначення ключового атрибуту.
8. В розділі 5 “Таблиці” для таблиці “ХХХХХХХХХХ_metadata” метадані проекту для “стовпчика” з назвою "Surv_First_Name" відсутнє (пропущене) роз'яснення (зміст стовпчика). Натомість для всіх інших “стовпчиків” такі роз'яснення наведені. Роз'яснення для значення "Surv_First_Name" доцільно навести за аналогією до інших роз'яснень в розділі 5.
9. В розділі 5 “Таблиці” для таблиці “ХХХХХХХХХХ_metadata” метадані проекту для “стовпчика” з назвою “Decision_Authority” в “змісті стовпчику” має місце “механічна помилка”. А саме там зазначено “Назва органу, щИ прийняв рішення щодо розроблення документації”, а потрібно “Назва органу, щО прийняв рішення щодо розроблення документації”. Доцільно скорегувати вказану помилку.
10. В розділі 2 “Переліки значень атрибутів” для переліку “water_sew_treat_kind” з псевдонімом “Характер стоків” визначені наступні значення в тому числі : “промилово-побутові” та “промилово-побутово-зливові”, в яких допущена в словах граматична помилка, пропущена буква “с”. Доцільно скорегувати вказану помилку.
11. В розділі 2 “Переліки значень атрибутів” для переліку “agro_landscape_subgroup” з псевдонімом “Агроландшафтна підгрупа земель” дублюються деякі значення. Зокрема “орнопридатні землі I групи на схилах до 3° “ повторюються три рази із кодом значень 1, 4 та 5. Доцільно зайві дублювання прибрати і зарезервовані під ці значення коди значень - призначити іншим значенням у цьому переліку.
12. В розділі 1 “Класи та атрибути об’єктів” для всіх класів обов'язковим визначено атрибут “class” - класифікаційний код. Атрибут “class” є обов'язковим для заповнення, а також для нього зазначено, як перелік допустимих значень “затверджується Мінрегіоном”. Необхідні додаткові роз'яснення щодо заповнення такого атрибуту поки відповідний перелік значень чи класифікатор не затверджено  Мінрегіоном. Також зауважимо, що діючий Перелік класів об’єктів містобудівного кадастру, затверджений Міністерством регіонального розвитку, будівництва та житлово-комунального господарства України наказом №193 від 14.08.2015, не узгоджується повністю із затвердженою структурою класів в Наказі БГД. Така ситуація викликає суперечність, оскільки класи, вже визначені в Наказі від 14.08.2015 No 193, не співвідносяться із Наказом БГД, а допоки інша класифікація не затверджена Мінрегіоном незрозумілим є, як саме потрібно заповнювати обов'язковий атрибут “class”. Просимо надати роз'яснення щодо викладеної ситуації та заповнення атрибуту “class”.
13. Для класу “heritage_monuments” (Пам'ятки культурної спадщини) атрибут “type” (тип пам'ятки) визначається через перелік допустимих значень “heritage_monum_type” (Тип пам'ятки культурної спадщини), що включає такі значення: археології, архітектури, містобудування, історії, монументального мистецтва, садово-паркового мистецтва, ландшафтна, науки й техніки. Статті 2 Закону України "Про охорону культурної спадщини" https://zakon.rada.gov.ua/laws/show/1805-14#Text передбачено класифікацію пам'яток за видами та типами.

Згідно з статтею 2 Закону України "Про охорону культурної спадщини" п. 1 за типами об'єкти культурної спадщини поділяються на: споруди (витвори), комплекси (ансамблі) , визначні місця.

Згідно з статтею 2 Закону України "Про охорону культурної спадщини" п. 1 за видами об'єкти культурної спадщини поділяються на: археологічні, історичні, об'єкти монументального мистецтва, об'єкти архітектури, об'єкти містобудування, об'єкти садово-паркового мистецтва, ландшафтні, об'єкти науки і техніки.

Пропонуємо узгодити атрибути та допустимі переліки значень, через які ці атрибути визначаються, для класу  “heritage_monuments” із Законом України  "Про охорону культурної спадщини", а саме:

а) назвати атрибут “type” відповідно до змісту переліку допустимих значень “heritage_monum_type” та статті 2 Закону України "Про охорону культурної спадщини" - як “вид об'єкти культурної спадщини”;

б) додати до класу “heritage_monuments” атрибут тип об'єкта культурної спадщини, який буде відповідати статті 2 п. 1 Закону України "Про охорону культурної спадщини" та визначатися через перелік допустимих значень, таких як споруди (витвори), комплекси (ансамблі) , визначні місця.

14. Вважаємо за доцільне привести у відповідність до Земельного Кодексу України частини першої статті 19 пункту ж формулювання категорії земель, а саме замінити слово "зв'язку” на “електронних комунікацій" для допустимого переліку значень "land_category" (Категорія земель).
15. Для класу “landuse” (Угіддя) встановлено атрибут “landuse” (вид угіддя), для класу “landuse_violation” (Території порушення складу угідь) встановлено атрибути “legal” (угіддя згідно з документами або даними ДЗК) і “factual” (угіддя фактичні), які визначаються через переліку допустимих значень “landuse_type” (Тип угіддя). Для перелічених атрибутів визначено тип атрибутивних даних “String” і не визначено довжина текстового поля за аналогією з іншими атрибутами, для яких визначено тип атрибутивних даних “String”. Аналізуючи кількість символів у значеннях переліку допустимих значень “landuse_type” (Тип угіддя) доцільно встановити обмеження кількості символів 255.
16. Для класу “planning_forms” (Планувальні утворення в населених пунктах) в Структурі БГД визначено тип геометрії “Polyline” (лінія), а також встановлено обов'язковий для заповнення атрибут “type” (тип утворення), який визначається через перелік допустимих значень “planning_form_type” (Тип планувального утворення в населених пунктах), що містить такі елементи: житловий район, житловий квартал, мікрорайон, планувальний район, планувальний центр, планувальна зона, промислова зона, промисловий район. Відповідно ДБН Б.2.2-12:2019 п. 3. “Терміни та визначення понять”, п. 5. “Просторова-планувальна організація територій” такі планувальні утворення як житловий район, житловий квартал, мікрорайон, планувальний район, планувальний центр, планувальна зона, промислова зона, промисловий район мають визначатися через тип геометрії “Polygon” (полігон). Отже, для класу “planning_forms” доцільно встановити тип геометрії “Polygon” (полігон) для виокремлення даних планувальних утворень в населеному пункті через встановлення просторових взаємозв'язків із іншими сутностями БГД, які містяться/не містять/тощо в межах планувальних утворень, в тому числі для автоматизації процесів пошуку, фільтрації об'єктів всередині “полігону”(геометрії) цих утворень. Допускаємо, що визначений тип “Polyline” (лінія) для класі “planning_forms” є помилкою і вважаємо за доцільне змінити тип геометрії на “Polygon” або в іншому випадку надати роз'яснення щодо встановлення типу геометрії для класу “planning_forms “Polyline” (лінія).
17. Згідно зі статтею 26 п. 4 Закону України "Про регулювання містобудівної діяльності" деякі складові реквізитів адреси, втому числі назва вулиці, площі, майдану, шосе, проспекту, бульвару, алеї, провулку, узвозу тощо вказуються лише за умови їх наявності (тобто є не обов'язковими для зазначення).

Згідно з п. 15 постанови Кабінету Міністрів України №690 від 07.07.2021 «Про затвердження Порядку присвоєння адрес об’єктам будівництва, об’єктам нерухомого майна» реквізит адреси “назва поіменованого об’єкта” використовується для об’єктів, що розташовані за межами населених пунктів, замість реквізиту “назва населеного пункту” у разі, коли ідентифікувати об’єкт без зазначення такої назви неможливо.

Виходячи із вищезазначеного потрібно привести вимоги Структури БГД  щодо обов’язковості заповнення атрибутів  “settlem” (населений пункт), “st_name” (назва вулиці), “st_type” (тип вулиці), “build” (номер будинку) класу “address” (Адреси) до вимог ЗУ "Про регулювання містобудівної діяльності" та КМУ №690 від 07.07.2021, зокрема для атрибутів  “settlem” (населений пункт), “st_name” (назва вулиці), “st_type” (тип вулиці), “build” (номер будинку) класу “address” (Адреси)  задати “Дозвіл на пусті значення” як “nullable”, тобто не обов'язкові для заповнення (допускаються пусті значення атрибутів).

Також, виходячи з постанови №690 від 07.07.2022 для атрибута “block” (корпус, квартира) рекомендовано встановити  класифікатор (корпус, будинок, ділянка, гараж).

 

Додаток Б. Пропозиції із доповнення Структури БГД.

1. Згідно з Законом України “Про національну інфраструктуру геопросторових даних” профільні набори геопросторових даних та метадані містобудівної документації належать  до тематичних даних національної інфраструктури геопросторових даних. Згідно зі статтею 9 п. 1. Закону України “Про національну інфраструктуру геопросторових даних” Україна бере участь у міжнародному співробітництві з питань діяльності з геопросторовими даними, метаданими та інфраструктурами геопросторових даних відповідно до норм міжнародного права. Згідно з  Порядком функціонування національної інфраструктури геопросторових даних, затвердженої Кабінетом Міністрів наказом №532 від 26.05.2021 року, вимоги до структури та змісту метаданих визначаються відповідно до вимог національного стандарту ДСТУ ISO 19115-1 (ISO 19115-1:2014, IDT) “Географічна інформація. Метадані - Частина 1: Основи”. Отже, оскільки набори геопросторових даних містобудівної документації є складовою профільних наборів геопросторових даних національної інфраструктури геопросторових даних, то виникає питання щодо неузгодженості структури таблиць для збереження метаданих, визначених в розділі 5 “Таблиці” Наказу БГД. Рекомендуємо структуру метаданих в розділі 5 “Таблиці” Наказу БГД узгодити із вимогами Порядку функціонування національної інфраструктури геопросторових даних та ДСТУ ISO 19115-1 (ISO 19115-1:2014, IDT) для забезпечення їх інтероперабельності на подальших етапах використання наборів даних.
2. При проєктуванні БГД виділяють наступні рівні моделювання: концептуальний, логічний (зовнішній) та фізичний (внутрішній), які відповідають термінології за міжнародними та національними стандартами з інформаційних технологій, зокрема ДСТУ ISO/IEC 2382:2017, ДСТУ 8774:2018 та іншими. Концептуальна модель є абстрактним описом концептів предметної сфери (понять, складу, структури та зв’язків) з використанням базових формалізмів обраного загального підходу моделювання даних незалежно від фізичного середовища реалізації бази даних. Логічна модель враховує особливості певного програмного середовища, тобто відображає концептуальну схему у певні мовні конструкції та схематичні позначення вибраного програмного забезпечення. Аналізуючи опис структури БГД прослідковується комбінування концептуальної та логічної схеми, зокрема деякі розділи описані термінологією конкретного програмного забезпечення, що ускладнює роботу з описом БГД та в деяких випадках не дає можливості однозначно інтерпретувати “задум” розробників. В розрізі викладеного особливі складності викликає розділ 3  “Класи відношень”, який потребує додаткових роз'яснень, оскільки розділ 3 частково описано як логічну модель. Параметри та термінологія потребують уточнення.

Для уникнення неоднозначностей та подвійного тлумачення, для кожного класу просторових об'єктів та його атрибутів в розділі 1 “Класи та атрибути” доцільно додати розширене визначення з роз'ясненнями щодо його використання або визначення. Наприклад, обов'язковий атрибут для всіх класів “джерело даних” - можна трактувати по різному, наприклад зазначати виконавця, а можливо як виготовлялися ці дані тощо. Аналогічні приклади трактування можна навести й до значної кількості й інших класів та атрибутів. До того ж, в процесі апробації БГД робочою групою, яка включає практикуючих архітекторів та землевпорядників виникали розходження  у трактуванні призначення (використання) деяких класів та атрибутів, що говорить про можливі різні тлумачення у практикуючих спеціалістів.

Для розділу 3 “Класи відношень” та 4 “Правила топології” доцільно надати визначення термінів, які використовуються для опису класів відношень, а також правил топології, для уникнення неточностей та неоднозначного тлумачення.

3. Для атрибутів, які можуть визначатися через різні одиниці вимірювання, наприклад площі, довжини об'єктів, розміри різних зон обмежень тощо, має бути в описі атрибута (про важливість якого ми зазначали вище) вказано одиницю вимірювання, через який він визначається для уникнення помилок при зведенні та/або інтерпретації даних, зведенні даних з різних наборів в єдині БГД тощо. Пропонуємо в описі атрибутів конкретизувати всюди одиниці вимірювання.
4. Для класу “streets” (Вулиці та дороги населених пунктів) встановлено атрибут “signific” (значення вулиці). Атрибут “signific” визначається через перелік допустимих значень street_significance (Значення вулиці), де пропонується такий перелік допустимих значень: не визначено, магістральна дорога безперервного руху, магістральна дорога регульованого руху, магістральна вулиця загальноміського значення безперервного руху, магістральна вулиця загальноміського значення регульованого руху, магістральна вулиця районного значення, вулиця (дорога) місцевого значення.

Тобто, фактично перелік допустимих значень “street_significance” визначає категорію вулиці згідно з  ДБН Б.2.2-12:2019 "Планування та забудова територій" додатку Ж-1. При цьому  ДБН Б.2.2-12:2019 "Планування та забудова територій" додатку Ж-1 передбачається більше категорій для вулиць. Частина значень категорії вулиць представлена у вигляді інших класів. Але в переліку допустимих значень “street_significance” та інших класах  відсутні наступні значення: головна вулиця, основна вулиця, другорядна вулиця.

Пропонуємо доповнити та узгодити перелік допустимих значень “street_significance” відсутніми елементами відповідно до додатка Ж-1 ДБН Б.2.2-12:2019 "Планування та забудова територій" (а саме головна вулиця, основна вулиця, другорядна вулиця), а також перейменувати атрибут “signific”  згідно з найменуванням в додатку Ж-1 ДБН Б.2.2-12:2019, а саме: категорія.

5. Для класів, які належать до наборів класів “Structures”, “Transport_networks”, “Engineering_networks”, “Inf_social_objects”, “Inf_tourism_objects”, “Inf_community_facilities”, “Inf_enterprise_objects”, “Inf_transport_objects”, “Inf_engineering_objects”, а також для деяких окремих класів з інших наборів класів встановлено як обов'язковий атрибут “state” (статус об'єкта), який має визначатися через перелік допустимих значень атрибутів “state” (Статус об'єкту), що передбачає такий перелік допустимих значень: не визначено, існуючий діючий, існуючий недіючий, на реконструкції, на стадії будівництва (реалізації), зруйнований (руїни), законсервований, занедбаний, проектний, проектний на короткостроковий період, проектний на середньостроковий період, проектний на довгостроковий період, запроектований раніше, аварійний.  Такий перелік допустимих значень не є доцільним для всіх класів, в деяких випадках цей перелік допустимих значень доцільно звузити.

Тому пропонуємо для кожного атрибуту “state” (статус об'єкта) в кожному конкретному класі вказати, які самі значення можуть застосовуватися із переліку допустимих значень “state” , що в тому числі “підвищить” рівень забезпечення цілісності даних через неможливість виробу статусу об'єктів, які є не коректними для конкретного класу.

6. В розділі 1 “Класи та атрибути об’єктів” для більшості класів із набору класів просторових об'єктів “Restrictions” визначено атрибут “res_code” (код обмеження), який визначається через перелік значень “restr_code”.  Перелік значень “restr_code” має 129 допустимих значень. Але для кожного класу значення із переліку  “restr_code” може (повинна) обиратися лише частина зі 129 допустимих позицій. Доцільно для кожного класу для атрибуту  “res_code” вказати які саме значення із переліку  “restr_code” є допустимі для вибору. Обмеження домену значень зазначеним шляхом “підвищить” цілісність даних, звузивши можливість вибору не вірного коду обмеження для класу.
7. Клас “pzf_pg” (Території та об'єкти природно-заповідного фонду) має серед інших атрибут “pa_name” (назва). Клас “pzf_protected_zones” (Охоронні зони об'єктів природно-заповідного фонду) має серед інших також атрибут “pa_name” (назва об'єкта ПЗФ). Окрім того,  в розділі 3 “Класи відношень” передбачено відношення між цими класами “pzf_prot_z_pzf_pg”. Таким чином, зберігання назви об'єкту ПЗФ у класі “pzf_pg” та “pzf_prot_z_pzf_pg” є дублюванням з точки зору організації збереження даних у БГД. Пропонуємо для класу “pzf_prot_z_pzf_pg” прибрати атрибут “pa_name”.
8. В класі “chemical_line_hazad_areas” (Зона можливого хімічного забруднення від ХНО лінійної протяжності) атрибут “type” (підклас зон можливого хімічного забруднення від ХНО лінійної протяжності) визначається через перелік допустимих значень “chemical_line_hazad_area_type” (Тип зони можливого хімічного забруднення від ХНО лінійної протяжності). Перелік допустимих значень “chemical_line_hazad_area_type” містить наступні значення: зона можливого розповсюдження небезпечної речовини до від 0 до 2,5 км, зона можливого розповсюдження небезпечної речовини до від 2,5 до 5,0 км.

Згідно ДСТУ-Н Б Б.1.1-19:2013 “Настанова з виконання розділу інженерно-технічних заходів цивільного захисту у містобудівній документації на мирний час”, а саме “третя зона можливого хімічного забруднення знаходиться на відстані більше ніж 5,0 км від джерела хімічної небезпеки”. Відповідно до ДСТУ-Н Б Б.1.1-19:2013 п. 4 “Містобудівне моделювання небезпек на території міста від можливих надзвичайних ситуацій” оскільки повна глибина зони розповсюдження небезпечної хімічної речовини від зазначеної можливої надзвичайної ситуації на магістральних залізницях (аміакопроводу) може складати до 20 км, а третя зона окреслюється як розмір від 5,0 км і більше.

У відповідності з  ДСТУ-Н Б Б.1.1-19:2013: Безпечні райони знаходяться за межами 100-кілометрової зони можливого сильного радіоактивного забруднення, а також за межами першої, другої та третьої зон впливу можливого хімічного забруднення від магістральної залізниці і аміакопроводу та зони можливого катастрофічного затоплення. Відповідно до ДСТУ-Н Б Б.1.1-20:2013: одним з головних завдань виконання розділу ІТЗ ЦЗ (ЦО) є визначення безпечних районів та розрахунки ємності безпечних районів… без врахування хімічної небезпеки від магістральної залізниці (аміакопроводу) - перший варіант, та із врахуванням такої - другий варіант. Це все говорить про те, що третя зона можливого хімічного забруднення не є повним еквівалентом безпечного району, який необхідно визначати для розміщення евакуйованого населення.

Висновок: для підготовки схем інженерно-технічних заходів цивільного захисту доцільно додати можливість визначення третього типу зони можливого розповсюдження небезпечної речовини від 5,0 км до 20,0 км 

9. Для забезпечення оперативного реагування на сьогоденний воєнний стан пропонуємо для класів “civil_protect_constr_pg” (Захисні споруди цивільного захисту) та “civil_protect_constr_p” (Розташування захисних споруд цивільного захисту) атрибути: “cap_in” (ємність існуюча, осіб), “cap_pr” (ємність на короткостроковий період, осіб), “cap_pro” (ємність на середньостроковий період, осіб), “cap_ext” (ємність на довгостроковий період, осіб) відокремити прогнозовані показники (періоди) від роз’яснення, яке надано в пп. 28 п. 2 Постанови Кабінету Міністрів № 926 (до 5 років, 6-10 років та понад 10 років) та внести такі строкові показники, відповідно: до 1 року, до 3 років, до 5 років.
10. Відповідно до ДБН Б.2.2-3: 2021 "Склад та зміст історико-архітектурного опорного плану населеного пункту" обов'язковою складовою історико-архітектурного опорного плану населеного пункту є фотографії об'єктів культурної спадщини (щойно виявлених об'єктів культурної спадщини, значних історичних будівель, втрачених пам'яток, фотофіксація видового розкриття пам'яток архітектури та містобудування).

Пропонуємо для класів "heritage_monuments” (пам'ятки культурної спадщини), "historic_build” (історична забудова), "heritage_mon_areas” (визначні місця - пам'ятки культурної спадщини), "lost_objects” (значні втрачені об'єкти), “thresholds” (Характерні відстані (якісні пороги) видового розкриття пам'яток архітектури),” monuments_view_areas”   ( Зони огляду пам'яток архітектури), “review_point” (Оглядові точки), “review_axes” (Оглядові осі), “review_fronts” (Оглядові фронти), “view_zones” ( Зони формування видів) додати атрибут “Photo” (фотографії) із типом даних String, який буде призначений для зберігання посилання на відповідну теку (архів) із фотографіями, які будуть передаватися разом із набором документів містобудівної документації як їх невіддільна частина.

Згідно з ДБН Б.2.2-12:2019 п. 13.2.3 має бути забезпечено при розробленні містобудівної документації збереження чергування відкритих просторів із забудованими територіями для забезпечення видового розкриття об’єктів культурної спадщини, підсилення естетичних характеристик і композиційних особливостей історичної забудови, виявлення і відновлення композиційно-візуальних зв’язків між історичними архітектурними домінантами, рядовою забудовою і ландшафтом, для чого визначаються оглядові точки, що повинні мати певний “напрям” (кут огляду). Пропонуємо для класу “review_point” (Оглядові точки) додати атрибут “angle” (кут повороту) з типом даних Double, який буде призначено для збереження значення напрямку (кута) для огляду.

11. Для класу “agro_soil” (Агровиробничі групи ґрунтів) визначено атрибути “agrogr” (назва агрогрупи), “agrogr_с” (кодова позначка агрогрупи), які визначаються через переліки допустимих значень, зокрема “agrogroup_name” та “agrogroup_code” відповідно. Для обох атрибутів “agrogr” та “agrogr_с” встановлено тип атрибутивних даних - String, довжина текстового поля - 5. Отже, і в атрибуті  “agrogr”, і в атрибуті “agrogr_с” буде фактично зберігатися кодова позначка агровиробничої групи ґрунтів що є фактично дублюванням даних в межах одного класу. Якщо розробниками передбачалося виведення окремих атрибутів лише для візуалізації кодової позначки грунту та їх назви, то доцільно для цього використовувати відповідні інструменти програмного забезпечення, або у другому атрибуті безпосередньо зберігати назву агровиробничої групи грунту (наприклад її можна записувати автоматично після вибору кодової позначки), але прибрати дублювання даних.

Аналогічне зауваження щодо класу “parcel” (Земельна ділянка), де дублюються при зберіганні даних значення в атрибутах “pur_code” (код цільового призначення) та “purpose” (цільове призначення).

Аналогічне зауваження щодо класу “function_zoning_pr” (Функціональне призначення територій проєктне), де дублюються при зберіганні даних значення в атрибутах “type” (функціональне призначення території) і “code” (кодова позначка зони),“pr_st“ (проєктний статус).

12. Відповідно до затвердженої структури Бази геоданих містобудівної документації на місцевому рівні в класі просторових об’єктів «hromada» (території територіальних громад) відсутній атрибут, який визначає межу як «проєктну». Виходячи з цього, встановлення меж територій територіальних громад повинно бути проведене до початку проведення робіт по розробленню  комплексного плану просторового розвитку території територіальної громади . Станом на сьогодні, межі територіальних громад не встановлені по всій території України.

Комплексний план передбачає всебічний аналіз, обґрунтування та обговорення з громадою перспектив використання їх територій, в тому числі й визначення меж громади, старостинств та населених пунктів. Для забезпечення виконання процедури обґрунтування встановлення межі громади, пропонуємо, за аналогом з генеральним планом населеного пункту, додати до  класу просторових об’єктів «hromada» атрибут «status» (статус межі), що значно прискорить виготовлення, узгодження та затвердження проєктів землеустрою щодо встановлення меж територій територіальних громад.

13. Для класу "env_monitoring_p" (Пункти моніторингу стану довкілля) обов'язковий атрибут "sign_in" (значення існуюче) із типом даних "Double". При виконанні стратегічної екологічної оцінки може виникати потреба у проєктуванні (наданні пропозицій щодо місць розміщення) пунктів моніторингу. Тому доцільно для класу "env_monitoring_p" зробити значення атрибута "sign_in"  не обов'язковим, а також забезпечити можливість вказання статусу такого пункту через додавання до класу "env_monitoring_p"  атрибуту “status”, який би визначався через перелік допустимих значень “status” (Статус). Окрім того, більшість сучасних пунктів моніторингу стану довкілля вимірює низку параметрів, а наразі в БГД передбачено внесення для одного пункту моніторингу лише значення по одному показнику. Необхідно забезпечити можливість внесення декількох показників та важливо зазначати дату фіксації відповідного показника. Пропонуємо, як мінімум додати атрибут “дата фіксації значення” (date_sign з типом даних Date).

Отже, пропонуємо наступне. Для забезпечення внесення відомостей про низку показників за різні періоди доцільно створити ще один клас об'єктів  “env_monitoring_p_value” (показники пункту моніторингу стану довкілля). Цей клас має містити наступні атрибути:
“mon_giud” (тип даних UUID)- - ідентифікат пункту моніторингу
“indicator”  (тип даних String)- назва індикатора

“unit”  (тип даних String)- одиниця вимірювання
“sign_in”  (тип даних double) - значення

“date_sign” (тип даних Date) - дата фіксації значення
“comp”  (тип даних SmallInteger) - компонент довкілля
Для класу "env_monitoring_p" (Пункти моніторингу стану довкілля) залишити такий набір атрибутів:
“task” (тип даних String) - завдання моніторингу, визначається через перелік допустимих значень “status”
“status” (тип даних SmallInteger) - статус, визначається через перелік допустимих значень “status”.

 

14. В розділі 5 "Таблиці" пропонується вводити нові додаткові атрибути через збереження їх в одній загальній окремій таблиці «UAХХХХХХХХХХХХХХХХХ_info». Зауважимо, що у визначеній для розширення класів атрибутами таблиці, не визначене ключове поле, яке буде кожний запис унікально ідентифікувати, оскільки передбачається ,що кожен клас може бути розширений жодним, одним і більше атрибутами. Якщо поле obj_guid - це код об'єкта до якого приєднуються атрибут, то воно не може виступати як ключове поле (унікальне значення в межах таблиці). Також в зазначену таблицю розширення атрибутів варто робити посилання на клас, наприклад, вказуючи назву класу, для полегшення зв'язування нового атрибути із класом, до якого він відноситься.

Отже, в таблиці “UAХХХХХХХХХХХХХХХХХ_info” потрібно визначити ключове поле, та додати поле (атрибут), в якому можна вказувати назву класу, до об'єкту якого вносяться додаткові атрибути.

15. Просимо звернути увагу на затверджені постановою Кабміну № 632 від 9 червня 2021 року формати передачі набору просторових даних та метаданих документації (Бази геоданих містобудівної документації на місцевому рівні), а саме File Geodatabase (GDB) або JavaScript Object Notation (GeoJSON), та розширити їх список додатковими форматами для обміну даними, які мають відкриті специфікації, що відповідає вимогам закону України “Про національну інфраструктуру геопросторових даних”, стандартам ISO, INSPIRE та матиме відкриту технічну специфікацію.

Формат File Geodatabase (GDB) не є відкритим обмінним форматом, то політика компанії власника щодо його використання, в тому числі надання API тощо в будь-який момент може бути змінена. Формати сімейства баз геоданих Esri GeoDB, в тому числі GDB (file geospatial database) – є власною реалізацією моделі даних, що використовується в лінійці продуктів Esri ArcGIS, яка включає ArcMap, ArcCatalog, ArcGlobe та ArcScene для настільних комп'ютерів, а також програмному забезпеченні ArcGIS для підприємств та мобільних пристроїв. Esri не надає загальнодоступних відкритих технічних специфікацій для опису формату файлової бази геоданих GDB, а лише загальний опис - https://desktop.arcgis.com/ru/arcmap/latest/manage-data/geodatabases/types-of-geodatabases.htm. Зауважимо, що наявні на сьогодні бібліотеки, зокрема API не дозволяють повноцінно працювати з форматом GDB в інших програмних продуктах, відмінних від програмних продуктів лінійки Esri. Зокрема, ПЗ FileGDB driver дозволяє читати та редагувати лише векторні дані формату GDB (https://gdal.org/drivers/vector/fileGDB.html). Також зазначене ПЗ не забезпечує доступ до повного функціоналу для створення баз геопросторових даних GDB у відкритих ГІС із повним використанням їх властивостей, конвертацію інших форматів даних у формат GDB (наприклад вивантажити/конвертувати SQL у GDB).

Формат geojson це відкритий стандарт обмінного формату геопросторових даних, розповсюджується на основі відкритого стандарту - https://www.rfc-editor.org/rfc/rfc7946. Геопросторові об'єкти у форматі GeoJSON можуть подаватися через геометрією (geometry), об'єкт (feature) чи колекцією об'єктів (feature collection). Об'єкт (feature) у GeoJSON складається з геометрії та додаткових властивостей, колекція об'єктів (feature collection) – з набору об'єктів (feature). За замовчуванням згідно стандарту (https://www.rfc-editor.org/rfc/rfc7946. ) для geojson використовується географічна система координат WGS84 у десяткових градусах довготи та широти, але будь-яка інша система координат може бути визначена в елементі "crs". Недоліком використання такого стандарту є те, що у разі експорту всіх шарів БГД в один файл формату geojson розділення на класи (шари в ГІС) у такому файлі не буде передбачено, оскільки стандарт файлу не містить відповідних елементів для «виокремлення класів (шарів в ГІС)». В такому випадку при передачі даних у форматі geojson потрібно їх передавати за принципом 1 клас (шар в ГІС) – це один файл. Можливо додатково прописувати у форматі geojson «користувацькі властивості», на основі яких будуть виділятися окремі класи (шари ГІС), але такі властивості повинні бути затверджені на рівні Постанови, бо вони не є загальноприйнятим стандартом і це потребуватиме розроблення додаткового функціоналу для роботи із таким обмінним файлом.

Опираючись на вищевикладене пропонуємо розширити перелік форматів обмінних файлів, такими що мають відкриті технічні специфікації, відповідають вимогам закону України “Про національну інфраструктуру геопросторових даних”, стандартам ISO, INSPIRE та матиме відкриту технічну специфікацію, зокрема SQL (https://www.iso.org/standard/63555.html) або geopackage (https://www.geopackage.org/spec/).

Додаток В. Щодо надання роз'яснень по використанню БГД.

1. В класі "parcel" (Земельна ділянка) визначено атрибут "pop_dens" (максимальна щільність населення в межах житлової забудови, осіб/га), який визначено як обов'язковий для заповнення (“required”). Просимо надати роз'яснення яким чином заповнювати поле "pop_dens" у випадку, коли земельна ділянка належить  до земель громадської забудови, промисловості, транспорту, зв'язку, енергетики, оборони та іншого призначення, сільськогосподарського, природно-заповідного та іншого природоохоронного, оздоровчого, рекреаційного, історико-культурного, лісогосподарського  призначення або земель водного фонду для яких параметр «максимальна щільність населення в межах житлової забудови, осіб/га» не визначається.

Вважаємо, що є доцільним атрибут "pop_dens" зробити не обов'язковим для заповнення, тобто “nullable”.

2. Потребує роз'яснення питання, яким чином в структуру БГД вносяться зміни, зокрема у випадках, коли в нормативні документи, законодавчі акти тощо будуть вноситися зміни та пропоновані в структурі переліки допустимих значень, класи та/або їх атрибути не будуть узгоджуватись зі змінами. Чи можливо та якщо так, то яким чином при розробленні містобудівної документації згідно з вимогами Постанови враховувати зміни у законодавстві, що зачіпають структуру БГД, Чи можуть виконавці МБД, які передають розроблену документацію у визначеній структурі вносити зміни або в іншому випадку чи буде передбачено в метаданих БГД атрибут (параметр), де буде фіксуватися версія структури БГД згідно з якою розроблено документацію.

Додатково зазначимо, що Структура БГД фактично є каталогом класів об'єктів згідно ДСТУ 8774:2018 Географічна інформація. Правила моделювання геопросторових даних (Наказ ДП «УкрНДНЦ» від 11.06.2018 р. No 158 «Про прийняття національних нормативних документів», чинний з 01.07.2019). Згідно вимог ДСТУ 8774:2018 каталог об‘єктів повинен бути доступним в електронній формі та мати таку інформацію (метадані про каталог), зокрема: найменування ‘name’, номер версії ‘versionNumber’ і дату версії ‘versionDate’, 'produce' (‘виробник’). Окрім того, виробники даних мають посилатися при використання відповідного каталогу даних (структури даних, в нашому випадку Структури БГД) на його версію тощо, при описі своїх специфікацій, метаданих тощо, згідно вимог Європейського Союзу, INSPIRE та положенням національного стандарту ДСТУ ISO 19131:2019 (ISO 19131:2007; Amd 1:2011, IDT) «Географічна інформація. Специфікація геоінформаційного продукту».

Також в процесі апробації структури БГД матимуть місце питання, виникатимуть пропозиції або виявлятимуться ймовірні помилки. Чи передбачена процедура за якої є можливість отримати відповідні роз'яснення та/або повідомити про виявлення таких помилок? Можливо доцільно створити відповідну робочу групу, яка буде адміністратором структури БГД, як мінімум на період її практичної апробації.

3. В класі “emerald_network” (Території Смарагдової мережі) атрибут “status” (статус) визначається через перелік допустимих значень “status” (Статус), що має такі значення: не визначено, існуюча, проектна, проектна на короткостроковий період, проектна на середньостроковий період, проектна на довгостроковий період. Основною передумовою для створення Смарагдової мережі є Конвенція про охорону дикої флори та фауни і природних середовищ існування в Європі (Бернська конвенція), але українське законодавство, яке б регулювало роботу Смарагдової мережі в Україні, наразі відсутнє, зокрема Проєкт Закону про території Смарагдової мережі: № 4461 від 04.12.2020 не затверджено.

Просимо надати роз'яснення щодо того в яких випадках та на підставі яких законодавчих актів можуть проєктуватися території Смарагдової мережі.

4. Згідно з ДБН Б.1.1.-14:2021 “Склад та зміст містобудівної документації на місцевому рівні”, який вступає в дію з 1.10.22 року таблиці 5.1. “Перелік графічних матеріалів комплексного плану” в складі містобудівної документації передбачається розроблення креслення «Схема розташування територіальної громади в системі розселення». Згідно п. 5.25.1  ДБН Б.1.1.-14:2021 схема розташування територіальної громади в системі розселення відображає розташування території територіальної громади  на території області або району. Згідно з Постановою від 17 липня 2020 року № 807-IX  Верховної Ради України Про утворення та ліквідацію районів - змінились межі та площі районів в областях адміністративно-територіальних одиницях Україні.  Після прийняття постанови нової містобудівної документації “Схеми планування території районів” та “ Схеми планування території області” з межами нових районів не розроблялось. Межі районів, які зображені на наявній містобудівній документації регіонального рівня не відповідають чинному адміністративно-територіальному устрою. Тому використання наявної містобудівної документації регіонального рівня для виконання «Схема розташування територіальної громади в системі розселення» не є цілком доцільним. Відповідно для розроблення «Схема розташування територіальної громади в системі розселення» необхідно показувати межі таких об'єктів як "Межа області" та "Межа району", щоб мати змогу коректно показати приналежності територіальної громади до відповідних адміністративно-територіальних одиниць в системі адміністративно-територіального устрою України та забезпечити комплексну оцінку території громади.

Також, згідно з адміністративно-територіальним  поділом України багато територіальних громад безпосередньо примикають до державного кордону України. Вздовж державного кордону України встановлюється прикордонна смуга, у межах якої діє особливий режим використання земель (відповідно до статті 115 Земельного кодексу України). Також правовий режим прикордонної смуги визначається статтями 18, 22-24 Закону України «Про державний кордон України», а також постановою Кабінету Міністрів України від 27.07.1998 № 1147 «Про прикордонний режим». Територія даних прикордонних смуг встановлюється безпосередньо від лінії Державного кордону.  Дана територія  потраплятиме у межі прилеглих до кордону територіальних громад та матиме певні обмеження у використанні, вважаємо за потрібне показувати на містобудівній документації місцевого рівня (зокрема комплексного плану території) межу Державного кордону України, для того, щоб встановити усі планувальні обмеження у використанні даної території та забезпечити якісне  виконання містобудівної документації.

Зважаючи на вищевикладене пропонуємо додати до БГД просторові класи: "border" (Державний кордон України), "region" (Межа області, АР Крим), "district" (Межа району) для відображення та збереження даних щодо державного кордону, межі області та  межі району або надати роз’яснення яким чином забезпечити вимоги  ДБН Б.1.1.-14:2021, оскільки в БГД відсутні класи, які б передбачали збереження даних щодо державного кордону, межі області та  межі району.

5. Стаття 19 Закону України «Про регулювання містобудівної діяльності» детальний план території деталізує положення генерального плану населеного пункту або комплексного плану та визначає планувальну організацію і розвиток частини території населеного пункту або території за його межами без зміни функціонального призначення цієї території. Саме Детальний план території визначає планувальну організацію та розвиток території (щодо якої проводиться проєктування). Враховуючи особливості та рівень деталізації рішень детальних планів території просимо надати відповідні рекомендації щодо застосування класів просторових об'єктів та їх атрибутів для виконання детальних планів територій.

Так, наприклад, для класу «Transport_networks» встановлено тип геометрії “Polyline” (лінія), що унеможливлює виконання вимог ДБН Б.2.2-12:2019, щодо організації проїздів пожежних машин та ДБН В.2.3-5:2018, ДБН В.2.2-40:2018 "Інклюзивність будівель і споруд" щодо забезпечення інклюзивності та інших планувальних рішень, які конкретизуються саме в детальному плані. В тому числі в цілому для забезпечення розроблення детальних планів територій, основою для яких є топооснова масштабу 1: 500, в структурі БГД відсутня можливість детального обґрунтування планувальних площинних елементів набору класу об’єктів «Transport_networks»: «roads» (автомобільні дороги), «streets» (вулиці та дороги населених пунктів), «spec_roads» (спеціалізовані дороги та проїзди), «forest_roads» (польові та лісові дороги), «trails» (мережа доріжок), «railways_main» (залізниці магістральні), «railways_local» (залізниці місцеві), «trolleybus_lines» (тролейбусні лінії).

6. Відповідно до статті 15 та статті 14 та статті 19 ЗУ "Про регулювання містобудівної діяльності" у разі наявності в комплексному плані/генеральному плані населеного пункту/детальному плані території інформації, яка відповідно до закону становить державну таємницю або належить до інформації з обмеженим доступом, така інформація подається у вигляді окремого файлу, формат якого визначається Кабінетом Міністрів України, та підписується кваліфікованими електронними підписами відповідальними особами, які розробили відповідну містобудівну документацію. В розрізі зазначеного просимо надати роз'яснення щодо використання БГД та передачі класів БГД у випадку наявності в ній даних ДСК в класах, що входять до набору класів об'єктів “Civil_protection”. Також згідно з п. 5 Наказу 15.08.2018  № 220 Міністерство регіонального розвитку,будівництва та житлово-комунального господарства України  “Про затвердження Вимог до структури і формату оприлюднення відомостей про містобудівну документацію у мережі Інтернет” графічні матеріали містобудівної документації про проєктування та будівництво будівель і споруд цивільного захисту та про джерела водопостачання, що містить інформацію з обмеженим доступом, не оприлюднюються у мережі Інтернет.  просимо надати роз'яснення щодо передачі БГД із такими даними.
7. Межі (території) адміністративно-територіальних одиниць можуть подаватися через декілька окремих полігонів, тобто як мультиполігон. Зокрема це об'єкти таких класів як "hromada" (Території територіальних громад), "settlement" (Населені пункти). Оскільки в БГД для цих класів тип геометрії визначено як проста геометрія "Polygon" просимо надати роз'яснення щодо того, як коректно вносити геометрію таких об'єктів до БГД. Доцільно явно вказати можливість збереження даних в перелічених шарах у вигляді мультиполігонів (multipolygon), оскільки деякі ГІС та для деяких форматів даних при роботі ці два типи геометрії polygon та multipolygon явно розділяються і для можливості їх використання потрібно точно вказувати тип геометрії. Також, це дозволить запобігти ситуаціям, коли межа адміністративної одиниці, яка складається з декількох полігонів буде подана користувачами як окремі записи в класі (таблиці) БГД. Додатково зауважимо, що в ДЗК при формуванні меж населених пунктів, територіальних зон у форматі XML, при таких ситуаціях,  застосовується геометрія "мультиполігонів" для передачі цілісності  об'єктів.

Якщо використання мультиполігонів (multipolygon) для згаданих класів не передбачається просимо надати роз'яснення щодо внесення даних про об'єкти, геометрія яких складається із декількох полігонів.

8. В розділі 4 “Правила топології” визначено правило згідно з яким об'єкти класу “settlement” мають суміщатися з об'єктами класу “hromada”. Просимо надати роз'яснення щодо змісту та практичного застосування цього правила топології, адже межі населених пунктів не завжди можуть/повинні накладатися (суміщатися) із межею громади, меж населених пунктів можуть покривати межею громади, бути в середині межі громади, не повинні виходити за межі громади тощо.
9. Просимо надати роз'яснення щодо логіки використання відношень між класами просторових об'єктів, описаних в розділі 3 “Класи відношень”, де зокрема виділено: 188 відношень з кардинальністю “один до одного”, 2 відношення з кардинальністю “один до багатьох”, 436 відношень з кардинальністю “багато до багатьох”.

Структурою БГД для відношень вводиться окремий клас-посередник (клас відношення) через який має утворюватися зв’язок між класами учасниками такого відношення, тобто між класом-джерелом та класом-адресатом. З іншої сторони, структурою БГД для відношень з кардинальністю “один до одного” та “один до багатьох” окрім класів відношення вводиться в одних випадках у класі-адресаті, а в інших у класі-джерелі додатковий атрибут для встановлення зв'язків між класами. Введення  додаткового атрибуту, і класу-посередника для встановлення зв'язків з кардинальністю “один до одного” та “один до багатьох” є суперечливим, оскільки достатнім є використання чогось одного.

Нижче на типових прикладах відношень із розділу 3 “Класи відношень” сформулювали основні питання, що виникають.

Щодо відношень типу “один до одного”.

На рисунку а.1 наведено приклад схеми для класів відношення “cemeteries_szz” і “crematoria_szz”. В цьому випадку для класів-адресатів структурою БГД вводиться додатковий атрибут.  (Аналогічно пропонується будувати зв'язки між класами для ще 84 відношень).

Аналізуючи на прикладі типового відношення “cemeteries_szz” виникає ряд питань:

• якщо для зв'язку використовується окремий клас, з якою метою для забезпечення такого відношення вводиться окремо атрибут “ro_guid” (код режимоутворючого об'єкту)?
• виходячи із псевдоніму атрибута “ro_guid” - код режимоутворючого об'єкту - то атрибут “ro_guid” має містити значення “GUID” із класу “cemeteries”, в такому випадку виникає питання який сенс в класі відношення  “cemeteries_szz” зберігати два атрибути з однаковим семантичним значенням, а саме “GUID” із класу “cemeteries” та “ro_guid”  із класу “sanit_protect_zones” ? Чому через клас відношення не встановлюється зв'язок із класом “sanit_protect_zones” через атрибут “GUID”?
• Зауважимо, що якщо в класі відношення фігурують два атрибути “ro_guid” (код режимоутворючого об'єкту) та “GUID” (Globally Unique Identifier кладовища, тобто режимоутворюючого обєкту) - виходить, що це є один і той самий ідентифікатор, тобто ідентифікатор кладовища, для якого встановлюється зв'язок із санітарно-захисною зоною і в цьому випадку сенс створення окремого відношення губиться.
• З іншої сторони, для прикладу класу відношення “cemeteries_szz” може бути забезпечений зв'язок без введення класу-посередника (класу відношення) через прямий зв'язок. Схема такого зв'язку наведена на рисунку а.2. В такому випадку значення  “GUID”  із класу “cemeteries” буде записуватися в атрибут “ro_guid” класу “sanit_protect_zones” і таким чином ці класи (зв'язані об'єкти в межах цих класів) будуть зв'язуватися. Зауважимо, що в розділі 3 “Класи відношень”  пропонується реалізувати 84 відношення, які можуть бути спрощені за наведеною схемою.

На рисунку б.1 наведено приклад схеми для класів відношення “np_in_cfa_cat_fl_ar” і “np_in_cat_flood_ar_settl”, на рисунку б.2 наведено приклад схеми для класів відношення “cat_fl_ar_str_hydro_pg”, “cat_fl_ar_str_hydro_l”, “cat_fl_ar_str_hydro_p”. В цьому випадку для класів-джерел структурою БГД вводиться додатковий атрибут.  (Аналогічно пропонується будувати зв'язки між класами для ще 104 відношень).

Аналізуючи на прикладі типового відношення “np_in_cfa_cat_fl_ar” виникає ряд питань:

• якщо для зв'язку використовується окремий клас, з якою метою для забезпечення такого відношення вводиться окремо атрибут “ar_guid”(код зони можливого катастрофічного затоплення у разі руйнування гребель)?
• виходячи із псевдоніму атрибута “ar_guid”(код зони можливого катастрофічного затоплення у разі руйнування гребель) має містити значення “GUID” із класу “catastrophic_flood_areas”, в такому випадку виникає питання який сенс в класі відношення “np_in_cfa_cat_fl_ar” зберігати два атрибути з однаковим семантичним значенням, а саме “GUID” із класу “catastrophic_flood_areas” і “ar_guid” із класу “np_in_catastr_flood_areas”? Чому через клас відношення не встановлюється зв'язок із класом “np_in_catastr_flood_areas” через атрибут “GUID”?
• Зауважимо, що якщо в класі відношення фігурують два атрибути “ar_guid”(код зони можливого катастрофічного затоплення у разі руйнування гребель) та “GUID” (Globally Unique Identifier зони можливого катастрофічного затоплення у разі руйнування гребель) - виходить, що це є один і той самий ідентифікатор, тобто ідентифікатор зони можливого катастрофічного затоплення у разі руйнування гребель, для якого встановлюється зв'язок із населеними пунктами і в цьому випадку сенс створення окремого відношення губиться.
• З іншої сторони, для прикладу класу відношення  “np_in_cfa_cat_fl_ar” може бути забезпечений зв'язок без введення класу-посередника (класу відношення) через прямий зв'язок, як це було наведено в прикладі на рис. а.1. Але при цьому клас-джерело - не може виступати батьківським класом, бо цей клас підпорядковується і прив’язуватиметься до класів “catastrophic_flood_areas”.

 

Щодо відношень типу “один до багатьох”

На рисунку в.1 наведено приклад схеми для класів відношення “settl_city_district” і “parcel_sublease”. Відношень із кардинальністю “один до багатьох”, як вже зазначалося в БГД передбачено лише два. В цьому випадку для класів-адресатів структурою БГД вводиться додатковий атрибут.  (Аналогічно пропонується будувати зв'язки між класами для ще 84 відношень).

Аналізуючи ці два відношення виникає ряд питань:

• виходячи із псевдоніму атрибутf “set_guid”(код міста) класу “city_district” (Райони у містах) має містити значення “GUID” із класу “settlement”, в такому випадку виникає питання який сенс в класі відношення “settl_city_district” зберігати два атрибути з однаковим семантичним значенням, а саме “GUID” із класу “settlement” і “set_guid” із класу “city_district”? Чому через клас відношення не встановлюється зв'язок із класом “city_district” через атрибут “GUID”?
• Зауважимо, що якщо в класі відношення фігурують два атрибути “set_guid”(код міста) та “GUID” (Globally Unique Identifier міста) - виходить, що це є один і той самий ідентифікатор, тобто ідентифікатор населеного пункту і в цьому випадку сенс створення окремого відношення губиться.
• Також зазначимо, що для відношень між класами “city_district” та “settlement”, “parcel” та “sublease”  .

 

 

Отже, просимо аргументувати мету та доцільність введення такої кількості відношень в БГД, оскільки збільшення кількості зв'язків ускладнюватиме роботу із БГД. Просимо навести роз'яснення щодо логіки побудови та практичного застосування класів відношень в БГД.

 

 

 

 

Щоб підписати лист - заповність форму https://docs.google.com/forms/d/e/1FAIpQLSc8zl5b2ns33LVkYnWFjrXiHmLINyO7c2GoPYo6PoA2wqsGPA/viewform