Главная

Верификация

Главная
География
Интерфейс
ТЗ
Начало
Очистка
Верификация
Описания
Эксперимент

Карта

Поиск ошибок в данных




Назад...   Далее...

На этом этапе осуществляется комплексная верификация данных БД. Здесь у нас несколько разбухает объём из-за появления значительного числа технологических массивов, которые нужны только для верификации и будут впоследствии удалены. Это списки уникальных идентификаторов элементов данных типа way и relation, а также идентификаторов данных с "геометрическим" (являющиеся дочерними элементами других данных БД) или "описательным" (имеющие собственные описания) иммунитетом от удаления из БД. При этом выявляются ошибки вида:

  • Не найдены дочерние элементы, на которые есть ссылки из родительских (отдельно для каждого типа данных). Родительские элементы, содержащие такие ссылки, помечаются как "потенциально бракованные".
  • Не найдены элементы, для которых имеются описания. Очевидная ошибка в БД.
  • Найдены элементы без иммунитета. По идее, их нужно выбрасывать из базы, хотя, теоретически, возможно, что элемент, востребованный в каком-то районе Канады вдруг обнаружится где-нибудь в Антарктиде. Проверка, конечно, громоздкая, но разочек проведём "для очистки совести".

Тип node

Основная масса узлов переводится в литеральные значения траекторий типа way. При этом возможны варианты:
  • Все узлы данной траектории благополучно конвертированы в новый формат. Успешное завершение процесса конвертации, так и должно быть.
  • Хотя бы один узел траектории не удалось перевести к новому формату. Ошибка в данных, траектория помечается как "бракованная".

После завершения конвертации мы, помимо набора "бракованных" траекторий можем получить и массив "ненужных" узлов, которые не принадлежат ни одной траектории. Это ещё не означает ошибку в данных: ведь узлы могут принадлежать траекториям типа relation или быть самостоятельными элементами БД, имеющими собственное описание. Если этих связей не обнаружено, такие узлы должны быть удалены как "мусор".

Как ни странно, при переводе траекторий типа way в новый формат данных не было обнаружено ни одной бракованной! Это означает высочайшее качество данных, которое, конечно, обеспечивается программным обеспечением OSM - люди настолько безошибочно работать не могут! А вот с другими данными дела обстоят заметно хуже. В частности, обнаружено 312057 траекторий типа way, которые не только не имеют описаний, но на них никто и не ссылается. Что с ними делать? Выбросить? Или пометить как бракованные и натравить на них волонтёров? На карте ведь всё равно какие-то линии ими могут быть прорисованы. Ладно, пока оставим. Узлы-пустышки выбросим, а траектории-пустышки оставим. Но вообще, объект без описания - это ненормально, это ошибка. И таких объектов в базе не так уж и мало - тех же way-траекторий без описаний более 12 миллионов!

Чтобы особенно не перелопачивать большие массивы, мы собираем элементы данных (отдельно по каждому типу данных) с описательным или геометрическим иммунитетом по всей базе (их относительно немного), а проверяем их наличие в конкретных нарезках конкретных стран и регионов (таковых в базе 380) - так намного быстрее. Кроме того, мы формируем списки идентификаторов траекторий, присутствующих одновременно в нескольких нарезках - они могут быть разными из-за ошибок в данных. Таких траекторий также немного. После этого процесс верификации данных БД можно считать завершённым.

Забавно, но, как оказалось, в Монако и на Азорских островах нет ни единой траектории, которая не дублировалась бы в каком-то другом файле. Оно и понятно: попробуй-ка нарисовать карту Франции, чтобы не зацепить Монако! Азоры - это, разумеется, Португалия. Столь же понятно, почему Антарктида, Куба, Мадагаскар или Мальдивы не имеют ни одного дубля в других нарезках. А вот траектория с ID rel=148838 дублируется аж в 64 файлах! Нетрудно догадаться, что она называется "административные границы США".

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

Как будем исправлять ошибки? Да очень просто! Ссылки на отсутствующие в БД элементы игнорируем, а данные из разных нарезок тупо сливаем в одну: либо они полностью поглощаются (нет ошибок рассогласования), либо имеем некоторый "дребезг" при прорисовке траектории (если они похожи друг на друга). Если же они совсем непохожи - что ж: мы уже пометили траекторию как бракованную.

Все эти проверки, хотя и довольно громоздкие по времени выполнения, имеют весьма простые и очевидные алгоритмы: это фактически проверка уникальности тех или иных идентификаторов (без значений информационных полей), иногда совмещённая с операциями пересечения или объединения тех или иных множеств. Последняя проверка чуть сложнее: проверяется уникальность идентификаторов траекторий вместе с полем порядкового номера узла в траектории (также без значений).

Тип way

Траектории мы пересобираем заново в порядке следования их узлов и убираем поле Number, т.е. переводим реляционный вид снова в иерархический, а данные о порядке следования - вновь в информацию. Карта готова!

Тип relation

Я пока плохо понимаю, что представляют собой данные этого типа, но, как минимум, нужно убедиться, что все дочерние элементы этих траекторий (типа node, way или relation) имеются в наличии (в противном случае траектория бракованная). Кроме того, здесь мы выявляем иерархическую зависимость элементов БД по измерению принадлежности (входит в...), хотя основная иерархия, разумеется, должна извлекаться из описаний.

