Предисловие: извиняюсь за сумбурный стиль описания. за годы работы с ОСМ, накопилось много мыслей и эмоций, хочется выразить как можно больше, надеюсь это 1-й блин, в дальнейшем мысли будут более структурированными и картина более ясной.
Как поменять OSM XML.
- OSM XML - замечательный формат и, наверное, единственный замечательный формат. Он любому новому человеку позволяет понять “что-такое” OSM, просто взяв и открыв файл, и при некоторой сторонней помощи (wiki или человек) можно понять, что и как обозначается. Благо сущностей в нем всего 4: node, way, relation/members, tags. Дальше можно провести аналогию с частью большого и сказать, что это маленький кусочек OSM, а вот OpenStreetMap - это planet.osm.bz2 (50 GB).
Этот формат отличный, он позволяет начать программировать (скриптовать-автоматизировать) на любом языке с минимумом документацией, библиотеками и с максимумом пониманием. К сожалению, достаточно быстро возникают очевидные проблемы.
Многие могут подумать, что формат для человека и для машины это 2 абсолютно разных формата. На самом деле это не так, главное преимущество OSM, в том, что программисты тоже люди и когда они приходят им нужно разбираться, чтобы написать программу. Сила crowdsource, не в том что у нас есть 2-3 opensource тула, а в том, что в любой момент к нам могут присоединиться новые авторы-программисты и вывести проект на другой уровень. Присоединиться к существующему opensource проекту гораздо сложнее, чем кажется. Поэтому простота и мощь формата обеспечивает обучаемость человека, решаемость повседневных задач простыми средствами. Большинство из наших OSM-авторов умеет пользоваться скриптами, сложными редакторами (vi например), главная проблема кто-то знает python, кто-то perl, bash поэтому формат данных должен быть просто понятен. Я попытаюсь описать основные пункты улучшения формата и объяснить, чем они могут понять разным людям.
-
Ввести понятие quad-tree в формат. Для любого человека проблема найти что-то в более-менее большом osm.xml файле, в большинстве случаев остается только один вариант, зайти на OSM.org и скачать маленький кусочек того, что тебе нужно. Что делает не практичным возиться с большими файлами, к сожалению такая задача часто возникает при отладке. Имеется osm.xml и надо посмотреть, что в нем, но вопрос упирается, что невозможно эффективно вырезать из него кусок, используя текстовый редактор. В данном случае нужно использовать специальные тулы osmconvert. Если подумать, то эти тулы тоже решают сложную задачу, которая могла быть решена самим форматом. Ведь для того, чтобы вырезать надо посчитать bbox, а если прямо в файле по некоторому id или имени можно найти и вырезать, то, несомненно это упростило бы жизнь.
-
Как ни странно это звучит, но надо поменять геометрию и сортировку. Сейчас для того, чтобы вырезать некоторый кусок постоянно приходится читать или 2 раза или строить кеш из всех nodes. Основная проблема, что невозможно написать streamline алгоритм почти для любой практической задачи. Потому что, существует 2 типа запросов по карте (bbox упрощенно) и по типам объектов и для любого из этого запросов необходимо делать join node-way. Для решения этой задачи нужно прописать геометрию внутри объекта с тегами. Несомненно мы можем получить некоторую дубликацию данных, но это незначительный объем. По поводу сортировки, то необходимо, сначала писать relation, а затем объекты с геометрией. Тогда можно достаточно просто при проходе профильтровать по тегам, а затем объединить с геометрией. Обычно количество relation во много раз меньше, чем геометрии, поэтому можно безопасно хранить в памяти. Можно отсортировать relation, чтобы сверху были relation, которые используют другие relation, а внизу, которые не используют
- Расширение OSM XML дополнительными файлами.
На самом деле если предположить, что мы хотим оставить существующие форматы как есть, то можно попытаться не менять osm.xml, а сделать новый формат osm.xml.zip. И построить quad-tree индекс, например, внутри zip.
- Как это могло бы выглядеть.
osm.zip - содержит список osm.gz raw-файлы , которого являются quad-tree по алгоритму shortlink (ссылка на osm shortlink, т.е. AFAF.osm.gz покрывает AFAFBB, AFAFCC и т.п. квадраты). Каждый файл, содержит строго объекты внутри, объекты выходящии за рамки квадрата идут на уровень выше и т.п., для того, чтобы не разделять геометрию на границе quad-tree обычно строятся с некоторым наложением, что является некоторым неудобством, но вполне приемлимым решением. Вполне возможно допустить дубликацию данных на соседних тайлах. - Можно также построить tag_info.txt файлы для каждого quad-tree тайла, чтобы упростить поиск объекта. Вполне возможно его строить динамически для всей планеты, количество тегов является ограниченным числом и индекс со ссылкой на квадрат, в котором содержатся объекты является достаточно емкой, но удобной информацией, так же можно указать число объектов с этим тегом.
Для value можно построить 3-буквенный индекс или больше букв, в зависимости от размера тайла. Для маленьких тайлов это вполне может быть словарный индекс, любое архивирование osm и индекса вместе, сможет прекрасно вычленить дубликаты.
Имея такой формат мы можем решать огромное количество задач, просто имея текстовый редактор. В основном задач связанных с поиском, визуальные редакторы карт все так-же необходимы с единственным большим отличием, можно эффективно найти необходимый тайл для редактирования и уже в него внести изменения.
-
Таким образом мы подходим к вопросу, как же получить этот формат и поддерживать. Главное, что необходимо в решение задач нового формата, чтобы его обслуживания было простым и понятным. Преимущество “многофайлового” формата, что с ним можно работать распределенно. Можно так же обновлять частично, т.е. разные файлы. Правда совместно с этим приходят и проблемы. Самая главная задача, которую как мне кажется невозможно решать “без центрального сервера” нацеленного на этот формат, это provider “улучшенных” osmc. К сожалению сегодня osmc не содержат достаточно геометрия, без этого невозможно распределенно или частично обновлять существующие тайлы, по крайней мере не сканируя их всех. В принципе это замедляет весь процесс обновления! обновить планету даже на маленький osmc требует 20 минут, просто потому что весь файл перечитывается и переписывается. В новом формате этого можно избежать, и чтения и записи! Если можно сделать osmc api, то единственное, что необходимо и это можно сделать в backward compatible manner, что сущ-ие программы не сломаются.
-
Описанные изменения ведут к немного большему, чем просто изменение формата. Хочется поменять какие объекты мы имеем в OSM API, добавить multipolygon, но от этого настоятельно стоит воздержаться, если мы не научимся строить backward compatible изменения в API (то есть не меняя его вообще), скорость изменения API будет падать, пока не достигнет 0. Необходимо найти возможность сосуществовать с текущим API и пользоваться преимуществами нового.
Однако мы не должны думать о новых объектах иначе мы не найдем золотую середину.
К примеру, вот некоторые идеи, описанные отдельно. В распределенном по тайлам формате необходимо отказаться от связок через id.
- Отказ от node id в way
Недостатки:
Теряется связь между way и node (сейчас можно проверять, что node имеет тот же id что и в way) или невозможно понять что 2 way пересекаются (для решения см. 3).
Преимущества:
Возможность редактировать каждый way отдельно. Возможность без join найти полноценный геометрический объект и найти его координаты. - Отказаться в relation от использования member id. Member должны определяться, через теги.
Недостатки:
- в объекте relation невозможно, просмотреть список объектов. Его и сейчас невозможно просмотреть, кроме id, остальное надо мерджить.
Преимущества:
- на member объектах отображается достаточно информации обо всех relation. К примеру на остановке, будет подписано какие автобусы на ней останавливаются. Пример тег: bus:62= - Ввести специальный объект для описания взаимоотношений между геометрическими объектами.
Примеры:- Объект 1 содержится в объекте 2 (валидация)
- Объект 1 пересекается с объектом 2 в точке. Теги допустимы для описания запрещенных маневров к примеру.
- Объект 1 следует за объектом 2. (Автобусные остановки)
— Взаимоотношение между геометрией не ограничено конкретным списком, а является free style editing.
— Взаимоотношения в отличие от сущ-х relation являются локальными для одного файла, соответственно нельзя описать через “геометрические отношения” выразить admin_level=2.
Послесловие: суммируя все изменения, вырисовывается одна простая и понятная цель, неообходимо придумать такой текстовый формат, который будет удобно читать, искать, редактировать, обновлять и иметь у себя под рукой (в смысле объема на PC, хотя бы интересующей части). Как ни странно, если что-то будет удобно делать руками, автоматизация тоже получится простой и понятной.
Текст map editing кажется crazy, но, кажется, это дает интересные результаты.