OpenStreetMap

актуальность != достоверность

Posted by Max Vasilev on 20 August 2012 in Russian (Русский)

Большинству "картографов" ОСМ совершенно чуждо понятие ответственности в плане поддержания чистоты, полноты, корректности и актуальности данных. У некоторых оно есть, но сильно в однобокой и не всегда адекватной форме. Когда вторые - это новички, а первые - "опытные" маперы, то ничего не происходит, потому что первым влом. Когда "опытные" маперы - это вторые, а первые новички, то начинаются массовые правки пустого в порожнее.

Когда чувство обострённой картографической справедливости обостряется не у картографов, а у программистов, а полноты восприятия всей системы, как единого набора данных нет - рождаются сферические валидаторы в вакууме. Основная причина отсутствия полноты восприятия - закостенелость мышления и видение только одной, сугубо прикладной стороны применения всех данных. Чаще всего это звучит так: "в моём конвертере под мой конкретный навигатор это работает только так, значит так должно быть везде".

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

Мой личный эксперимент показал, что группа из 5-8 школьников старших классов, после 20-ти минутной устной лекции об основах классификации и генерализации геопространственных данных и 10-ти минутным знакомством с GIS инструментом, способна за один факультативный час (одна пара уроков по 45 минут) обрисовать больше чем десяток опытных участников проекта ОСМ за тот же период времени, совершив при этом на порядок меньше логических, структурных и взаимосвязанных ошибок.

Почему же тот же гугл очень не охотно идёт на контакт в плане обмена технологиями и методами работы в своих пользовательских картопроектах с участниками других проектов, а предпочитает организовывать регулярные семинары для полных нубов, разжёвывая каждый раз с нуля то, что казалось бы не нужно было бы объяснять тем, кто уже был знаком с основами "пользовательской картографии"? Всё просто - обучить правильно группу школьников проще и результат в итоге будет качественней, чем передалбливать сомны догматических заблуждений закоренелым маперам, которые уже завесили свой мозг непробиваемыми шорами и подписали свои все свои догмы как "аксиома №1, №2" и т.д., даже не предпринимая более попыток анализировать картину абстрагируясь от устоев.

Сразу замечу, что при более правильном и экономичном подходе в организации работ, у того же гугла в районе пользовательской картографии есть свои, специфичные ему родовые травмы, которые тоже не делают из него конфетку, но речь не об этом.

Можно ли сейчас использовать проект ОСМ как полноценный и достоверный источник геопространственных и справочных данных? Напрямую - нет. Ни как достоверный, ни как полноценный. По крайней мере актуально нельзя получить. Требуется процесс несколькоуровневой ревалидации данных на реальных, а не синтетических тестах, построенных по реальному шаблону применения данных. Это и полнота и взаимосвязанность данных и роутинговые тесты и логические структурные тесты. Чем больше тестов - тем больше времени, зачастую ручного времени, тем меньше актуальность данных. По статистике и общей практике 80% времени тратится на приведение косяков в норму, откат вандализма, структурирование данных, 15% на обработку отвалидированных данных с целью получения конечного результата и только 5% на добавление новой информации в проект.

Если нужны самые актуальные данные, то ни о какой достоверности уже речи не может идти. Сам по себе этот компромисс в проекте ОСМ смещён строго в сторону актуальности. Т.е. беря данные напрямую из проекта, вы всегда берёте самые актуальные данные с всем самым актуальным вандализмом, без какой либо претензии на адекватность данных.

Если ваш проект чуть крупнее чем маленькая самосборка на коленке, то для вас такая актуальность уже не так важна как качество выходных данных, а значит вы уже по определению будете тратить время на постобработку и ревалидацию данных, почти независимо от сроков выполнения этой процедуры. Такая модель (модель ступенчатых фриз-релизов после серии QC тестов) знакома разработчикам ПО и стандартна в рамках работы любого крупного издателя конечного продукта. Модель же роллингового развития продукта характерна для большинства децентрализованных, не-production-ориентированных проектов.

