Нам нужны вообще ; в значениях для России? Запретим их?

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

Данные можно отдавать алгоритмам. Людьми свет не закончился.

Не хочешь дружить данные с внешними API и подавать их в съедобном для всех алгоритмов виде - никто их есть не будет.

addr:flats=“1-20”

Это только строка. То, что у тебя есть знания чтобы написать для неё парсер ничего не упрощает для потребителей данных.

  • им всё равно приходится угадывать что это множество, а не одна квартира “1/20”
  • им всё равно приходится делать это всё для всей базы, а не только там где ; реально есть

Если ты

то зачем эта

когда можно уже допилить API до нормальных таксономий и множеств? (сюрприз! для этого нужно только лишь разрешить пользовательский XML чтение-запись на начальном этапе)

Зачем ты мне тыкаешь в теги викимапии? Они плоские как доска. Они не значат ничего. Там даже на leisure=/shop= теги не выделяют.

О сколько нам открытий чудных…

То что вы великий практик в программировании мы уже поняли, до сих пор круги в глазах, от сияния чистого разума. Но если вы и с блондинками имели опыт общения на тему валидации геометрии - тогда… просто нет слов.

Тебя что-то кидает из крайности в крайность.
то
key:value=yes
то
key=[a,b,c]
то
json
то
xml

Но ладно, это лирика, кто делать то будет? Ленивое, косное, надменное англокомьюнити?

Нет. Великие, Имперские Программисты на Плечах Которых Держится Целое Отечество.

Дать любому пользователю сохранить и считать любой xml для геометрии из OSM это так сложно. Потребуются несколько съездов EWG и разработка спецификации, тестирование и внедрение.

Но самое страшное! В этот XML кто-то может внести ложь. О ужас!

Конкретна эта тема в которой мы сидим про этот костыль в рамках API 0.6, да. Но теперь я знаю куда его спрятать: в пользовательский XML.

Про это уже во всю говорят в отдельной теме.

Это форматы ответа API. Ты не знал что overpass умеет выдавать CSV?! Сумасшедшие! В бан их! У нас геопространственная база, а не викимапия какая-нибудь.

Я устыжен, я был против запрета ‘;’ и тем коварно хотел всех забанить. Мой план раскрыт, остается только бежать. Вы дадите мне Парабеллум?

В отдельной теме уже много чего предложили. Есть очень серьезные у меня сомнения что это будет реализовано.

Нет. И теперь вас ждёт самый прискорбный исход.

Ну и поделитесь почему нет?

Как параллельный API, для тех, кому жмут теги OSM - почему нет?
Как основной API - нужно будет подождать пока поддержка будет у всего, да потребует времени потому что это изменение, а не плохой подход.

d1g
Ну дык начните вы уж наконец с самого простого — написания полноценной спецификации на ваши хотелки. (и нет, форумные посты за спеки не считаются) Можете пока даже не продумывать миграцию с существующих данных, просто опишите своё виденье сферически вакуумной системы, начиная от точек с БД и заканчивая высокоуровневыми API, валидацией и XSD. Но при этом держите в голове не только пользователей данных, программистов и опытных маперов, но и условных домохозяек и блондинок, которые заносят в базу весомую долю данных, ибо для них нужно будет создавать удобные и понятные инструменты. Пока же вы только разводите трёп, в котором полезного содержания кот наплакал.

Никто за вас спецификации писать не будет, РЛ так не бывает, что приходит гений чистого разума, говорит “хочу вот так”, а сообщество в ответ создаёт на блюдечке с голубой каёмочкой и спеки, и код. Даже после написания спек и длительного обсуждения (в т.ч. и с “англоязычными снобами”), вам (да-да, лично вам, а не мифическим “имперским программистам”), скорее-всего придётся написать хотя бы демку proof-of-concept. В общем, doitcracy в чистом виде.

Иначе, вас весьма скоро начнут просто игнорировать, и не говорите потом про костных и несговорчивых руосмеров.

P.S.: Идея — ничто, реализация — всё.

Потому что гора рожает мышь. Предлагаются очень серьезные изменения ради решения очень узкого круга задач.

Напишите на osm-dev, появится какое-то представление о том, будет ли это поддержанно в апи, и если будет то когда.

И вот отмечая их мы получаем викимапию в чистом виде! Только сегодня отметил два shop=doityourself которые имеют совершенно разные ассортименты, которые понять можно только прочитав название.

Вот и получаете викимапию в чистом виде в OSM.

Вместо новых тегов и старых, более общих пытаетесь уместить два разных смысла под одним тегом shop=doityourself.

Не удивительно что различать отличия после этого можно только по названиям.

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

Я не понимаю, что вы хотите получить и как. Двух совершенно одинаковых объектов не бывает. Всегда есть какие-то различия.

