Мммм, тогда давай. Только форматец попроще вроде JSON могешь? Как доколдую мониторинг займусь импортом тегов, чтобы осталось по категориям распихать и описания сделать.
Дофоркаются, конечно. Но кому это мешает? Кому какая-разница что там у какого-то user-а в тегсетах, если он не портит официальный.
Зато из форков можно вынести пользу. Например открываем /Shop/Clothes, делаем поиск “как там у других” и видим грубо говоря три столбика:
официальный вариант для этого пресета,
потом наш,
а потом самые популярные изменения: 120 человек добавили brand в свой /Shop/Clothes, ещё 100 добавили age, ещё 10 добавили новый тип одежды “валенки”. И на каждое новшество кнопки “утянуть себе”.
Таким образом из облака форков можно вытянуть самые популярные новшества в свои пресеты. А те, кто рулит официальным пресетом, могут просто просматривать самые популярные изменения. Например, если изменение набирает 100 и больше редакторов, то автоматически идёт pull request
Точно такая же идеология у JOSM-а. Исходники открыты, а на пресеты даже исходники не нужны. XML файл - надо просто залезть и поправить, а потом отправить изменения тем кто поддерживает. Однако, отстаёт на год.
Если не нравится гитхаб-лайк, значит не нравится. Не настаиваю на своей идее, всё таки сам я пока не готов помочь, а настаивать на своей точке зрения, если сам не буду помогать, считаю неправильным. Пусть это были мысли вслух, а проекту помогу чем смогу и когда смогу %)
Другие реализации и вправду лучше обсуждать в отдельной теме. Эта про TOSM.
По теме: GaM, если хочешь машиночитаемости, формализуй, к чему можно применять значение.
value я бы сунул в values, а в value описание значения на разных языках. Ну и к чему применяется. Сразу на будущее - node / line / area / relation. При этом в условиях API 0.6 подразумевается, что line разрешает ставить на вей, area разрешает вей и мультиполигон.
XML не нужен.
Hind, а какой формат предлагаешь? Я сам от xml тошнюсь, но как понимаю это более менее будет понятней нашему софту. Я люблю простой json, всегда и везде
Про типы тегов спасибо, надо видимо true/false сделать на все 4 типа.
Я так и подумал что сначала идёт коллекция категорий с вложенностью, а потом объекты. Ну и уже софтина или берёт нужную себе категорию или обрабатывает все, её дело.
upd: действительно… лучше описать значения тега все в одном контексте, чем кучу плодить. спасибо за идею!
Я что-то подобное делал для себя в прошлом году. По России и окрестностям насчитал 276 описанных в вики или документации ключей и 1023 уникальные комбинации ключ/тег. Списко далеко не поплон! Потом забил так как значений огромное количество а фактических объектов - мизер.
При этом не забываем про теги типа source:addr или official_name:be
И что в словах Hind`a убирает человеко-читаемость? note и description никуда не исчезнут, а языки я думаю это просто надо файл типа tosm-ru.json, tosm-en.json и т.п. Правда донести до англоязычного сообщества это не так просто будет, потому надо хотя бы для себя сделать для начала.
Только json для человекочитаемости должен быть с индентами, как через бьютифаер выгнан :3
И с комментариями в начале по синтаксису.
Что касается отдельных файлов для языков. Есть нюанс, в нескольких файлах немножко сложнее валидировать, например, полноту перевода. Требуется либо эталонный файл, либо синтез словаря в памяти с пробегом по файлам и проверкой наличия описанных тего/значений.
Может ты не совсем уловил, всю инфу я храню в обычном mysql, а потом оно выгружается в ацкие файлики которые не должны быть понятны человеку, они должны быть понятны для программы, так чтобы человек смог найти тег и понятное описание на нужном языке уже внутри программы, сами файлы делать читаемыми для людей это ВАХ