Что делать, если всё таки есть желание использовать ОСМ как источник данных? Вводить двухуровневую систему. Брать данные из ОСМ, определять для себя и своих потребностей два вида критериев достоверности данных: 1) структурные ошибки, которые могут быть исправлены только в самой базе ОСМ; 2) нормализация и генерализация даннных, не требующая внесения изменения даннных в самом проекте ОСМ, а выполняемая на копии локальных данных. После проведения этих двух этапов необходимо определить перечень и объём QC тестов и планомерно достигать полного их прохождения, путём внесения изменений в сам проект ОСМ и копии изменений в локальные данные, а так же возможно и внесение изменений в методы нормализации и генерализации. Если же объём изменений самих данных велик, то возможно придётся спустя некоторое время заново взять полный объём данных из ОСМ и заново запустить процесс итераций по нормализации локальной копии данных.

Почему это нельзя сделать в проекте целиком? Потому что ОСМ - это всего лишь набор данных, без привязки к конкретному конечному использованию, а методы нормализации данных всегда жёстко завязаны на конечный выходной продукт, следовательно все постобработки возможны только персонально под каждый конкретный конечный продукт, т.е. говоря другими словами: ОСМ - всегда только полуфабрикат без этикетки, остальное - самостоятельно напильником, газовым ключём и изолентой.

Что нужно проекту сейчас от его активных участников?

  1. Самое главное, давайте периодически постараемся быть школотой и забудем ненадолго о придуманных нами же догмах, а подумаем о предмете нашего труда абстрактно, в целом, с нуля. Что бы увидеть главное, иногда надо отойти в сторону и взглянуть издалека. Многие аксиомы в таком случае теряют свой определяющий фактор и начинают казаться искусственными.

  2. Давайте не будем превращать базу ОСМ в "локальную копию данных" под свой конечный продукт, доводя до абсурда некоторые вещи и вводя в аксиомы искусственные ограничения отдельных продуктов и распространяя это на весь набор данных.

Comment from Zverik on 20 August 2012 at 08:23

«Брать данные из ОСМ, определять для себя и своих потребностей два вида критериев достоверности данных: 1) структурные ошибки, которые могут быть исправлены только в самой базе ОСМ; 2) нормализация и генерализация даннных, не требующая внесения изменения даннных в самом проекте ОСМ, а выполняемая на копии локальных данных. После проведения этих двух этапов необходимо определить перечень и объём QC тестов и планомерно достигать полного их прохождения, путём внесения изменений в сам проект ОСМ и копии изменений в локальные данные, а так же возможно и внесение изменений в методы нормализации и генерализации.»

Я правильно понимаю, что это можно сократить до «выкачать данные OSM себе, преобразовать в удобный для обработки формат, валидировать и исправить ошибки, загрузить изменения обратно в OSM», что, в свою очередь, означает просто создание валидатора и правку данных OSM, что не сильно отличается от нынешней модели?

Также, можно пример догм, на которые ссылается текст? Или это упрёки только в сторону критериев качества, введённых Кириллом в своих валидаторах?

Hide this comment

Comment from Zkir on 20 August 2012 at 09:42

Макс, много букв, обвинения в догматизме и безграмотности, а чего-то конкретного - ноль.

С тем, кто понимает чего он хочет от OSM и от системы тегов, и способен это сформулировать - можно и нужно договариваться. С тем же кто только кидает обзывалки - невозможно.

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

Hide this comment

Comment from Max Vasilev on 20 August 2012 at 09:43

Не правильно поставленный вопрос.

Речь не идёт о замене процесса редактирования данных. Речь идёт о разделении редактирования данных в целом, которое как было так и осталось и на обработку данных под конечный продукт отдельно от основной базы. Если надо нормализовать какие то вещи, но это нужно только для выпуска ограниченного количества продуктов - пожалуйста, используйте препроцессинг под свои собственные нужды у себя локально, а не превращайте основную базу в набор оптимизированных данных.

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

Попытка искусственно привести данные к модели одного единственного дерева понятна и она была уже давно озвучена тем же Кириллом: "Ситигид испытывает трудности в расчёте маршрута при другой модели данных". Это и есть попытка уйти от реальных данных в данные нормализованные под один конкретный конечный продукт.

Что касается других догм, то я пока не буду заострять на них внимание, по крайней мере до времени, когда очевидность борьбы с "изолированными подграфами" для части мапперов не перейдёт из разряда религии в разряд информации для анализа.

Hide this comment