Очеводно, что основная (и, возможно, единственная) ценность траекторий типа relation - они работают как контейнеры дочерних элементов. Попытка привнести туда рёберную информацию (если рассматривать БД как граф) с помощью насильственно втиснутого атрибута role явно не удалась - достаточно сказать, что львиная доля элементов данных в этих траекториях (61.5%) значением этого атрибута имеют пустышку (role=""). И вообще редакторы БД плохо понимают что с ним делать - здесь сплошь и рядом встречаются описания (место которым в данных формата EAV - например, URL) и просто мусор. Самыми распространёнными значениями атрибута являются outer, inner, forward, stop, from, to, via, информационная ценность которых стремится к нулю. Немало и явно описательных значений (house, platform, street, admin_centre, subarea). Ладно, пока оставим - возможно, приткнём кое-что в описания.

Масштабирование

В новом формате записи координат подготовка карт разных масштабов тривиальна - она заключается всего лишь в обработке данных типа way. В самом деле, информация о местоположении точечных объектов на карте любого масштаба содержится в их идентификаторах уже сейчас, а траекториям типа relation (не говоря уже про описания) и вообще нет никакого дела до карты - они просто группируют дочерние объекты по измерению принадлежности. Да и сам алгоритм формирования траекторий для карты очередного масштаба намного проще и быстрее, чем даже процесс конвертации данных в этот формат. Отметим, что не только полигон фактически ничем не отличается от любой другой линии (просто первый и последний элементы совпадают), но и одиночный узел есть та же ломаная, состоящая из одного элемента. Таким образом, мы вообще избавились от типа данных node - отныне вся "геометрия" представлена только элементами типа way, которые, при необходимости, собираются в контейнеры типа relation и имеют описания в формате EAV. Их идентификаторы - последнее, что связывает [пока ещё] нашу БД с исходной базой OpenStreetMap.

Алгоритм формирования комплекта карт всех масштабов полностью автоматизирован и выглядит следующим образом: у элементов траекторий типа way карты текущего масштаба отрезается последний символ, после чего убираются образовавшиеся (идущие подряд) дубли. Затем из общего массива выделяются группы схлопнувшихся в точку траекторий, а также группа "отрезков" - траекторий, в которых осталось ровно два узла. Ни те, ни другие на карту более грубого масштаба не переносятся (если не будет найдено убедительных аргументов за то, чтобы их оставить на формируемой карте). Остальные траектории (если не будет найдено убедительных аргументов за то, чтобы их не переносить на карту нового масштаба) образуют новую карту и процесс повторяется. Комплект карт готов!

Новый формат записи координат как иерархического набора карт, в которые они входят, имеет реальную практическую ценность, причём сразу в двух смыслах: для сервера (позволяет группировать рядом расположенные данные и передавать их пользователю единым куском, не рыская по базе данных) и для клиента (позволяет прорисовывать траектории на карте, не обращаясь к БД за данными о координатах узлов - вся необходимая информация для этого уже "упакована" в их идентификаторах). Таким образом, уже сейчас (теоретически) можно получать всю информацию о карте с основной БД проекта OpenStreetMap, а прорисовывать объекты на компьютере клиента уже по новым данным - теперь это может сделать "любой дурак", если он хоть немного понимает в программировании: все данные у него уже под рукой, "на блюдечке с голубой каёмочкой".

На этом шаге база данных претерпела серьёзнейшую модификацию: литеральные "де факто" объекты стали литеральными и "де юре". Отныне любой объект становится непосредственно адресуемым лишь в том случае, если он привязан к внегеометрическому объекту БД (имеет описание). Кроме того, тип данных node полностью поглотился типом данных way, а тип relation упростился до обычного контейнера дочерних элементов.

Я знаю, что вы знаете, что "гладко было на бумаге"! Простейший (и нокаутирующий) вопрос: "Если масштабирование выполняется столь просто, то почему же до сих пор нет этого набора карт? Ведь его вообще нет! Это мы так лихо описали (и даже реализовали) алгоритм: траектории, состоящие из одного узла и "отрезки" на карту слдедующего масштаба не переносятся. А на деле? Разве кому-то непонятно, что Храм Василия Блаженного на любой карте должен быть гораздо заметнее, чем какая-нибудь "хрущёвка" или современная железобетонная коробка - пусть даже намного более крупная! Так что решение о существовании любого объекта, включая точечные, должно приниматься индивидуально для карты каждого масштаба. И алгоритмы этих решений не такие уж и простые. Скажем, какой-нибудь задрипанный "Учкудук", в котором всего-то "три колодца" в "горячей пустыне" очень даже важный ориентир, а кому он нужен вне её? Тем не менее, техническая часть подготовки карт разных масштабов действительно проста именно в той степени, как это описано - ею мы и завершим этот "многострадальный" шаг. А далее займёмся поиском тех самых "аргументов", то есть рубрикацией объектов по их описаниям.
Назад...   Далее...

28.03.2019 09:48
 
`