Перевірка даних OSM

Редакція 2017-04-24

• Перевірка даних OSM
  • Щоденні перевірки
    • Перевірка даних
    • Використання пошуку в JOSM
  • Повторне осбтеження
    • Виправлення помилок
    • Звітування про точність
  • SQL запити
    • Підготовка даних
    • Робота із запитами SQL
  • Підсумки

Цей розділ охоплює процеси перевірки якості даних, особливо в контексті керованого проєкту мапінгу в OSM, наприклад, тих, що здійснюються Humanitarian OpenStreetMap Team у різних країнах та проєктами Open Cities у Бангладеш, Шрі-Ланці та Непалі. Продемонстровані методи можуть бути корисними і в інших контекстах, коли перевірка якості даних є регулярним завданням.

Коли ми намагаємось мапити всі об’єкти та їх властивості на визначеній території, нам потрібно переконатись у відсутності помилок та мати методики для оцінки якості роботи. У цім посібнику ми розглянемо кілька методів перевірки даних, пояснивши кроки кожного етапу та причину, що стоїть за кожним з них.

• Щоденні перевірки
• Повторне осбтеження
• SQL запити

Ці методи перевірки набувають все більшого значення, оскільки модель даних зростає, а кількість зібраних об’єктів стає досить великою. Наприклад, не знадобиться багато часу та зусиль для оцінки моделі даних, яка включає лише точкових об’єктів (POI):

В цьому випадку питаннями на які треба відповісти будуть:

• Чи були замаплені всі POI?
• Чи є POI без назви?
• Чи є POI тип яких не зазначений?
• Чи є POI у яких не зазначено номер телефону?
• Чи назва в полі name написана з великої літери?
• Чи має значення номеру телефону хоча б якийсь сенс?

Однак, як правило, модель даних набагато складніша, як і у випадку з мапінгом будівель. Розглянемо модель даних, яка включає в себе:

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

Щоденні перевірки

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

Розглянемо кілька методів перевірки даних з використанням JOSM. Ось деякі питання на які ми маємо знайти відповідь щодо даних:

• Чи у нас є помилки топології (коли контури будинків перетинають друг друга або у нас помилкові зв’язки [relations])?
• Чи є у нас помилки в теґах (помилкові значення, друкарські помилки, невідповідні пари ключ=значення)?
• Чи є наші дані повними згідно з нашою моделлю даних?

Спробуймо відповісти на ці питання користуючись JOSM. Вважатимемо, що ми перевіряємо роботу інших, але ті ж принципи добре працюють (і є можливо простішими), коли ми перевіряємо власну роботу.

Будемо використовувати тренувальні дані з проєкту Open Cities для міста Дака (Dhaka). Завантажте собі для подальшої роботи файл: dhaka_validation_example.osm

НЕ НАМАГАЙТЕСЬ завантажити ваші зміни до OpenStreetMap. Ці дані лише для демонстрації процесу перевірки.

Перевірка даних

Першим кроком перевірки буде використання вбудованих в JOSM інструментів перевірки даних, які дозволяють в автоматичному режимі знаходити потенційні помилки. Ці інструменти особливо корисні для пошуку помилок топології, але можуть не спрацювати для пошуку помилок в теґах.

• Активуйте вікно Результати перевірки натиснувши на кнопку на панелі інструментів ліворуч. (Це необов’язково робити якщо у вас вже відкрите це вікно)

• Далі, переконайтесь що у вас не виділено жодного об’єкта на мапі, можна просто клацнути в порожнє місце на мапі для скидання виділення. Якщо у вас виділено якісь об’єкти під час запуску Перевірки, всі перевірки будуть здійснені тільки дня них. (Іноді у вас може виникнути потреба перевірити лише деякі об’єкти, але зараз ми хочемо перевірити весь файл).
• Натисніть кнопку “Перевірка” (“Validation”) у вікні.

• Після виконання перевірок ви побачите перелік попереджень:

• Також у вікні шарів ви побачите появу нового шару, який показує помилки на мапі. Зараз його можна приховати.

Переглянемо кілька попереджень. Ви можете побачити що у нас чотири випадки перетину контурів будинків попередження “Crossing buildings”. Це означає, що десь контури будинків перекривають друг друга. Виділіть перший елемент в списку, клацніть правою кнопкою миші та оберіть “Zoom to problem”.