Comment from Zkir on 20 August 2012 at 09:51

... или даже по принципу "Маппинг для самовыражения".

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

Например, в России больше 1000 городов. Если построить маршруты между ними попарно, получится 2,000,000 (два миллиона) маршрутов. Кто их должен отсматривать и когда? При этом эти два миллиона маршрутов покрывают лишь малую часть дорожного графа.

Hide this comment

Comment from Zkir on 20 August 2012 at 09:58

Макс, модель "общего суммарного трафика" не реальная модель, а просто модель которая больше тебе нравится/больше тебе подходит. Она далеко не единственная.

Более того, модель "общего суммарного трафика" совершенно не соответствует принятой в РУ-ОСМ системе класиификции дорог по значимости тег highway. Очень странно, что ты этого не видишь/не хочешь видеть.

Hide this comment

Comment from Zkir on 20 August 2012 at 10:04

И мне кажется, что тебе нужно не бороться против борьбы с изолированными подграфами, а расставить на дорогах данные о трафике (если ты им располагаешь) в машинах в час. И все твои проблемы (если они у тебя есть) решатся.

Hide this comment

Comment from osmisto on 20 August 2012 at 10:10

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

Плюсую. Качество OSM баз автоматики, т.е. валидаторов - это фантастика. И рисовать под валидаторы - тоже правильно.

А если валидатор показывает ненужную ошибку, или неправильную ошибку, вынуждая нарисовать что-то неправильно, значит надо срочно чинить валидатор.

Hide this comment

Comment from Max Vasilev on 20 August 2012 at 10:45

... принятой в РУ-ОСМ системе класиификции дорог по значимости тег highway. Очень странно, что ты этого не видишь/не хочешь видеть.

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

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

Более простой алгоритм, для более обычного применения - это обычный роутинговый граф, но не зацикленный на модель одного единственного дерева. Между прочим прекрасно рассчитывается маршрут и в обычных гарминах, при множестве "изолированных подграфов на определённом уровне". То, что ситигид не может это осилить - это не повод заявлять, что любая модель, кроме искусственно примитизированного единственного дерева - не реальная.

Есть ещё несколько моделей расчётов и анализа маршрутов, в том числе и азимутальных с избеганием дорог и минимизацией пересечений трасс.

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

Hide this comment

Comment from Zkir on 20 August 2012 at 14:43

Макс, делить модели на "реальные" и "нереальные" очень страно. Модель может быть адекватна или не адекватна некоторому применению. Поэтому моделей может быть много - о чем я и пишу. Так что "догматизм" я переадресую обратно тебе. :)

А вот что действительно невозможно - запихнуть разные модели в один и тот же тег (в данном случае highway).

