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

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

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

Может тогда сделать несколько веток? Одна - то что уже принято. Вторая - то что используется, но пока еще в 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
И с комментариями в начале по синтаксису.

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

Может ты не совсем уловил, всю инфу я храню в обычном mysql, а потом оно выгружается в ацкие файлики которые не должны быть понятны человеку, они должны быть понятны для программы, так чтобы человек смог найти тег и понятное описание на нужном языке уже внутри программы, сами файлы делать читаемыми для людей это ВАХ :slight_smile:

А, ну тогда совсем просто, конечно.
Генерить его раз в 5 минут, и все дела.

А поддержку для JOSM кот-нибудь напишет.

Кстати, надо что-то делать с иконами же?

Ну иконы я не думал вообще что нужны, нафиг? В разных прогах они разные или ты и их предлагаешь впихнуть? Но это сильно увеличивает объем работы для рисовальщиков, я то не фафа с “кистями” :slight_smile: Тогда или надо прилагать айкон-пак рядом или прямо в файл в base64 писать в свойстве icon.

Меня просто коробит мысль, что у редактора будет своя таблица тегов, хоть даже и для иконок :3

тогда я вас тоже не правильно понял)) Обычно человекочитаемостью именно про файлы говорят))

В целом прикрутить сюда ещё и иконки это мелочь, но иконка какая? Для программы редактора соотвественно? Ибо рэндэры у нас сами фантазируют на тему иконок, просто надо выбрать ориентацию и найдя бригаду десингеров закрыть их в сыром подвале до тех пор пока все теги не отрисуют :slight_smile:

Кстати а какие иконки для полигонов и линий? оО Мы ещё и стиль должны что ли описать? А полигону заливку? оО Ахтунг какой-то))) Но вполне осуществимо, конечно.

Погнали от примеров:

Речка:
На линии - это waterway=river + опциональные tidial=yes/no, name, gvr
На полигоне - это либо waterway=riverbank (deprecated) либо natural=water + water=river ну и те же опциональные

По идее еще name у полигона и линии должны совпадать, но это на следующую итерацию.

Потом нужны ref элементам чтобы собирать такие штуки в иерархии. Т.е. чтобы можно было определить что building=appartments это наследник building=yes ну плюс прелести ооп: т.е. по умолчанию building=appartments наследует атрибуты building=yes + возможно имеет свои (число квартир для примера) ну и нужна возможность указать что часть атрибутов не наследуется, т.к. наследники иногда просто соответсвуют одному из значений уточняющего атрибута родителя, или просто часть опциональных родительских атрибутов родителя для наследника принимают одно значение.

Т.е. нужны

  • обязательность/опциональность тегов
  • комбинации тегов
  • наследуемость типов
  • устаревшее
  • зависимость от того к чему (полигон точка и т.д. применяется) заготовка

Последнее в принципе есть.

А ещё пресеты! Это уже интереснее, формы для ввода параметров здания и т.п. Тут-то и пригодится наследуемость, которой сейчас в осме нет и о которой я уже писал. Но не могу найти пост. :frowning:

Написал простынку, но вынес в отдельную тему.