Например, не бывает двух магазинов с совершенно одинаковым ассортиментом.

Кто и как должен кодифицировать ассортименты (и главное зачем) я тоже не понимаю.

Им не нужна, вам нужна. Даже если это прямо сегодня не будет использоваться прямо сейчас, вам запретить теги никто не даст.

Отфильтровывать на уровне меток.

Кто запрещал что можно отмечать “разделка свинины” “разделка рыбы” у мясника?

Никакого круга нет, просто не обращайте внимание на аргументы “такая детализация не нужна”. Если ваши теги может другой человек использовать, то почему нет? Для какой-то цели при поиске их можно использовать? Значит вперёд.

Вот и не стоит их пытаться увязать на такие общие теги “shop”. У одного магазина будут одни теги-услуг, у другого-другие.

Пытаться это вместить в только в один shop= только потому что это рендерится по-умолчанию или обрабатывается по умолчанию где-то это абсурд. Те кто хотят обработки по умолчанию пусть указывают shop=yes или другой тег на выбор.

“Смыслы” и “ассортименты” могут трактоваться совершенно по разному.

Например, газетный киоск (shop=news_agent) в Москве и Сан-Паулу имеет совершенно разный ассортимент.

Для этого введём привязку меток к пользователям.

Я понятия не имею почему согласование смыслов требовало Proposal process вместо перетегирования объектов на *одинаковые *или разные метки.

Всё тегами их изобретателями должно решаться, если их задачи решает, значит схема тегирования адекватная для какой-то цели.

Газеты в Москве и Сан-Паулу могут иметь похожие метки, но смыслы которые вкладывают к них авторы будут разные и обрабатывать их нужно по-разному.

Иначе получаются village_green которые что-то значат в Англии, но у нас это просто зелёные прямоугольники для красоты.

Обрабатывать такие теги с наивным предположением что все будут понимать тег одинаково - наивно. Нужно отфильтровывать данные на уровне отдельных пользователей у таких специфичных вещей.

Иначе у вас будут люди которые разбираются в таксономии растений, а есть люди которые просто так, в википедию заглянули.

Иногда этими различиями можно принебречь. Иногда нет.

речь не идет о подробном описании ассортимента. Речь идет о основном “направлении” этого ассортимента. Как пример два shop=doityourself но один занимается только наполными покрытиями и сопутсвущими товарами, другой только плиткой и сопуствующими товарами. Так и надо это указывать.

А на мой взгляд, практически одинаковый, да. Газеты, журналы, возможно мелкие канцтовары. Естественно издания будут разные, но это и дебилу понятно, что в Сан-Паулу было бы странно встретить в киоске газету “Вечерний Бобруйск”, как и в Бобруйске “Вечерний Сан-Паулу”.

Так что смысл ассортимента не в перечислении конкретных товаров, а в перечислении типов товаров которые есть.

Но есть задача актуальная (относительно конечно), но малоразрешимая: есть большая деревня, в ней два магазина. Условно назовём один “для алоконавтов” а другой “продуктовый”. Но, ассортименты (как я понимаю их) они одинаковые. Просто в “для алконавтов” всё самое дешовое - и водка, и закуска. А в “продуктовом” товары нормального качества. Формализировать такое различие, imho не получится. Только note человекочитаемое писать.

Дык, эти “направления” нигде не описаны, и каждый волен понимать их по своему.

Что же есть? Есть кодифицированные на вики значения shop. Если значение ключа подходит к объекту, этот ключ можно вешать на объект. Тот же doityourself.

То что в двух магазинах shop=xxx может быть совершенно разный набор конкретных товаров – абсолютно нормально. Что касается “направления” – оно чисто умозрительно. Каждый волен объединять товары в группы как ему угодно. “Вечерний Бобруйск” и “Вечерний Сан-Паулу” – это газеты. линолиум и стенной кафель – материалы для ремонта дома. Один считает, что нужно (ему нужно или всем нужно?) различать между линолеумом и плиткой, шурупами и метизами, болтами и гайками. А другой считает что не нужно.

Еще раз, что мы хотим? Решить какую-то насущную задачу, или представить себе способ формализировать вообще ВСЁ? Разработать на будущее некую “универсальную онтологию”?

Кто-то ходит за хлебом, а кто-то за водкой.

Да такого просто нету.

Ну а если общество считает достаточной формализацию, то тогда я буду note писать. Оно так точно не повредит.

Главное тут - кому то водки хочется нормальной, а кому то лишь бы какую, так как у бабы Мани сэм кончился.

Если я правильно понял не хватает спецификации diy магазинов?
Что-то типа shop:doityourself=Электрика;Напольные покрытия;Сантехника

Собственно да. Но пропозал про магазины есть, и если не будет потярсений никаких его надо принимать и начинать описывать типы магазинов. В том числе и diy