Возможные изменения в OSM xml, API

Communities Россия (Russia)
61

Аккуратнее с заявлениями про нерабочесть xpath/css

мы же генирить их (txt/xml) хотим на каждый тайл

  1. мы используем тайлы
  2. xpath ломается одинаково по скорости с sed

https://en.wikipedia.org/wiki/XPath#Implementations - здесь далеко не все. И не все они “тупые” парсилки DOM

Предлагаю начать с XML потому что CSS мы всё-таки используем во многих OSM-проектах, да и разработчика с хабра проще подружить с XML чем OPL. Это не значит что JSON или OPL плохие, но не в первую очередь.

62

Скажем так, есть зарезервированные для этого дела типы данных. Но самих ссылок нет.

63

Я не собираюсь спорить о преимуществах и недостатках xml. Но и тому кто за это возьмется (кандидатур то у нас, как я посмотрю очередь стоит) xml бы не посоветовал.

64

И теперь все должны угадывать что же ты имел ввиду.

Ну так почему ты скажи?

Читаемость? Все вроде за это.

Популярность (простота освоения) среди разработчиков и готовые инструменты (целые IDE) для него?
Два десятка лет разработок и тестирования инструментов и инфраструктуры вокруг xml?
stackoverflow с тысячей ответов “как сделать это” на xml?

по гуглению “xml limitations” нашёл:

  • Length of XML 2,147,483,647 characters - нам это не грозит для тайлов на низших уровнях

https://en.wikipedia.org/wiki/XML_database
http://www.postgresql.org/docs/devel/static/datatype-xml.html
http://exist-db.org/

65

Дак я сказал, сортировать - неудобно, мержить - неудобно.
Как формат для кодирования объекта в рамках одной строки - можно и xml и json и OPL здесь я не вижу принципиальной разницы.

А то что чудес для xml в мире - как мух в сортире, дак это я знаю. Если у тебя 1 объект - 1 строка, при грамотной записи, ты можешь сортировать и фильтровать файлики (по некоторому ограниченному набору параметров) без парсинга, просто как строки.

Я еще разок повторюсь, что в качестве формата кодирования одного объекта в одной строке, я ничего против не имею, но это не будет валидным xml документом.

66

Имел я ввиду следующее: я не вижу смысла тратить на это обсуждение шибко много сил, т.к. нет ни разработчика, ни четкого плана что надо сделать. Соответсвенно спор превращается в типичный холивар “хорош ли сферический xml в вакууме или не хорош”.

P.S. В вакууме xml великолепен.

67

Стой, но это на любом формате неудобно.

Вот тебе примеры вопросов, попробуй их хоть как-то объяснить себе:

  • Как JSON удобнее сортировать чем XML?
  • Как JSON удобнее мержить чем XML?

“неудобно” упирается в то что данные иерархичны/древовидны. Это для расширяемости и простоты БЕЗУМНЫХ тегов_через_подчёркивание тегов:через:двоеточие которых мы наплодили за всё это время пока сидели на “простых” key/value.

Ты в key костылишь XML/JSON структуры (иерархии) и говоришь что тебе просто их потом сортировать и мержить?

AddrN кто предлагал? Думаешь тебя строка=строка спасёт опять?

Не наглядно о каких “строках” речь. По мне, ты говоришь о “метаданных”. Замени “строка” на “псевдоXML” и всё будет то же самое.

Я (и никто) не требовал наличия одного корня у XML, я даже ЗА несколько корней у XML

Так ты и конкретизируй, что не так; а то говоришь о “сортировках”, “слияниях”, но примеры даже простецкие не приводишь.

Как JSON или OPL спасёт твою задницу? Мне со всеми мухами XML это просто непостижимо.

68

Вот дался тебе этот xml…
Просто json/xml ничью задницу не спасут.

Я про запись вида


<way geohash="asda" id="1" ><tags><tag k="foo" v="bar"/></tags><nodes>....</nodes><geometry>WKT</geometry></way>
<way geohash="asdb" id="2" ><tags><tag k="foo" v="bar"/></tags><nodes>....</nodes><geometry>WKT</geometry></way>
<way geohash="asdc" id="3" ><tags><tag k="foo" v="bar"/></tags><nodes>....</nodes><geometry>WKT</geometry></way>

Такой документ легко сортировать/фильтровать. Легко искать что-то в таком документе.

Например здания из такого документика можно отфильтровать банальным грепом. Причем учитывая что у нас тайлики, можно этот греп запустить в 200 потоков на 20 нодах. И результат потом можно аггрегирвать просто записав все в один файлик.

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