Натисніть кнопку “Вибрати” (“Select”) у вікні Валідатора, щоб підсвітити підозрілі об’єкти. Ми побачимо що проблема з цими двома контурами:

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

Цей метод автоматичної перевірки даних є ефективним способом виправлення помилок топології, особливо тих, які важко помітити людині. В переліку попереджень можна також побачити інші повідомлення, наприклад “Будівля в середині будівлі” (“Building inside building”), що є результатом подібної помилки.

Ще інші попередження, такі як “Перетин доріг/водних шляхів” (“Crossing waterway/highway”) – не завжди є помилками. Це свідчить, що інструменти перевірки добре працюють для пошуку потенційних помилок, але для вирішення того чи є ці помилки критичними потрібен певний досвід.

Розглянемо попередження “Лінії зі схожими назвами” (“Similarly named ways”) – це вже не пов’язано з топологічними помилками. Натисніть “Вибрати” (“Select”) для виділення двох ліній, щодо яких є сумніви.

Чи ви можете сказати в чому помилка? Тут у нас два відрізки дороги, які насправді є частинами однієї дороги, але мають невелику відмінність в назві – слово “road” в одного з відрізків написане з великої літери, а в іншого з маленької. Зрозуміло що вони мають називатись однаково, в цьому випадку треба писати “road” з великої літери для обох відрізків.

Використання пошуку в JOSM

Пошук у JOSM – це потужний спосіб перегляду даних. Він дозволяє вам використовувати пошукові запити, щоб вибрати лише потрібні вам об’єкти.

• Щоб відкрити вікно пошуку, в меню Правити знайдіть пункт Пошук… або натисніть CTRL + F.

• До ваших послуг велика кількість типів пошукових запитів, приклади та певна інформація знаходяться безпосередня у вікні пошуку, або ж ви завжди можете скористатись “Довідкою”.

• Спробуємо зараз знайти всі будівлі. Кожна з них має бути позначена теґом building=yes, а деякі – building=construction. Ми можемо скласти запит який виглядає так:

  building = yes OR building=construction

• З його допомогою ми вибілимо всі будівлі, але на всяк випадок, якщо хтось застосував неправильний теґ, ми скористаємось запитом, який покаже нам всі будівлі що мають ключ building.

• В результаті всі будівлі будуть виділені.

Чудово, яле як це може нам допомогти в перевірці даних? Що ж, тепер коли ми маємо виділеним однотипні дані, ми можемо перевірити їх на правильність заповнення

• Погляньте на вікно властивостей, у нас є теґи всіх виділених об’єктів. У них є однакові ключі, але через те що кожен об’єкт має своє власне значення, всі значення відмічені як <different>.

• Оберіть ключ building:use та натисніть “Правити” (“Edit”).

• ОБЕРЕЖНО! Нам не треба зараз нічого змінювати та натискати “Так”, тому що зміни будуть застосовані до всіх виділених об’єктів. Це було б дуже погано.
• Натомість, розкрийте випадаюче меню поля Значення (Value).

• Зверніть увагу, що всі елементи, виділені жирним шрифтом, мають цифри поруч із собою. Це кількість виділених об’єктів, які мають це значення теґу.

Ми можемо порівняти їх з теґами OpenStreetMap, які були використані в нашій моделі даних, та шукати помилки. Наприклад, цим теґом позначається для яких цілей використовується будівля. Раніше в проєкті Open Cities Dhaka, звідки ми взяли ці дані, не було узгоджено яким чином позначати будинки які мають багатоцільове призначення: building:use=multipurpose чи building:use=mixed. Оскільки перший теґ вже використовувався в інших країнах, було вирішено дотримуватись такої практики. Однак, ми бачимо, що один із будинків позначено як mixed. Нам треба це виправити. (Інший наочна помилка – три різних варіанти для гаражів [garage], але ми не будемо робити виправлення прямо зараз).

