Машиночитаемый справочник тегов для программ [TOSM]

С нуля не надо, можно импортировать пресеты с JOSM-а.

Обновлять будет мешать примерно то же, что сейчас мешает редакторам JOSM-а держать свои официальные пресеты в самом актуальном и полном состоянии, так сказать bleeding edge.

Потому что суть та же: изменения нужны одним, а делать должны другие, у которых семья, работа, дети, другие увлечения, кино, да и то, что просят добавить, нужно всего 10 человекам где-то в Зимбабве.

А разрешить всем править официальный источник, это уже точно бардак, споры, удаления.

Это не ИСПОЛЬЗУЕМЫЕ, это ИЗ ВИКИ выгрузка.

Мммм, тогда давай. Только форматец попроще вроде JSON могешь? Как доколдую мониторинг займусь импортом тегов, чтобы осталось по категориям распихать и описания сделать.

Вы их давно открывали? Там теги устарели на год так точно многие. Ещё теги с потлача предлагайте)))

Дофоркаются, конечно. Но кому это мешает? Кому какая-разница что там у какого-то user-а в тегсетах, если он не портит официальный.

Зато из форков можно вынести пользу. Например открываем /Shop/Clothes, делаем поиск “как там у других” и видим грубо говоря три столбика:

  • официальный вариант для этого пресета,
  • потом наш,
  • а потом самые популярные изменения: 120 человек добавили brand в свой /Shop/Clothes, ещё 100 добавили age, ещё 10 добавили новый тип одежды “валенки”. И на каждое новшество кнопки “утянуть себе”.

Таким образом из облака форков можно вытянуть самые популярные новшества в свои пресеты. А те, кто рулит официальным пресетом, могут просто просматривать самые популярные изменения. Например, если изменение набирает 100 и больше редакторов, то автоматически идёт pull request :slight_smile:

Хз, правда, как это реализовать.

xml файл - править просто. И стоит использовать уже имеищися опыт - того же линукса. Что-то нужно - сделай сам и пришли тем кто поддерживает.

Не стоит автоматически делать pull request, если сотня потлачеров, что-то сделала, то это не означает, что это правильно.

Формат могу примерно любой, только зачем там json? Там же пара - key-value. Проще в CSV выгрузить.

Давай CSV, ещё проще. Мне главное всосать это средствами php :slight_smile: Не более)))

Точно такая же идеология у JOSM-а. Исходники открыты, а на пресеты даже исходники не нужны. XML файл - надо просто залезть и поправить, а потом отправить изменения тем кто поддерживает. Однако, отстаёт на год.

Pull request, это не merge. Можно и отклонить.

Я не буду спорить дальше.

Если не нравится гитхаб-лайк, значит не нравится. Не настаиваю на своей идее, всё таки сам я пока не готов помочь, а настаивать на своей точке зрения, если сам не буду помогать, считаю неправильным. Пусть это были мысли вслух, а проекту помогу чем смогу и когда смогу %)

Может тогда сделать несколько веток? Одна - то что уже принято. Вторая - то что используется, но пока еще в proposal.

А кому не нарвится github -лайк? Мне нравится.

Да харош флудить!

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

Наоборот. Никто же не мешает сделать и так и так. Пусть и не вами. Интересно же узнать что по этому поводу думают.

Другие реализации и вправду лучше обсуждать в отдельной теме. Эта про TOSM.

По теме: GaM, если хочешь машиночитаемости, формализуй, к чему можно применять значение.
value я бы сунул в values, а в value описание значения на разных языках. Ну и к чему применяется. Сразу на будущее - node / line / area / relation. При этом в условиях API 0.6 подразумевается, что line разрешает ставить на вей, area разрешает вей и мультиполигон.
XML не нужен.

Гхм, говоря “XML” и “допустимые тэги” подразумеваем DTD или XSD (XML Schema) и валидатор… Нет?

Hind, а какой формат предлагаешь? Я сам от xml тошнюсь, но как понимаю это более менее будет понятней нашему софту. Я люблю простой json, всегда и везде :slight_smile:

Про типы тегов спасибо, надо видимо true/false сделать на все 4 типа.

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

upd: действительно… лучше описать значения тега все в одном контексте, чем кучу плодить. спасибо за идею!

Я что-то подобное делал для себя в прошлом году. По России и окрестностям насчитал 276 описанных в вики или документации ключей и 1023 уникальные комбинации ключ/тег. Списко далеко не поплон! Потом забил так как значений огромное количество а фактических объектов - мизер.

При этом не забываем про теги типа source:addr или official_name:be

В первичной постановке вопроса задача была сделать не только машиночитаемый но и человеко-читаемый.

И что в словах Hind`a убирает человеко-читаемость? note и description никуда не исчезнут, а языки я думаю это просто надо файл типа tosm-ru.json, tosm-en.json и т.п. :slight_smile: Правда донести до англоязычного сообщества это не так просто будет, потому надо хотя бы для себя сделать для начала.

Только json для человекочитаемости должен быть с индентами, как через бьютифаер выгнан :3
И с комментариями в начале по синтаксису.

Что касается отдельных файлов для языков. Есть нюанс, в нескольких файлах немножко сложнее валидировать, например, полноту перевода. Требуется либо эталонный файл, либо синтез словаря в памяти с пробегом по файлам и проверкой наличия описанных тего/значений.