По тегу находится в каких subtiles оно лежит, затем можно зайти в “папку 4”, открыть osm.xml и найти его. Сами конечные тайлы достаточно маленькие, чтобы их можно открыть в текстовом редакторе и найти объект. Это древовидный индекс + немного статистики.
Я не понимаю, зачем возможность ручного поиска. Какие задачи она решает? Кто в своём уме руками будет высматривать все highway=level_crossing на планете? Или запоминать координаты bbox для ограничения запроса?
И если ограничиваться тайлами, то либо они будут конского размера (несколько мегабайт) и включать в себя половину тегов из индекса каждый (кроме океанов), либо они будут сильно мелкие, что приведёт к дубликации данных и к конского размера спискам субтайлов в индексе.
Я бы взял за основу тайлы o5m с внутренней разбивкой на подтайлы и ссылками внутри файла.
Индекс по тегам - тупо не нужен.
Выборку по редкому тегу можно получить из того-же оверпаса, для частой комбинации - всеравно придется пробежать все тайлы из набора.
Вообще, если геометрия уже построена, то фильтрация по тегам делается в 1 проход и без использования большого числа оперативки. А вот выгрузок с собранными линиями (полигонами, мультиполигонами и т.д.) - нет.
А текстовые форматы - это удобно, хош сортируй, хош грепай, хош - конкатенируй.
Только вместо JSON - XML. Потому что не хочется CSS переписывать на выборки из этого json.
Либо у нас так много пользователей json? Откуда он прёт, какой смысл есть за ним?
Думаю, нужен, но не по всем. Проблема оверпасса в том, что он не работает в офлайне, сложно настраивается, требует адского количества ресурсов при установке, и ненадёжен. А здесь мы просто берём файл и обрабатываем. У меня, например, частая задача — выделить из планеты костлайны или адм. границы.
Тогда, может, на OPL обратить внимание? Правда, они, пока что, write-only для программ.
Xml (если генерить 1 большой документ) плох тем что его неудобно склеивать, неудобно сортировать объекты внутри файла.
xpath на документах нашего размера начинает очень натужно работать.
Да OPL только я не понимаю зачем выдумывать свой формат для записи объекта в строке, завернуть его в json (ну или в xml, только не генерить 1 огромный документ а в каждой строке держать 1 объектик заэнкоженый в xml). Это не столь уж и важно (для меня) json или xml. Но лучше что-то стандартное. Чтоб свой не писать свои граматики и парсер.
Если геометрия уже построена, то все админ. границы и/или все коастлайны фильтруются из планеты в один проход.
Вообще можно это в мамбле обсудить, только чур не в 23мск.
Тут явно не упомянули (вернее, не повторили с открывающего поста), но разбивка на тайлы полезна тем, что результат можно обрабатывать многопоточно.
Проблема с XML в том, что это большая стена текста, которую медленно обрабатываться просто из-за ограничений по i/o. В сравнении с бинарными форматами — на порядок (в ~10 раз) медленнее.
Ну можно геометрию как hex WKTB записывать чтоб поменьше места занимала. Если текст выровнен по страничкам и можно его просто в память мапить кусками то работает это оч. быстро.
o5m я кстати предлагал сделать блочным, чтоб ожно было грузить его страничками. Но при маленькой страничке, мы не шибко то и выйграем, т.к. основная эконоия у o5m имхо за счет “таблички” строк.
У нас для всего есть тулы, но кто может вспомнить сколько мы ждали overpass (3 года?), сколько мы мучались с taginfo, что нельзя было найти, где же находится этот тег с багом.
OPL как формат мне нравится больше JSON, но опять же у индекса нет задачи показывать все объекты и геометрию, это всего лишь индекс для поиска (help формат). Поэтому это не замена индекс-файлу. Заменять osm.xml на opl, идея хорошая, но может не такая необходимая.
Разбивка по тайлам, построение индекса, агреггация индекса для супертайла только из индексов подтайлов, может за разумное время дать текстовый индекс для большой страны, если имеются индексы на самих тайлах. Для меня выглядит поважнее.
Насчет индекс-файла, это всего лишь представление, если он подходит под некоторые задачи это замечательно, если нет можно добавить или сделать другой индекс файл, но не убавить - нет смысла, пусть будет 
Откуда этот посыл взялся? Я как раз везде пытаюсь писать, что все файлы должны быть маленькие не больше 3-5 МБ, чтобы удобно открывать и обрабатывать было! Как добиться большего объема, точно так же как мы делаем для тайлов, раскладывая по папки. Если файл маленький то принципиально нет разницы, что там и даже чем обрабатывать (XML, JSON, OPL). Текстовые файлы для чтения людьми, поэтому важно, чтобы читалось удобно.
Не по хорошему мил, а по милому хорош.
Кто будет делать, тот и выберет формат.
Вообще в o5m есть и ресеты и прямые ссылки где начинается точки, линии, отношения. Т.е. сделать страницы по 64к вообще не проблема.
Аккуратнее с заявлениями про нерабочесть xpath/css
мы же генирить их (txt/xml) хотим на каждый тайл
- мы используем тайлы
- xpath ломается одинаково по скорости с sed
https://en.wikipedia.org/wiki/XPath#Implementations - здесь далеко не все. И не все они “тупые” парсилки DOM
Предлагаю начать с XML потому что CSS мы всё-таки используем во многих OSM-проектах, да и разработчика с хабра проще подружить с XML чем OPL. Это не значит что JSON или OPL плохие, но не в первую очередь.
Скажем так, есть зарезервированные для этого дела типы данных. Но самих ссылок нет.
Я не собираюсь спорить о преимуществах и недостатках xml. Но и тому кто за это возьмется (кандидатур то у нас, как я посмотрю очередь стоит) xml бы не посоветовал.
И теперь все должны угадывать что же ты имел ввиду.
Ну так почему ты скажи?
Читаемость? Все вроде за это.
Популярность (простота освоения) среди разработчиков и готовые инструменты (целые 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/
Дак я сказал, сортировать - неудобно, мержить - неудобно.
Как формат для кодирования объекта в рамках одной строки - можно и xml и json и OPL здесь я не вижу принципиальной разницы.
А то что чудес для xml в мире - как мух в сортире, дак это я знаю. Если у тебя 1 объект - 1 строка, при грамотной записи, ты можешь сортировать и фильтровать файлики (по некоторому ограниченному набору параметров) без парсинга, просто как строки.
Я еще разок повторюсь, что в качестве формата кодирования одного объекта в одной строке, я ничего против не имею, но это не будет валидным xml документом.
Имел я ввиду следующее: я не вижу смысла тратить на это обсуждение шибко много сил, т.к. нет ни разработчика, ни четкого плана что надо сделать. Соответсвенно спор превращается в типичный холивар “хорош ли сферический xml в вакууме или не хорош”.
P.S. В вакууме xml великолепен.
Стой, но это на любом формате неудобно.
Вот тебе примеры вопросов, попробуй их хоть как-то объяснить себе:
- Как JSON удобнее сортировать чем XML?
- Как JSON удобнее мержить чем XML?
“неудобно” упирается в то что данные иерархичны/древовидны. Это для расширяемости и простоты БЕЗУМНЫХ тегов_через_подчёркивание тегов:через:двоеточие которых мы наплодили за всё это время пока сидели на “простых” key/value.
Ты в key костылишь XML/JSON структуры (иерархии) и говоришь что тебе просто их потом сортировать и мержить?
AddrN кто предлагал? Думаешь тебя строка=строка спасёт опять?
Не наглядно о каких “строках” речь. По мне, ты говоришь о “метаданных”. Замени “строка” на “псевдоXML” и всё будет то же самое.
Я (и никто) не требовал наличия одного корня у XML, я даже ЗА несколько корней у XML
Так ты и конкретизируй, что не так; а то говоришь о “сортировках”, “слияниях”, но примеры даже простецкие не приводишь.
Как JSON или OPL спасёт твою задницу? Мне со всеми мухами XML это просто непостижимо.