Xml (если генерить 1 большой документ) плох тем что его неудобно склеивать, неудобно сортировать объекты внутри файла.
xpath на документах нашего размера начинает очень натужно работать.
Да OPL только я не понимаю зачем выдумывать свой формат для записи объекта в строке, завернуть его в json (ну или в xml, только не генерить 1 огромный документ а в каждой строке держать 1 объектик заэнкоженый в xml). Это не столь уж и важно (для меня) json или xml. Но лучше что-то стандартное. Чтоб свой не писать свои граматики и парсер.
Если геометрия уже построена, то все админ. границы и/или все коастлайны фильтруются из планеты в один проход.
Тут явно не упомянули (вернее, не повторили с открывающего поста), но разбивка на тайлы полезна тем, что результат можно обрабатывать многопоточно.
Проблема с XML в том, что это большая стена текста, которую медленно обрабатываться просто из-за ограничений по i/o. В сравнении с бинарными форматами — на порядок (в ~10 раз) медленнее.
Ну можно геометрию как hex WKTB записывать чтоб поменьше места занимала. Если текст выровнен по страничкам и можно его просто в память мапить кусками то работает это оч. быстро.
o5m я кстати предлагал сделать блочным, чтоб ожно было грузить его страничками. Но при маленькой страничке, мы не шибко то и выйграем, т.к. основная эконоия у o5m имхо за счет “таблички” строк.
У нас для всего есть тулы, но кто может вспомнить сколько мы ждали overpass (3 года?), сколько мы мучались с taginfo, что нельзя было найти, где же находится этот тег с багом.
OPL как формат мне нравится больше JSON, но опять же у индекса нет задачи показывать все объекты и геометрию, это всего лишь индекс для поиска (help формат). Поэтому это не замена индекс-файлу. Заменять osm.xml на opl, идея хорошая, но может не такая необходимая.
Разбивка по тайлам, построение индекса, агреггация индекса для супертайла только из индексов подтайлов, может за разумное время дать текстовый индекс для большой страны, если имеются индексы на самих тайлах. Для меня выглядит поважнее.
Насчет индекс-файла, это всего лишь представление, если он подходит под некоторые задачи это замечательно, если нет можно добавить или сделать другой индекс файл, но не убавить - нет смысла, пусть будет
Откуда этот посыл взялся? Я как раз везде пытаюсь писать, что все файлы должны быть маленькие не больше 3-5 МБ, чтобы удобно открывать и обрабатывать было! Как добиться большего объема, точно так же как мы делаем для тайлов, раскладывая по папки. Если файл маленький то принципиально нет разницы, что там и даже чем обрабатывать (XML, JSON, OPL). Текстовые файлы для чтения людьми, поэтому важно, чтобы читалось удобно.
Предлагаю начать с XML потому что CSS мы всё-таки используем во многих OSM-проектах, да и разработчика с хабра проще подружить с XML чем OPL. Это не значит что JSON или OPL плохие, но не в первую очередь.
Я не собираюсь спорить о преимуществах и недостатках xml. Но и тому кто за это возьмется (кандидатур то у нас, как я посмотрю очередь стоит) xml бы не посоветовал.
И теперь все должны угадывать что же ты имел ввиду.
Ну так почему ты скажи?
Читаемость? Все вроде за это.
Популярность (простота освоения) среди разработчиков и готовые инструменты (целые IDE) для него?
Два десятка лет разработок и тестирования инструментов и инфраструктуры вокруг xml?
stackoverflow с тысячей ответов “как сделать это” на xml?
по гуглению “xml limitations” нашёл:
Length of XML 2,147,483,647 characters - нам это не грозит для тайлов на низших уровнях
Дак я сказал, сортировать - неудобно, мержить - неудобно.
Как формат для кодирования объекта в рамках одной строки - можно и xml и json и OPL здесь я не вижу принципиальной разницы.
А то что чудес для xml в мире - как мух в сортире, дак это я знаю. Если у тебя 1 объект - 1 строка, при грамотной записи, ты можешь сортировать и фильтровать файлики (по некоторому ограниченному набору параметров) без парсинга, просто как строки.
Я еще разок повторюсь, что в качестве формата кодирования одного объекта в одной строке, я ничего против не имею, но это не будет валидным xml документом.
Имел я ввиду следующее: я не вижу смысла тратить на это обсуждение шибко много сил, т.к. нет ни разработчика, ни четкого плана что надо сделать. Соответсвенно спор превращается в типичный холивар “хорош ли сферический xml в вакууме или не хорош”.
Вот тебе примеры вопросов, попробуй их хоть как-то объяснить себе:
Как JSON удобнее сортировать чем XML?
Как JSON удобнее мержить чем XML?
“неудобно” упирается в то что данные иерархичны/древовидны. Это для расширяемости и простоты БЕЗУМНЫХ тегов_через_подчёркивание тегов:через:двоеточие которых мы наплодили за всё это время пока сидели на “простых” key/value.
Ты в key костылишь XML/JSON структуры (иерархии) и говоришь что тебе просто их потом сортировать и мержить?
AddrN кто предлагал? Думаешь тебя строка=строка спасёт опять?
Не наглядно о каких “строках” речь. По мне, ты говоришь о “метаданных”. Замени “строка” на “псевдоXML” и всё будет то же самое.
Я (и никто) не требовал наличия одного корня у XML, я даже ЗА несколько корней у XML
Так ты и конкретизируй, что не так; а то говоришь о “сортировках”, “слияниях”, но примеры даже простецкие не приводишь.
Как JSON или OPL спасёт твою задницу? Мне со всеми мухами XML это просто непостижимо.
Такой документ легко сортировать/фильтровать. Легко искать что-то в таком документе.
Например здания из такого документика можно отфильтровать банальным грепом. Причем учитывая что у нас тайлики, можно этот греп запустить в 200 потоков на 20 нодах. И результат потом можно аггрегирвать просто записав все в один файлик.
Можно просто дописать в конец. Легко пайпать и т.д. но он не является валиднам xml документом (нет рут элемента). Соответсвенно как вариант записи одного объекта, ничего не имею против. А вот превращать файлики с набром данных в валидные xml документы - я бы сам уже не стал и другим бы не стал советовать. (Впрочем советами можно принебречь).
В o5m строки записываются в табличку, последовательно, пока она не переполнится. Как только она переполнилась, из таблички выкидывается строка (или пара ключ значение - в контексте o5m это не принципиально, ключ-значение записываются в строку просто разделены \0 символом).
Это усложняет сортировку и фильтрацию.
Я не могу прочитать произвольную строку, я не могу переставить объекты местами, не могу выкинуть часть тегов. Мне надо прочитать всю секцию (да можно пропустить геометрию но теги я буду обязан прочитать) и потом записать измененный вариант.
То что там есть секции, скажем так, я был очень воодушевлен прочитав про jump header и радостно потирал руки, что смогу прыгать между нодами, веями и релейшенами. Дак вот, osmconvert увы не пишет (год назад точно не писал) jump heder’ы для навигации между между разделами с разными типами объектов, увы.
Никит, а ты внимательно читал то что я писал? И если внимательно, то с чем же из того что я написал ты споришь?
И зачем? Какую часть реализации ты хотел бы взять на себя?
Не спорит никто? От тебя пытаются выяснить что ты имел ввиду. Читал и тебя не понял не я один:
“сортировать” ты имел ввиду используя аж коммандную строку и пайпы а не любой язык программирования
“склеивать” ты имел ввиду используя аж коммандную строку и пайпы а не любой язык программирования
Надо было сказать “XML давайте без рута и сформатируем у XML первых сыновей в одну строку чтобы GREP-ать было без разбора XML”.
Я бы тебя сразу понял и не нужно было в дебри вести куда-то тему.
