Нормализация данных (пилотный проект — Спб и ЛО)

Создание БД

  1. Файл leningrad.osm заливается в специализированную БД (моя разработка)
  2. Для каждого ключа (landuse, amenity, shop и т.п.) описанного в русской вики-документации создаются записи в БД, которые отмечают корректные ключи
  3. Для каждого значения ключа (yes, university, footway и т.п.) описанного в вики-документации создаются записи в БД, которые отмечают корректные значения ключей
  4. Аналогичное действо на комбинации ключей, скажем maxspeed и natural – некорректные сочетания ключей
  5. Дополнительные проверки

Это всё моя внутренняя работа, в конце могу создать отдельную страницу с результатами.

Обработка исключений

  1. То что не описано в документации подвергается анализу в виде валидационных страниц
  2. Если данные — следствия опечаток то исправляются вручную в моём валидаторе
  3. Если какие-то данные активно используются но не описаны корректно в документации — выставляю запрос на форуме о необходимости создания proposal или перевода страницы. Перевод могу сделать сам
  4. Если данные непонятны но используются несколькими авторами то попытка связаться с авторами и создание соответствующей темы в форуме
  5. Если данные созданы когда-то одним-двумя авторами давно и никаких упоминаний в документации то создаётся новая тема и эти данные объявляются мусорными в случае отсутствия какой-либо ясности

Это основной массив работы.

Процесс выявления и обработки мусорных данных

  1. О данных, значение которых не ясно и отсутствует какая-либо документация оповещаются все потенциально заинтересованные люди
  2. Если кто-то сможет создать адекватный proposal на эти данные то это наилучший вариант
  3. Если странные данные не удалось документировать и авторы не отвечают, то такие данные добавляются на вики-страницу «К удалению».
  4. Если данные вызывают вопросы, то перед удалением можно проставить специальный тег типа “FIXME=Proposal needed” или какой-нибудь новый тег типа «To_be_deleted».
  5. Если данные находятся долгое время (скажем пол-года, год) на странице «К удалению» и никто не смог дать объяснения — что это за данные, то такие данные подлежат удалению
  6. Как альтернатива - предлагаю составить список мусорных данных которые препроцессором будут выкидываться из импортированных OSM файлов. Физическое удаление из БД OSM не потребуется.

Пока это план, детали будут обсуждены по результатам фактической работы.

Резюме: главной целью данной работы является именно упорядочивание документации. Вторая цель — валидация. Наименее значимая цель — выявление мусорных данных и создание механизма по их удалению из проекта. Последняя цель наиболее спорная, но в перспективе неизбежная.

О процессе работы буду отписываться в этой теме.

Нда.
Ссылки по теме: Machine-readable Map Feature list, Tag Central: a Schema for OSM.
А предложения по автоматическому удалению чего бы то ни было автоматически отвергаются сообществом.

Ого. И чем дело закончилось с идеей Tag Central?

Не закончилось, ещё только начинается. К сожалению, я забыл, как его сейчас называют, но проект жив.

Что-то мне подсказывает что это всё глобальные идеи. А сообщество здесь несколько ленивое для стандартов (или точнее - “наш стандарт - отсутствие стандартов”). Идея чумовая, но не прокатит из-за того что в каждой стране, городе, улице, пользователя свой “стандарт”.

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

Об этом даже не думайте, никаких “к удалению”, fixme и to_be_deleted, как минимум потому что any tags you like. Пнуть автора насчет пропозала можно, но если он не соберётся, это не должно быть поводом ни для каких деструктивных действий с данными.

Я так и знал что все прочитают текст по диагонали, пропустят текст выделенный жирным и выхватят фразу про удаление … и начнут холивар :slight_smile:

А ведь я чётко написал - “создание механизма по удалению мусора из проекта”. Это как смертная казнь - механизм должен быть а помиловать или казнить - решается индивидуально. При этом жирным выделил что эта третья по значимости задача, конкретно меня особенно не волнующая. Меня более волнует бардак с документацией. А в шкафах OSM хранится немало скелетов …

Так не надо было писать эту фразу, вызывающую холивар :slight_smile: Тем более, что она хорошо если третьестепенной важности в этом задуманном проекте.

систематизация нужна
посмотрим, что за инструмент вы сможете предложить :slight_smile:

Ну вот, самая простая часть закончена - создание БД и импорт в неё данных из OSM. Закачка файла СПб и ЛО длится 46 минут. Долго, наверное нужно будет подумать об увеличении памяти сервера.

Сейчас балуюсь с отчётами. Пока они более-менее дублируют то что уже есть в latlon-е - http://stat.latlon.org/ru/leningrad/latest/ Геометрию я пока не трогаю, это мне сейчас не особо интересно, а вот атрибутивная информация интересна.

Отпишусь когда будет собрана нормальная статистика к размышлению. Промежуточные построения нет смысла описывать.

После недели возни с файлами .osm появились первые результаты. Главный из них (для больше всех переживавших Zverik и AMDmi3) - объём несистематических данных весьма невелик. Для каких-либо техник удаления нет почвы и из своей повестки я это точно убираю. Я подозреваю, что это связано с гораздо более высоким порогом входа чем скажем в википедию и большая наглядность результатов действия вандалов.

180 ключей (k=““), описанных в вики или (если это что-то служебное типа esr или cladr) в форуме покрывают 99.5% всех свойств по выбранным мною регионам. Из оставшихся 0.5% что-то будет ещё разобрано, т.е. “за бортом” оказываются какие-то очень разовые малоценные теги либо очепятки. 825 значений (v=””) также покрывают около 99% данных. Здесь есть ряд спорных моментов, но о них отдельно.

А на сочетаемость проводилась проверка? К примеру что не может быть на одном полигоне landuse=forest и building=yes.

Думаю что в промэксплуатацию что-то пойдёт в районе майских праздников. Собственно запланировано 5 итераций:

  1. Собрать статистику по использованным в .osm (на нескольких регионах) ключам и привязать к wiki-документации или описанию на форуме. Это сделано
  2. Собрать статистику по использованию в .osm (на нескольких регионах) key=value и отсылка к документации. Это тоже сделано

Далее - сложнее.

  1. Собрать статистику по фактическим комбинациям тегов. И обкатать на rus.osm. Здесь уже начинается определённый уровень абстракции и есть параллели с упомянутым Tag Central, хотя и без фанатизма.
  2. Обкатанный и отлаженный инструмент попробовать испытать на соседях - финнах, голландцах, немцах. Уже неоднократно натыкался на то, что один и тот же тег используется нами по разному.
  3. Собственно создать валидатор годный для нормального использования.

Ну и параллельно хотелось бы как-то приводить в порядок документацию. Несмотря на то, что она достаточно неплоха (я ожидал худшего) неточностей хватает. Во всяком случае новичков она легко собьёт :frowning:

Какой-то такой план. Не думаю что я делаю что-то уникальное для проекта, но какой-то позитивный выхлоп в виде большей нормализации данных должен быть.

Здание лесничества.

Здание лесничества - становиться землепользованием что ли?

Земля под знанием управляется лесничеством.

Если территория лесничества ограничивается только этим зданием. Чет я сильно сомневаюсь в реальности такой ситуации.