Как бороться с версиями в OpenStreetMap?

Тема управления картографическими данными в более общем смысле , придумал прежде , чем здесь. Тема версионирования также упоминалась там, но на самом деле не рассматривалась.

Традиционный сбор и обслуживание геопространственных данных требует лишь внутреннего контроля версий, поскольку база данных обновляется только внутри организации. Это не относится к краудсорсинговым базам геоданных, таким как OpenStreetMap. Там каждый может прийти и добавить, изменить или удалить объекты. В OpenStreetMap это решается в зачаточном виде: каждый объект имеет целочисленный номер версии, и только объект с самой высокой версией представлен в действующей базе данных. База данных использует оптимистическую блокировку, поэтому пользователи должны разрешать все конфликты, возникающие при загрузке вкладов вручную.

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

1. Строительный объект импортируется из открытого набора данных государственного сектора
2. Здание получает некоторые модификации от людей (атрибуты, геометрия или оба)
3. Новая версия данных государственного сектора становится доступной и импортируется.

В настоящее время на шаге 3. человеческие вклады будут потеряны, если каждое здание, получившее модификации сообщества, не будет вручную объединено с новым импортом.

Как OpenStreetMap может справиться с этой ситуацией? Нужно ли нам смотреть на распределенный контроль версий при разработке программного обеспечения? Как можно адаптировать методы DVC для обслуживания распределенных пространственных данных?

Я мечтал о том, чтобы кто-то реализовал неразрушающее редактирование данных ГИС. Это требует интенсивных вычислений, но не должно быть трудным для реализации в RDBMS.

Начните со снимка данных. Любые изменения сохраняются как изменения, исходные данные остаются без изменений. В вашем примере здания изначально поступают из данных государственного сектора. Когда пользователь выполняет редактирование, изменение или различие сохраняются в отдельной таблице. Когда кто-то просматривает объект, ему предоставляется оригинал плюс все внесенные изменения. Последующие правки - это вычисленная разница между новой формой объекта и оригиналом, а также все предыдущие правки.

Это дает вам возможность отменить на мелком уровне. По сути, это то, что делает контроль версий. Хороший пример неразрушающего редактирования - Apple Aperture. Импортированные цифровые изображения в Aperture не изменяются напрямую. Изменения уровней, резкости, размытия и т. Д. Сохраняются как изменения и применяются на лету при работе с изображением. Любое изменение может быть немедленно удалено.

Конечно, вы бы сделали снимки БД для распространения и использования в производственных средах. Это будет только для разработки и редактирования.

Посмотрите на версии 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

Чангсеты: http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#Changeset_Derivation_and_Merging

Я хоть и об этой проблеме и задумывался, но не проверял. Это может сработать:

Используйте систему контроля версий, такую ​​как Mercurial или Git. Mercurial станет проще, поскольку позволяет легко создавать анонимные ветки.

Теперь с первоначальной ревизии запустите ветку для импорта открытых наборов данных. Итак, будет 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 в виде версий. (Или файловую систему можно смоделировать).

Я не могу гарантировать, что это сработает.