Что касается классификации по значимости (и связанных с ней требований), у тебя какое-то странное представление, что это такое и зачем она нужна. Я писал много и часто, но наверно не вполне понятно :( На досуге попробую еще раз.

Она была придумана не мной, и не потому что ситигид чего-то может или не может, а потому что это удобная (естественная, реальная) модель для автомобильных навигаторов. Пользователи Гармина, Навитела и Гисруссы ее поддержали. Тому кто считает маршруты на супер-сервере с учетом азимутального направления движения относительно времени суток, она естественно кажется нереальной.

P.S. Попробуем найти человека способного абстрагироваться от собственных проблем.

Hide this comment

Comment from bopoh13 on 21 August 2012 at 02:11

#Уже писал, но повторюсь: Чтобы проект мог перейти в стадию конечного продукта необходимо создать структуру и её поддерживать. Это первоочередная задача.

##Если не знаешь букв, то и читать не сможешь (тут и говорить не о чем).

Смысл на пальцах объяснить просто, - достучаться до людей сложно, т.к. люди не умеют читать по слогам, а значит, читают то, что хотят прочитать.

В техническом языке всегда есть структура, не позволяющая месту быть любым разночтениям. Если это "напильник", значит это "инструмент, который выполняет функцию для распиливания отверстий, отпиливания острых углов и опиливания поверхностей", но никак не "забивание гвоздей, открывание бутылок с пивом и т.д."

Для достижения целей в команде не может быть "Хочу", может быть только "Как надо". Если нет предложений "Как надо" - разговаривать вообще не о чем (и незачем вылезать из каналов в #IRC)

Hide this comment

Comment from lenux on 21 August 2012 at 13:26

Если честно на мой взгляд у нас нет базы на которой можно было бы строить качественные карты. Просто откройте http://maps.google.com/?ll=61.856149,119.882813&spn=76.454042,270.527344&t=m&z=3 , а затем osm.org.ru и видно, что на нашей на карте нет ни морей, ни океанов. Даже транспортный слой на главной osm.org красивее. Получить информацию о том, что это к примеру это Рыбинское вдхр так и постараться надо в джосме, либо в правках посмотреть данные (выделив линию, нажав на Подробнее и посмотреть в каких отношениях она участвует.

Это если видимой части, что видит пользователь когда заходит.

Теперь внутренней. Сейчас нет единого мнения как и что надо рисовать. Создайте уроки, выложите на Ютюб как правильно рисовать дороги/лес и т.д. Что бы мы мапперы могли обращаться к этому, как к источнику данных. Все не понятки идут от одного, что то что прописано в вики оно условно. Например: Как я должен классифицировать дорогу соединяющую через лес, болото одну деревню с крайней деревней где виден только один дом? Поправилам uncl, хотя тут и track с натяжкой. А ведь я ещё должен огородить этот домик на полигон навесить теги с точки и поставить landuse=residental, дорогу разорвать и сменить её на highway=residental. И это не единичный случай, подобной разумности. Потому что человек (и я в том числе) если видит две полоски огороженных линией(нарисованную uncl), то ожидает хорошую дорогу. А пунктир что-то тут плохая дорога. Потому что иначе если человек не владеет, и не знает (а новичок и случайный человек который зашёл он не владеет и не знает) что вот в проекте OSM мы рисуем, а точнее не рисуем, а наполняем базу. Потому, что если человек посмотрит на мапник (и к примеру у него нет навигатора) на деле он может приехать и мягко говоря удивиться, что по карте никаких различий обычное ответвление, а на месте ток на Урале.

У меня есть определенная мысль как получить качественную карту. Но я боюсь она не реализуемая. Суть её в разделении ОСМ на векторный и растровый. Если к примеру взять разграфовку мира по секторам, разные масштабы. То подготавливать растровые карты, но брать за основу ОСМ. Таким образом если хочешь самой последней информации смотри отрисовку мапника, если качества то подобный растр. + это сильно поможет в планомерности и поэтапности отрисовки (я думаю). + Моральное стимулирование выполнить качественно - Проблема рендинга этих гифок (в частности как и что отображается)

В качестве примера: http://upload.wikimedia.org/wikipedia/commons/d/d4/North-East_part_of_Caspian_Sea_%28IMW_NL39%29.jpg Только это конечно крупномасштабная :)

В частности это мысли по небольшим масштабам. По крупным (скажем в 1 см:25км) тут уж не знаю как лучше всё сделать.

Hide this comment

Comment from Zkir on 21 August 2012 at 18:43

Все не понятки идут от одного, что то что прописано в вики оно условно. Например: Как я должен классифицировать дорогу соединяющую через лес, болото одну деревню с крайней деревней где виден только один дом? Поправилам uncl, хотя тут и track с натяжкой.

В вики написано предельно однозначно - highway=unclassified+surface=unpaved. Если бы Мапник показывал unclassified с покрытием и unclassified по разному, как это принято в навигаторах, проблема бы мигом решилась бы.

Но по сложившимся в осм порядкам это проблема скорее самих пользователей мапника, и решить ее должны они :D

Hide this comment

Comment from Zkir on 21 August 2012 at 18:44

следует читать:

Если бы Мапник показывал unclassified с покрытием и unclassified без покрытия по-разному, как это принято в навигаторах, проблема бы мигом решилась бы.

Hide this comment

Comment from dkiselev on 22 August 2012 at 09:11

Максим, выложите куданибудь, то, что вы рассказываете школьникам.

Hide this comment

Leave a comment

Parsed with Markdown

  • Headings

    # Heading
    ## Subheading

  • Unordered list

    * First item
    * Second item

  • Ordered list

    1. First item
    2. Second item

  • Link

    [Text](URL)
  • Image

    ![Alt text](URL)

Login to leave a comment