Задачі і методи аналізу забруднень в ГІС

Що із себе представляє типова міська база даних? Це реляційна база даних, вхідною інформацією для який служать спеціальні бланки заповнювані при реєстрації угод, актів про вступ у права власності, реєстрації заявок на оренду і т.п. Така база даних представляє із себе зв'язані таблиці утримуючі вищезгадані зведення; причому дані повинні бути розумно стиснуті, доступні для контролю коректності і знаходитися під керуванням сучасної СУБД.

БД повинна відповідати звичайним вимогам: містити мінімум дублювання, протиріч і двозначності, мати достатню повноту й актуальністю, мати розумну фрагментацію і високий ступінь інтеграції спеціалізованих БД. Це вимагає існування групи ведення БД, що включає в себе адміністратора БД. Саме ця група повинна робити необхідні вибірки з централізованої БД.

Для підтримки задач зонування, у тому числі моніторингу міська реляційна БД повинна містити наступні полючи:

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

для повноцінної роботи з земельними ділянками необхідна служба електронного кадастру, у противному випадку можна обмежитися площею і координатами центроїда ділянки.

для відстеження процесів до об'єкта повинна бути прив'язана інформація про дати: реєстрація угод з об'єктом, реєстрація заявок зв'язаних з об'єктом, зміни в правах власності, дати дозволу на будівництво, будівлі, капітального ремонта, додання того чи іншого статусу. У більшості випадків для задач зонування міської території має сенс тільки поточний стан об'єкта, але в деяких випадках може знадобитися одна дата (наприклад виділення всіх об'єктів приватизованих у плині року) або ланцюжок дат (наприклад виділення об'єктів часто переходили з рук у руки). Така інформація про дати і права власності як правило зберігається окремо і може бути зв'язана з об'єктом через ідентифікатор.

У загальному випадку прив'язка реляційної БД до електронної карти може здійснюватися різним способом. Можна прив'язуватися до міської системи координат. У цьому випадку кожному об'єкту в БД повинна бути зіставлена пара чисел - координати в міській системі координат, а електронна карта повинна бути надточної, тому що координати об'єкта, навіть котеджу, повинні відповідати якійсь точці на електронній карті усередині даного об'єкта. Така прив'язка швидка в роботі, однозначна, точна. На жаль така система завжди є засекреченої і вимагає додаткової роботи з БД. Інший спосіб це прив'язка об'єкта в реляційної БД до земельної ділянки по кадастровому номері. У цьому випадку в місті повинний бути комп'ютерний кадастр і прив'язка інформації з БД відбувається до центроїду відповідного ділянки. Міський кадастр як ціле також є секретним, крім цього в наших умовах ділянки можуть бути дуже великими (заводи, мікрорайони) і кадастр у цілому рідко буває приведений у порядок хоча б у традиційному виді - на папері. Найбільш прийнятний спосіб прив'язки для рішення задач зонування, у тому числі моніторингу, традиційна прив'язка по поштовій адресі. Поштова адреса зазначена для будь-якого об'єкта нерухомості занесеного в БД для можливості зв'язку з власниками. З іншої сторони для прив'язці до карти досить побудувати просту адресну або структуру заповнити адресну інформацію для будинків. Адресна структура може мати різний вид. Тому що така структура носить тимчасовий характер (до ідентифікації адрес усіх будинків), головним - це простота створення і зміни при задоволенні всім необхідним вимогам. Представляється розумної структура представлена крапковими об'єктами на карті, що позначають сторони кварталу, знаходяться усередині кварталу і представлені рядком у таблиці з указівкою вулиці й ідентифікатора типу (площа, проїзд, набережна й ін.), діапазону номерів будинків і ідентифікатором спеціальної непарно-непарної нумерації (поле "type"). Квартал у даній системі може бути розбитий на частині по границях зон. Вулиці повинні бути зазначені в стандартизованому виді, тобто кожна вулиця має тільки одне написання імені, ідентифікатор стоїть в окремому полі, або в стандартному місці (попереду або позаду) назви вулиці, має стандартний вид і не допускає різночитань. Написання ідентифікатора можна скорочувати.

Інші цікаві матеріали

Економіко-географічна характеристика Республіки Індонезії
Назва "Індонезія" є складовим і походить від топоніма "Індія" (лат. Indus) В поєднанні з похідним від грецького слова "несос" (греч. нῆупт - острів), Буквально "Острівна Індія&q ...

Транспорт і зв'язок
Головною ціллю в транспортної галузі є більш повне, безпечне, якісне задоволення потреб населення та економіки району у послугах транспорту, поліпшення транспортно-експлуатаційного стану автомобільних доріг і мостів, планомірни ...

Регіональний розвиток центрально-українського економічного району
Проблеми регіонального розвитку центрально-українського економічного району – це проблеми невикористаних можливостей, нереалізованого потенціалу. Зменшення чисельності працездатного населення, депопуляція - свідчать про ...