Сторінка
9
БД повинна відповідати звичайним вимогам: містити мінімум дублювання, протиріч і двозначності, мати достатню повноту й актуальністю, мати розумну фрагментацію і високий ступінь інтеграції спеціалізованих БД. Це вимагає існування групи ведення БД, що включає в себе адміністратора БД. Саме ця група повинна робити необхідні вибірки з централізованої БД.
Для підтримки задач зонування, у тому числі моніторингу міська реляційна БД повинна містити наступні полючи:
- параметри об'єкта: тип об'єкта, тип власності на об'єкт, тип використання об'єкта, реєстрація угод з об'єктом, для земельної ділянки покоординатний опис границь (електронний кадастр), для будинку це число поверхів, висота, загальна площа, площа забудови, капітальність, амортизація, інженерне забезпечення, архітектурна й історична цінність. Даний список параметрів повинний уточнюватися і розширюватися.
- для повноцінної роботи з земельними ділянками необхідна служба електронного кадастру, у противному випадку можна обмежитися площею і координатами центроїда ділянки.
- для відстеження процесів до об'єкта повинна бути прив'язана інформація про дати: реєстрація угод з об'єктом, реєстрація заявок зв'язаних з об'єктом, зміни в правах власності, дати дозволу на будівництво, будівлі, капітального ремонта, додання того чи іншого статусу. У більшості випадків для задач зонування міської території має сенс тільки поточний стан об'єкта, але в деяких випадках може знадобитися одна дата (наприклад виділення всіх об'єктів приватизованих у плині року) або ланцюжок дат (наприклад виділення об'єктів часто переходили з рук у руки). Така інформація про дати і права власності як правило зберігається окремо і може бути зв'язана з об'єктом через ідентифікатор.
У загальному випадку прив'язка реляційної БД до електронної карти може здійснюватися різним способом. Можна прив'язуватися до міської системи координат. У цьому випадку кожному об'єкту в БД повинна бути зіставлена пара чисел - координати в міській системі координат, а електронна карта повинна бути надточної, тому що координати об'єкта, навіть котеджу, повинні відповідати якійсь точці на електронній карті усередині даного об'єкта. Така прив'язка швидка в роботі, однозначна, точна. На жаль така система завжди є засекреченої і вимагає додаткової роботи з БД. Інший спосіб це прив'язка об'єкта в реляційної БД до земельної ділянки по кадастровому номері. У цьому випадку в місті повинний бути комп'ютерний кадастр і прив'язка інформації з БД відбувається до центроїду відповідного ділянки. Міський кадастр як ціле також є секретним, крім цього в наших умовах ділянки можуть бути дуже великими (заводи, мікрорайони) і кадастр у цілому рідко буває приведений у порядок хоча б у традиційному виді - на папері. Найбільш прийнятний спосіб прив'язки для рішення задач зонування, у тому числі моніторингу, традиційна прив'язка по поштовій адресі. Поштова адреса зазначена для будь-якого об'єкта нерухомості занесеного в БД для можливості зв'язку з власниками. З іншої сторони для прив'язці до карти досить побудувати просту адресну або структуру заповнити адресну інформацію для будинків. Адресна структура може мати різний вид. Тому що така структура носить тимчасовий характер (до ідентифікації адрес усіх будинків), головним - це простота створення і зміни при задоволенні всім необхідним вимогам. Представляється розумної структура представлена крапковими об'єктами на карті, що позначають сторони кварталу, знаходяться усередині кварталу і представлені рядком у таблиці з указівкою вулиці й ідентифікатора типу (площа, проїзд, набережна й ін.), діапазону номерів будинків і ідентифікатором спеціальної непарно-непарної нумерації (поле "type"). Квартал у даній системі може бути розбитий на частині по границях зон. Вулиці повинні бути зазначені в стандартизованому виді, тобто кожна вулиця має тільки одне написання імені, ідентифікатор стоїть в окремому полі, або в стандартному місці (попереду або позаду) назви вулиці, має стандартний вид і не допускає різночитань. Написання ідентифікатора можна скорочувати.
Такий підхід був застосований у Новгороді. Розглянемо цей приклад докладніше, із указівкою службових таблиць, програм мовою MapBasic і способів відображення результатів. В адресній структурі (таблиці) 1045 елементів, її створення зайняло біля тижня. Основним джерелом служила карта масштабу 1:20.000 із указівкою границь кварталів і номерів кутових будинків. Карта була застарілої і деякого номера були відсутні, тому приходилося уточнювати схему у відділі головного архітектора міста. Крім адресної схеми в сучасних російських умовах необхідна таблиця перейменування назв вулиць. Така таблиця містить всього два полючи: стару назву і нова назва. Відзначимо, що нова назва може повторюватися, а старе - немає. Повторення відбувається у випадку двохкратного перейменування й у випадку поділу вулиці з перейменуванням. Така службова таблиця, як і сама адресна схема, робиться і змінюється в Mapinfo. У тому випадку якщо використовується тільки централізована БД, полючи якої містить добре перевірену й актуальну інформацію, їсти зміст вносити відповідні назви вулиць у таблицю адресної схеми і не проводити перейменування. Але як правило варто розраховувати на існування декількох БД, де імена вулиць можуть обновлятися, а можуть і не обновлятися. В адресній схемі, природно, ім'я кожної вулиці повинне бути тільки в одному варіанті.
В даний час система містить чотири службових програми, що запускаються і працюють у середовищі Mapinfo. У залежності від способу представлення вибірки з БД і структури адресної схеми з може бути більше або менше. Одна з них обробляє таблицю адресної схеми і запускається тільки один раз після створення чи схеми після її доповнення новими записами. Ця програма проставляє в графу "type" тип сторони вулиці - "пара" або "непара".
Ще дві програми обробляють таблицю вибірки з БД; одна видаляє знак простих лапок і запускається першої і тільки в разі потреби, інша приводить до стандартного виду назви вулиць у таблиці вибірки і перейменовує їх при необхідності, що робиться за допомогою таблиці перейменовування назв вулиць. Ці дві програми запускаються для кожної вибірки з БД. Програма спеціального геокодування працює довше інших. Вона обробляє таблицю вибірки приєднуючи до неї графічні крапкові об'єкти які володіють тими ж властивостями, що і крапкові об'єкти адресної схеми. Крім цього вона додає до цієї таблиці стовпець с' ім'ям "geocode_mistake_type" і заносить у нього коди результату геокодування. Програма обробляє також таблицю адресної схеми заносячи в додатковий стовпець "objects" кількість об'єктів з таблиці вибірки, що розміщені по даній адресі.
У ГІС Mapinfo існує стандартна програма геокодування. Але вона призначена для даних описаних у визначеному, не цілком зручному, стандарті. Таке геокодування не завжди проходить автоматично, і приходиться його доповнювати "ручним" геокодуванням. Засобу убудованого в ГІС мови MapBasic дозволяють побудувати більш ефективну, з урахуванням конкретної задачі і структури даних, програму геокодування.
Завантажити реферат