69

Я уж тогда сразу и freeExec добавлю про o5m.

В o5m строки записываются в табличку, последовательно, пока она не переполнится. Как только она переполнилась, из таблички выкидывается строка (или пара ключ значение - в контексте o5m это не принципиально, ключ-значение записываются в строку просто разделены \0 символом).

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

То что там есть секции, скажем так, я был очень воодушевлен прочитав про jump header и радостно потирал руки, что смогу прыгать между нодами, веями и релейшенами. Дак вот, osmconvert увы не пишет (год назад точно не писал) jump heder’ы для навигации между между разделами с разными типами объектов, увы.

70 

<way geohash="asda" id="1" ><tags><tag k="foo" v="bar"/></tags><nodes>....</nodes><geometry>WKT</geometry></way>
<way geohash="asdb" id="2" ><tags><tag k="foo" v="bar"/></tags><nodes>....</nodes><geometry>WKT</geometry></way>
<way geohash="asdc" id="3" ><tags><tag k="foo" v="bar"/></tags><nodes>....</nodes><geometry>WKT</geometry></way>

И где мухи-то в XML?

Чо тебе эта валидность сдалать? Про неё никто не вспоминал вроде.

Мешает ограничение “ток один корень” у XML значит не будем использовать.

Кому нужна валидность сделают:

<megavalidxml> >> hack.xml
OSMDB >> hack.xml
</megavalidxml> >> hack.xml

Исчерпаны твои высказывания/аргументы “XML - плохой формат, не используёте его”?

71

Никит, а ты внимательно читал то что я писал? И если внимательно, то с чем же из того что я написал ты споришь?
И зачем? Какую часть реализации ты хотел бы взять на себя?

72

Не спорит никто? От тебя пытаются выяснить что ты имел ввиду. Читал и тебя не понял не я один:

“сортировать” ты имел ввиду используя аж коммандную строку и пайпы а не любой язык программирования
“склеивать” ты имел ввиду используя аж коммандную строку и пайпы а не любой язык программирования

Надо было сказать “XML давайте без рута и сформатируем у XML первых сыновей в одну строку чтобы GREP-ать было без разбора XML”.

Я бы тебя сразу понял и не нужно было в дебри вести куда-то тему.

73

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

  1. У нас уже есть xml osm.xml, зачем делать новый может там чего-то не хватает
  2. XML формат общий и плохо работает для поиска и редактирования по строчно, потому что XML не подразумевает строчной структуры.
    Писать в одну строчку, что мы хотим в одну, моветон! Так делать нельзя.
  3. Мне действительно нравится OPL (как концепция), one object per line.
  4. Почему JSON? потому что json используется для коротких clob (text blob), которые можно записать в одну строку. Я абсолютно не писал, что json хорош, нет я просто предложил писать 1 json per line, так как это удобно и понятно, но сам файл абсолютно не является json. Json имеет библиотеки на всех ЯП, и зачастую распарсить из 1 line (1 string) json, гораздо проще чем xml.

P.S. Я не думаю, что прямо сейчас надо хвататься и писать некоторую имплементацию, в первую очередь надо подумать о применении. Во вторую очередь об API, чтобы даже если никто не договорится, будут точки соприкосновения. Пока что обсуждать osm.xml, osm.json, osm.opl - преждевременно, надо думать о применении и о возможных сложностях! Сложность парсить текстовый формат невелика, только если он не совсем страшный.

74
  1. а чем сейчас выгрузку делают? я уж забыл трекер
  2. в XML есть “строчная” структура https://en.wikipedia.org/wiki/CDATA или речь про такие строки строка? только 5 символов которые нужно кодировать в строках это большой плюс формата http://stackoverflow.com/questions/1091945/what-characters-do-i-need-to-escape-in-xml-documents
    можно! автоматическое форматирования/расформатирования xml это дело XML библиотек
  3. ничто не мешает применять её к ЛЮБОМУ текстовому/читаемому формату
  4. может быть в каких-то xml библиотеках CDATA криво реализован/недоступен через API? или речь про строка?

Да зачем вообще новый формат с нуля? Не исключено что сейчас что-нибудь допилим в старую выгрузку и будем как ключ использовать.

75