• Ми не можемо змінити об’єкт з теґом building:use=mixed тут, бо у нас виділено кілька сотень інших будівель. Тож для виправлення помилки нам потрібно знайти об’єкт що її містить. Як? Правильно – за допомогою Пошуку.
• Натисніть “Скасувати” (“Cancel”) щоб закрити це вікно. Пам’ятаєте, натискання Так – небезпечне.
• Викрийте вікно Пошуку та введіть наступний пошуковий запит: “building:use”=mixed
• Бачите, ми взяли ключ з двокрапкою (:) в лапки. Двокрапка також може бути елементом синтаксису пошукових запитів. Виконання цього запиту дозволить виділити нам один будинок, що має ключ з зазначеним значенням. Тепер ми можемо виправити значення на multipurpose.

Пам’ятайте, якщо ви намагаєтесь повторювати всі дії з цих настанов, НЕ НАМАГАЙТЕСЬ завантажити ваші зміни до OpenStreetMap. Ці вправи надано лише для демонстрації можливостей.

Повторне осбтеження

При керуванні таким проєктом, як додавання будівель, повинен бути додатковий метод контролю якості, як для поліпшення роботи, так і для звітування про точність в кінці проєкту.

Якщо в проєкті беруть участь кілька команд маперів, ймовірно що не всі вони працюють з однаковим рівнем якості. Навіть найкраща команда може припускатись помилок. Уявіть що кожна команда додає на мапу по 100 будинків кожного дня і досить можливо, що невеликий відсоток атрибутів, які вони внесли, можуть бути не точними.

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

Звісно, немає потреби в повторному досліджені всіх будинків на території проєкту, але 5-10% мають бути перевірені. Місця для перевірки треба обирати випадково, але так щоб можна було порівняти роботу різних команд. Команди можуть перевірити роботу друг друга, а за можливості це можна доручити найбільш досвідченим маперам. Поширеною практикою є витрачання менеджерами одного з днів тижня на часткову перевірку території проєкту.

Виправлення помилок

Що треба робити під час виявлення помилок?

Якщо відсоток помилок є порівняно не великим (не більше 5% всіх будівель), про проблему треба сповістити команду що виконувала завдання, щоб вони самотужки виправили помилки та не робили їх в майбутньому. Виправлення мають бути збережені в OpenStreetMap, а результати перевірки записані.

Якщо виявлено вищий рівень помилок, мають бути застосовані більш рішучі заходи. Про це треба відповідним чином повідомити виконавців, а територію, можливо, доведеться перевірити повністю, в залежності від критичності виявлених помилок. Відсоток помилок вищий за 10% скоріш за все є не прийнятним.

Звітування про точність

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

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

Наприклад, уявимо, що ми керуємо проєктом, який має на меті замапити 1000 будівель. Тож ми вирішуємо додати 10%, або 100 будівель, випадковим чином вибраних із цільової області. Ми починаємо і виявляємо, що зі 100 будинків, які ми перевірили, шість мають високий рівень помилок. Скажімо, ми визначаємо що це помилка, якщо більше ніж один атрибут вказаний невірно.

Повторна перевірка має проводитись під час всього перебігу проєкту. Уявімо, що ми чекаємо закінчення проєкту і після перевірки виявляємо, що 40 зі 100 будинків додані з помилками! Це може означати невдачу всього проєкту. Краще виловити грубі помилки якнайшвидше, щоб надалі їх не припускатись.

SQL запити

Мабуть, найкращим інструментом аналізу буде виконання SQL запитів в системі GIS, наприклад, Quantum GIS. Це схоже на пошук даних в JOSM, але QGIS пропонує більш потужні інструменти для аналізу, хоча налаштування може зайняти трохи більше часу. Використання JOSM – це швидкий, звичайний спосіб перевірити дані на основні помилки, тоді як запит у QGIS краще підходить для пошуку відсутніх даних або неправильних атрибутів.

Тут ми припустимо, що ви дещо знайомі з GIS, і зосередимось на побудові запитів, які можуть допомогти вам перевірити дані OpenStreetMap. Для вправ нижче, ми знову будемо використовувати дані проєкту Open Cities Dhaka, які ви можете отримати завантаживши файл: dhaka_sql.zip.

Підготовка даних

Розпакуйте архів та відкрийте два шейп-файли в QGIS. Ми почнемо з вирізання лише будівель в межах проєкту, щоб зробити наші запити простішими.

