У нас для всего есть тулы, но кто может вспомнить сколько мы ждали 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”.
Я бы тебя сразу понял и не нужно было в дебри вести куда-то тему.
Я думаю обсуждение формата XML немного за рамками, просто выскажусь почему он плох и не плох.
У нас уже есть xml osm.xml, зачем делать новый может там чего-то не хватает
XML формат общий и плохо работает для поиска и редактирования по строчно, потому что XML не подразумевает строчной структуры.
Писать в одну строчку, что мы хотим в одну, моветон! Так делать нельзя.
Мне действительно нравится OPL (как концепция), one object per line.
Почему 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 - преждевременно, надо думать о применении и о возможных сложностях! Сложность парсить текстовый формат невелика, только если он не совсем страшный.
Хороший вопрос, не смотря на огромное количество текста, он по-прежнему валиден.
Нам нужен древовидный формат quad-tree, чтобы быстро вырезать и составлять новую вырезку в домашних условиях
Преимущества расписывать не буду, уже много писал. Нам действительно не нужен совсем новый формат, мы просто можем положить “структурированно” массив osm.xml файлов в zip. или osm.bz2, или .o5m (но ! есть пункт 2)
Нам нужно развивать текстовый формат, а не бинарный. Потому что он понятен не “профессионалам” и позволяет использовать в “домашних” скриптах, читать и т.п. Текстовый файл не должен быть огромным 3-5МБ, в этом нам поможет структурированное дерево.
Текстовые индексы. Текстовый формат хорошо, но если мы раскидали все файлы по тайлам, мы возвращаемся к проблеме как теперь искать во всех файлах. Это неудобно и небыстро. Но имея текстовый индекс, по типу как я прислал, можно искать гораздо-гораздо быстрее чем в 1-м файле. Можно делать руками, изучать taginfo и заметьте в домашних условиях, не имея никаких specially dedicated servers (taginfo, …). Текстовый индекс я не взял совсем из головы, такой используется и в бинарных форматах для POI Search and Address search, и я думаю он полезен для поиска информации или написании примитивного поиска.
Вот в принципе и все для 1-й фазы. Ее достаточно просто сделать, но 1) надо найти кому это может быть полезно, поспрашивать, прикинуть на себе и если это достаточно обоснованно. Начать рассуждать о следующих вопросах, как обновлять этот формат, как получать этот формат исходным образом (из pbf, из osm api ?) и т.д.
Предлагается использовать quad tree на основе папок и файлов
Позволит эффективно обновлять большой участок планеты за короткое время, ни один файловый формат сейчас этим свойством не обладает (файл заново пересоздается)
Возможность простыми способами скопировать некоторую область карты
Если формат текстовый, то можно применять достаточно много спобосов среди файлов, это ассортимент чуть уже, чем в случае одного большого текстового, но тоже внушителен
Разбиение по дереву дает возможность понять, какие объекты большие, а какие нет. Косвенно может улучшить картографирование генерализированных данных
Разбиение по дереву можно помочь в рендеринге coastline, здесь можно прописать является тайл полностью сушей или водой (помощь рендерингу)
Текстовый индекс для поиска
Дешевая и простая замена online services (taginfo, поиск по тегам и поиск по имени)
При каждом файле можно создавать или поставлять, файлы соиндексы (пример приведен выше)
Помощь для поиска и возможность создавать прототипы за разумное время
Геометрия точек vs геометрия объектов (упрощение рендеринга)
Проблема разреженных линий, когда точки не принадлежат bbox, а линия пересекает его
Указание принадлежности тайла некоторому “большому мультиполигону”, к примеру океан или область или что-то другое
Изменение node-id на геометрию (encode lat/lon by id)
– позволяет решить проблему обновления (osc) без создания лишних индексов
– при написании алгоритмов не нужно делать join way - node и хранить в памяти 30Гб nodes (для planet), что упрощает многие алгоритмы
way-id также имеет первую часть part of tile id, тем самым по id мы знаем какой квадрат необходимо обновить
Простые (all existing tool compatible!) изменения osm.xml
- как единственный необходимый элемент (relation может существовать дополнительно, но необходимость неочевидна)
Замена равнозначна, так как исходя из текущего osm.xml можно сделать новый и наоборот, что позволяет сосуществовать с текущими tools
Примеры:
Один node
<!-- id means location so we can convert it to lat=‘4.3’ lon=‘52.421’
Один way
Один relation который содержит только (!) way и node, к примеру, multipolygon, bus=route
OSM Blockchain
Представить что OSM это не База Данных, а сеть, в которую постоянно передается новая информация на основе старой (как bitcoin)
Решить проблему увеличивающегося потока данных путем создания серверов ответственных только за некоторый регион
Избавить сеть от зависимости central api и дать возможность расширяться in distributed way
Решить проблему обновления формата и БД (больше нет api, есть только цепочка изменений), причем цепочки могут отличаться и osm blockchain может не совпадать с moscow-traffic-blockchain.
Добавить возможность верификации и сертификации, наподобие bitcoin blockchain voting к примеру.
