Як боротися з версіями в OpenStreetMap?

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

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

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

1. Будівельний об’єкт імпортується із відкритого набору даних у державному секторі
2. Будівля отримує деякі модифікації, внесені людьми (атрибути, геометрія чи обидва)
3. Нова версія даних про державний сектор стає доступною та імпортується.

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

Як OpenStreetMap може вирішити цю ситуацію? Чи потрібно дивитися на розподілене управління версіями при розробці програмного забезпечення? Як методи DVC можуть бути адаптовані для вирішення розподіленого обслуговування просторових даних?

Я мріяв про те, щоб хтось впроваджував неруйнівне редагування даних ГІС. Це обчислювально, але це не повинно бути важко реалізувати в RDBMS.

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

Це дає можливість скасувати на дрібнозернистий рівень. По суті те, що робить контроль версій. Хорошим прикладом неруйнівного редагування є діафрагма Apple. Імпортні цифрові зображення в діафрагмі не змінюються безпосередньо. Зміни рівнів, різкості, розмиття тощо зберігаються як редагування та застосовуються під час роботи з зображенням. Будь-яку зміну можна миттєво видалити.

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

Погляньте на версії PostGIS , pgVersion та Post Facto для ідей та можливих рішень. Це системи управління версіями, реалізовані в базах даних PostgreSQL.

OSM використовує Postgres і Postgis, які зберігають знімок бази даних.

Для реалізації цього на власному сервері та базі даних

http://wiki.openstreetmap.org/wiki/Databases#Choice_of_DBMS

База даних (plantet.osm) оновлюється щотижня http://wiki.openstreetmap.org/wiki/Planet_dump

Осмоз звик до"в ньому є компоненти для читання з бази даних та з файлу, компоненти для запису в базу даних та файлів, компоненти для отримання та застосування наборів змін до джерел даних"

http://wiki.openstreetmap.org/wiki/Osmosis

Changsets: http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#Changeset_Derivation_and_Merging

Я хоч із цією проблемою і мав ідею, але не перевіряв її. Це може спрацювати:

Використовуйте систему контролю версій, наприклад Mercurial або Git. Меркуріал буде простішим, оскільки він дозволяє легко створювати анонімні гілки.

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

1. основна лінія (OSM)
2. загальнодоступний набір даних X

Імпорт із загальнодоступного набору даних повинен бути виконаний у гілці 2, а потім об'єднаний у гілку OSM.

Ваш сценарій може працювати так:

• об’єкта не існувало
• то його імпортують і об'єднують у відділення 1
• то він змінюється в магістралі, включаючи геометрію
• знову імпортується у відділення 2
• коли він об'єднаний у гілку 1, у галузі 1 оновлюються лише ті дані, які були оновлені у гілці 2

Це може зажадати розбиття даних на кілька файлів, по одному на об’єкт і, ймовірно, у такому форматі, як json, щоб VCS міг легко боротися зі змінами окремих атрибутів.

{
     id: 1357
     lat: 1,
     lon: 2,
     tags: {
          'building': 'entrance'
     }
     type: 'node',
}
{
     nodes: [
         1357,
         2468
     ],
     tags: {
         building: 'yes',
     }
     type: 'way',
}

Я знаю, що розділення інформації на мільярд файлів - це занадто багато для будь-якої системи. Натомість слід використовувати ядро ​​VCS, а дані OSM обробляти та подавати у VCS у виправданому вигляді. (Або з файлової системи можна знущатися).

Я не можу гарантувати, що це спрацює.