Хороший вопрос, не смотря на огромное количество текста, он по-прежнему валиден.

  1. Нам нужен древовидный формат quad-tree, чтобы быстро вырезать и составлять новую вырезку в домашних условиях
    Преимущества расписывать не буду, уже много писал. Нам действительно не нужен совсем новый формат, мы просто можем положить “структурированно” массив osm.xml файлов в zip. или osm.bz2, или .o5m (но ! есть пункт 2)
  2. Нам нужно развивать текстовый формат, а не бинарный. Потому что он понятен не “профессионалам” и позволяет использовать в “домашних” скриптах, читать и т.п. Текстовый файл не должен быть огромным 3-5МБ, в этом нам поможет структурированное дерево.
  3. Текстовые индексы. Текстовый формат хорошо, но если мы раскидали все файлы по тайлам, мы возвращаемся к проблеме как теперь искать во всех файлах. Это неудобно и небыстро. Но имея текстовый индекс, по типу как я прислал, можно искать гораздо-гораздо быстрее чем в 1-м файле. Можно делать руками, изучать taginfo и заметьте в домашних условиях, не имея никаких specially dedicated servers (taginfo, …). Текстовый индекс я не взял совсем из головы, такой используется и в бинарных форматах для POI Search and Address search, и я думаю он полезен для поиска информации или написании примитивного поиска.

Вот в принципе и все для 1-й фазы. Ее достаточно просто сделать, но 1) надо найти кому это может быть полезно, поспрашивать, прикинуть на себе и если это достаточно обоснованно. Начать рассуждать о следующих вопросах, как обновлять этот формат, как получать этот формат исходным образом (из pbf, из osm api ?) и т.д.

76

Для выступления на osm радио подготовлю тезисы

Видение нового формата

  1. Древовидная структура текстового формата
  • Предлагается использовать quad tree на основе папок и файлов
  • Позволит эффективно обновлять большой участок планеты за короткое время, ни один файловый формат сейчас этим свойством не обладает (файл заново пересоздается)
  • Возможность простыми способами скопировать некоторую область карты
  • Если формат текстовый, то можно применять достаточно много спобосов среди файлов, это ассортимент чуть уже, чем в случае одного большого текстового, но тоже внушителен
  • Разбиение по дереву дает возможность понять, какие объекты большие, а какие нет. Косвенно может улучшить картографирование генерализированных данных
  • Разбиение по дереву можно помочь в рендеринге coastline, здесь можно прописать является тайл полностью сушей или водой (помощь рендерингу)
  1. Текстовый индекс для поиска
  • Дешевая и простая замена online services (taginfo, поиск по тегам и поиск по имени)
  • При каждом файле можно создавать или поставлять, файлы соиндексы (пример приведен выше)
  • Помощь для поиска и возможность создавать прототипы за разумное время
  1. Геометрия точек vs геометрия объектов (упрощение рендеринга)
  • Проблема разреженных линий, когда точки не принадлежат bbox, а линия пересекает его
  • Указание принадлежности тайла некоторому “большому мультиполигону”, к примеру океан или область или что-то другое
  • Изменение node-id на геометрию (encode lat/lon by id)
    – позволяет решить проблему обновления (osc) без создания лишних индексов
    – при написании алгоритмов не нужно делать join way - node и хранить в памяти 30Гб nodes (для planet), что упрощает многие алгоритмы
  • way-id также имеет первую часть part of tile id, тем самым по id мы знаем какой квадрат необходимо обновить
  1. Простые (all existing tool compatible!) изменения osm.xml
  • - как единственный необходимый элемент (relation может существовать дополнительно, но необходимость неочевидна)
  • Замена равнозначна, так как исходя из текущего osm.xml можно сделать новый и наоборот, что позволяет сосуществовать с текущими tools
    Примеры:

  1. Один node

    <!-- id means location so we can convert it to lat=‘4.3’ lon=‘52.421’

  2. Один way




  3. Один relation который содержит только (!) way и node, к примеру, multipolygon, bus=route











  4. OSM Blockchain

  • Представить что OSM это не База Данных, а сеть, в которую постоянно передается новая информация на основе старой (как bitcoin)
  • Решить проблему увеличивающегося потока данных путем создания серверов ответственных только за некоторый регион
  • Избавить сеть от зависимости central api и дать возможность расширяться in distributed way
  • Решить проблему обновления формата и БД (больше нет api, есть только цепочка изменений), причем цепочки могут отличаться и osm blockchain может не совпадать с moscow-traffic-blockchain.
  • Добавить возможность верификации и сертификации, наподобие bitcoin blockchain voting к примеру.
  • Live updates для гораздо большего числа данных