• Давайте спочатку виділимо лише полігони, що знаходяться на потрібній нам території. Для цього ми будемо користуватись втулком Spatial Query Plugin. Якщо ви ще не встановили його з робіт це через меню Plugins -> Manage and Install Plugins.
• Меню Vector -> Spatial Query -> Spatial Query.
• Вам потрібно заповнити параметри, щоб виділити об’єкти з planet_osm_polygon що within target_area (знаходяться в середині target_area).

• Натисніть Apply. Будуть виділені лише полігони.

• Клацніть правою кнопкою на шарі та збережіть виділення в новий файл. Додайте його в проєкт.

• Тепер залишимо лише полігони, які є будівлями та які було додані в ході проєкту.
• Клацніть правою кнопкою миші на planet_osm_polygon потім “Filter…”
• Додайте наступний запит:

“building” != NULL AND “source” = ‘Open Cities Dhaka Survey’

• Натисніть OK. Відфільтровані за допомогою запиту дані будуть показані для полігонів що мають заповнений параметр building. Також це призведе до приховування будинків у яких значення параметра source не пов’язане з цим проєктом.
• Збережіть ці дані в новий файл. Ми будемо використовувати його для наступних запитів SQL.

Робота із запитами SQL

Тепер ми можемо робити запити до шару з будинками для пошуку можливих помилок. Подумаємо про деякі речі, про які ми могли б запитати. Модель даних цього проєкту має наступні атрибути, які слід зазначати для кожної будівлі - це:

• name
• building
• building:levels
• building:use
• building:vertical_irregularity
• building:soft_storey
• building:material
• building:structure
• start_date
• building:condition

Візьміть до уваги, що в шейп-файлі довжина назви параметрів обмежена 10 символами.

То які питання ми маємо поставити? Які ймовірні помилки ми можемо знайти? Найпоширенішою помилкою є випадок, коли будинок додано в дані, але не всі поля з інформацією про нього заповнено. Тож спочатку ми перевіримо чи є у нас будинки з неповними параметрами. Звісно, для деяких параметрів, таких як name та start_date (рік зведення), припустимо мати пусті значення, не кожен будинок має назву та не для всіх з ним нам відомо, коли їх побудували. Але інші параметри мають бути заповнені.

Спробуємо створити потрібний запит:

• Клацніть правою кнопкою миші на шарі (ми створили його раніше) та оберіть “Filter…”. Ми відкриємо вікно для вводу запитів. Тут ми можемо створювати складні запити, щоб побачити потрібні нам дані.
• Ви можете створити ваш власний запит обираючи подвійним клацанням потрібні поля, значення та оператори, або скопіювати запит який ми вже підготували:

“building_c” = NULL OR “building_s” = NULL OR “building_l” = NULL OR “building_m” = NULL OR “vertical_i” = NULL OR “soft_store” = NULL OR “building_u” = NULL

• Натисніть “Test”, ви маєте побачити що цей запит відібрав для вас 125 елементів. Це означає, що серед близько 3500 будинків у 125 відсутній один чи більше параметрів.

• Натисніть OK щоб показати тільки такі будинки, що відповідають умовам цього запиту.

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

Які ще запити можуть бути корисні? Ну, ви також можете перевірити наявність атрибутів, які не містяться у вашій схемі даних. Ми робили це в розділі Пошук в JOSM. За допомогою запиту можна знайти всі будівлі, атрибути яких не входять у вашу модель даних.

Ви можете також використовувати запити для пошуку аномалій в даних, які не обов’язково є помилками. Наприклад, якщо ми відкриємо вікно фільтра для створення запитів та оберемо поле building_l, клацнемо “All” для перегляду всіх його значень, ми побачимо, що серед значень від 1 до 20 (це кількість поверхів, значення теґу building:levels) є 51. У нас є небезпідставні сумніви, що тут може височити 51 поверховий хмарочос, тож ми можемо з’ясувати де знаходиться цей об’єкт та зробити помітку для маперів щоб перевірити його ще раз.

Запити можуть бути ефективним інструментом, що дозволяє нам шукати помилки в даних. В поєднанні з іншими можливостями QGIS вони можуть допомогти у створені мапи для подальшого процесу перевірки та уточнення даних.

Підсумки

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