Пустота заголовка и отсутствие картинок, ссылок на osm wiki для вас нормально?
И что теперь? Вы JOSM открывали когда-нибудь? выделяли тег там? Нажимали F1 пока фокус был на теге?
Замапьте что-нибудь shop=car_parts и нажмите F1 в JOSM, теперь попробуйте повторить это с shop=car_parts;tea.
Теперь откройте iD добатьте точку с shop=car_parts, а теперь сменить это на shop=car_parts;tea и куда денутся все переводы.
Я вам такие очевидные вещи говорю… На этом достаточно.
Точка с запятой предполагает несколько значений. Для каждого отдельного значения нужно описание и страница в вики. Создать страницы для всех комбинаций тегов с “;” нереально. Да и не нужно это.
Вообще, для таких случаев нужна своя заготовка с кучей галочек. Возле каждой из них может быть ссылка на вики. Выглядеть это будет точно также, как и при использовании shop:car_parts=yes.
Можно распознавать “;” в теге и для каждого значения, разделённого точкой с запятой, и поставлять перевод. Он может быть кликабельным и вести на вики-страницу этого отдельного значения.
Честно, не вижу принципиальной разнице, что там свойства магазина, что тут свойства строения. Притом всё равно для подания информации человеку надо понимать конкретный тег, потому как даже для building=yes и building=roof сильно по разному нужно интерпретировать building:levels.
А вот за картинку “Режим умных тегов:” пять с плюсом.
Точно так же никогда не было shop=car_parts а до этого shop=greengrocer.
“Список всех возможных значений” можно узнать по страница из вики. Либо по пресетам iD. Либо еще из статистики Taginfo но она врёт и не ясно есть ли альтернативная схема.
То есть ты хочешь парсить сам не знаешь что. Зачем? Ты вики страницу открывал со смыслом этого тега? Такое вообще встречается что тебе что-то попалось полезное, но для неё нет вики страницы или предложения? Кроме натянутых за уши примеров?
Это вообще не связано с точкой запятой.
; просто запретить кроме opening_hours, addr:flats, turn тегов и простых ref=* и всё.
Серьёзно, зачем кому-то защищать 150 тегов с запятой shop=* когда 169000 shop=* магазинов. Вот изза этих >1% мне нужно объяснять что-то про регулярки? Про то, что что-то нужно избегать? Про то что это поддерживается только в малой части программ?
1.1. Напиши мне, пожалуйста, алгоритм который говорит мне о том, что передомною магазин. Любой.
1.2. Напиши мне, пожалуйста, алгоритм который соберет мне все типологии магазина, в том числе те, которых у меня нет в словаре.
Мне вообще сложно представить что тебя радует, что огорчает и что движет тобою в твоей деятельности.
Можно, схема не лишина приемуществ, хотя есть вещи которые меня смущают. Я бы не стал ограничивать применение ни одной из них, да собственно и возможности такой в осм нету.
Тоесть препроцессор умеет генерить код вида
“совпадение ключ=значение” или “совпадение ключ=значение” или “совпадение ключ=значение”
но не умеет генерить код вида “значение содержит строку” для shop.=car_parts
(допустим что содержится мы задаем через .=)
или не умеет разделять значения по символу ‘;’?
Ну это странный препроцессор, умеющий ровно то что нужно тебе и не умеющий ничего другого.
Это то безусловно плюс этой системы обозначения, что впрочем не говорит о том что другая система обозначения должна быть запрещена.
Сравнение не корректное, надо сравнить количество highway с двумя и более значениями разделенными ‘;’ и highway с двумя и более значениями записанными как highway:value=yes
Никита, то как ты общаешься с сообществом, то что ты постоянно говоришь менторским тоном, то что ты постоянно пытаешься, противопоставить себя сообществу и сообщество в чем-то упрекнуть, причем упреки зачастую сводятся к тому, что сообщество не делает чего-то что оно, по твоему мнению обязано было сделать, здесь и сейчас, все это говорит о том что и не увидишь.
‘;’ непременно должен быть разрушен, спасибо Катон, мы поняли.
Я хочу получить значения, не выбросив те из них которых нет в словаре.
Я хочу получить общую категорию магазин.
Как ты кстати отфильтруешь все магазины?
Да, например некоторые значения тега cuisine.
Это не просто. Ты вот наверное почувствовал что убедить 10 человек на форуме - это уже не просто. Убедить 10 человек на форуме и 10 человек в списке рассылки, совсем не просто. А добится чтобы маперы реально ; не использовали, сложнее на несколько порядков.
Еще, раз, сравнение не корректно.
Ну уж снизойди до нас, сирых да убогих.
Вооооо, запрещать перешло в избегать. День прожит не зря.
1.1 У нас есть теги. Очевидно что нужны все теги магазина, если тега нет, то мы ничего не можем знать о намеряннеях мапперов, пусть свои теги документируют. Мы что гадалки по Taginfo?
1.2 Если ты такой вопрос спрашиваешь ты знаешь ответ. Я тебе скажу такого алгоритма еще десятки лет не будет, причём для самых мощных компьютеров мира, OSM очень повезёт если дадут прикоснутся к ним. strong AI это не путь OSM, мы не ждём пока нам с неба упадёт чудо-алгоритм который решит где можно капусту купить, а где нет. Овощной? Мапим овощной. Вроде проще, но конкретных ответов не даёт. Где же мне капусту купить? Поищу-ка овощные.
Для чего можно редактировать iD кроме новичков? Ясен день когда кто-то пытается изголится с точкой с запятой в теге POI я этому не рад открыв iD.
Баааальшой запрос использующий bitset lookup-ы. Все теги магазинов узнаю как в пункте 1.1
Либо я сильно умный и использую что-то более подходящее, вроде bloom filters.
Не хочу я никому регулярки объяснять. Из института выходят ничего не понимая, а ты хочешь чтобы я учил автоматам, компиляторам и парсерам только потому что кто-то считает что запятую можно поставить, прокатит? Ты вообще серьёзно этот вопрос задал? Конечно не снизойду.
Тон/не тон. Что значит упрекнуть, кого? Проблема либо есть либо нет. Решать её нужно. Можно быстро, можно тянуть время и никогда ничего не сделать.
Сообщество затегировало 99,9% объектов одинаково, но над 0,1% нужно разбить голову и свернуть схемы работы программ разработчикам. У новичков не должно быть документации и внятных подсказок ради чего? Чтобы кто-то регулярками похвастался? Что у сообщества такого есть что абсолютно все программы должны сломаться на этих точках с запятой кроме osmand, osm2mp и пары других.
Нет, их нет смысла использовать кроме четырёх-пяти случаев. Те доли процента можно перетегировать за вечер и запретить.
Пора бы договориться что точка с запятой это фу, у нас так не делают.
Тоесть регулярки по значениям - это фу,
код вида new tagValue.split(“;”).contains(“something”) - тоже фу.
А необходимость передать осмозису или osmfilter к примеру, список всех возможных типов магазинов, + реализация ими фильтра Блума или bitset фильтра, чтобы получить выгрузку в csv магазинов в регионе - это одобрямс?
Не совсем понял. Правила таггетирования не аксиома и постоянно меняются - это нормально. По идее, инструментарий должен меняться вслед.
Концептуально, я вижу тут проблему в том, что попытки причесать мир по структуру ключ=значение, изначально обречены напровал. Мир несколько сложнее. Это всё как раз из разряда - впихнуть не впихуемое.
Ну, то есть Ваш вариант это мапить под инструменты? То есть, под рендер мы таки не мапим, но под какие-то другие вещи будем? У меня в этом месте возникает небольшой диссонанс.
ynx, выражение “мапить под рендер” означает приписывать объектам неверные (не соответствующие реальности) теги, чтобы они лучше выглядел (или вообще показывался) на рендере.
При выборе же самих схем тегирования, возможности инструментов (и желания их создателей и мантейнеров) должны безусловно приниматься во внимание.
Кстати, насчёт old_name. Раз вы тут составляете адекватную схему присвоения нескольких значений ключам, предлагаю запретить alt_name, а альтернативные названия добавлять в name. Ну или использовать alt_shop, alt_ref и т.д.
К счастью, изначально обречены на провал попытки поломать то, что есть и работает много лет.
ключ=значение – это основа структуры данных осм. Если она не нравится, то нужно менять API, а не пытаться впихнуть в неё то, что в неё действительно не вписывается.
Что касается конкретно магазинов, то существующая схема shop=<тип по основному ассортименту> дает вполне адекватное приближение к реальности и на своем уровне подробности, ничего не искажает.
С последним категорически не согласен. С моей точки зрения нужно разделять данные и обработку этих данных (редакатирование/удаление/добавление данных к этому не относится). Задача данных, максимально полно и точно описывать объекты мира (в случае OSM) и всё. Именно из этого и нужно исходить предлагая те или иные варианты тегетирования. Всё остальное, как то поиск, или та же отрисовка это те задачи, которые абсолютно никак не должны влиять на сами данные и их структуру. Если используемая структура, например, не подходит для поиска, значит где-то рядом надо создавать индекс по этим данным или вообще конвертировать данные в во внутренние стуктуры и использовать уже их.
Много что работало много лет и ничего, поменялось.
Да я и не говорил, что стуктура ключ=значение так уж плоха. Просто она имеет свои ограничения.
Про магазины согласен, поэтому вижу смысл в отказе от ; только в том контексте, что надо указывать только основной ассортимент и всё. Для чего-то более детального, как мне видится, надо уже делать какую GIS. Куда можно будет и номенклатуру товаров запихивать с ценами на них, и количество жителей с уровнем преступности. И я сомневаюсь что в такой GIS будут именно ключ=значение, хотя кто знает, конечно.
нечего ради этого 0,1% новичкам горовит слово “регулярка”. Тебе нравится когда твоё имя предлагают найти как ~ди~? Димой тебя не зовут? Dmitry нет такого имени? Зачем я вообще это должен кому-то объяснять?
нечего поддерживать программы которые парсят name=* или считают что highway=* найдёт дороги. Что ~Дми~ это регулярка имени Дмитрий. Ты пол людей тоже по именам определаешь? А не отдельному смысловому тегу “пол”?
Вообще не нужно разделять по точке с запятой. Ты не строки парсишь.
http://wiki.openstreetmap.org/wiki/Tag%3Ashop%3Dsupermarket “A large store for groceries and other goods”
Хотят твои пользователи “groceries and other goods” ищи для них “shop”=“supermarket”. Обрати внимание на кавычки. Я настаиваю что код счиатющие shop= - магазинами сломан изначально. Те кто от лени ищут все с shop=* не должны говорить остальным что магазины это shop=. У нас 200+ тегов магазинов, никих регулярок shop= в OSM нет.
Это делается один раз и выкладывается на гитхаб. Никакого секрета в 200 тегах через дизъюнкцию нет. Вместо этого ты хочешь чтобы каждый разработчик блестал (как ему кажется) регулярками.
Более того, обычные пользователи не могут использовать регулярки в значениях у программ которые пытаешься защищать.
Попробуй-ка мне найти volleyball этими osmosis или osmfilter:
у объектов с sport=soccer;volleyball
Конечно же да. Если osmosis еще можно пожалеть как основную программу импорта.
Ни osmosis
Ни osmfilter
Не могут выполнить функции базы данных. Если ты составлял запросы в них, а не postgres, спешу тебя огорчить, есть более продуктивные инструменты для работы с данными OSM. Пропогандируя менее эффективные инструменты (в т.ч. регулярки) ты не напрямую, но затягиваешь процесс эволюции.
osmosis это утилита выгрузки-загрузки в DB, не более. То, что ты видишь фильтрацию в ней это плюшки, а не основная функция.
Основаную фукнцию запросов выполняют
postgresql
overpass
OSM API 0.6
В блокнотике тоже можно xml читать, но это не значит что это хорошая идея или стоит так советовать всем делать.
Фраза хорошая, но целиком не соглашусь.
Смысл объекта мира нужно дробить, тогда его можно будет впихнуть в маленькие теги OSM.
Если раньше жили sport=soccer;volleyball и казалось нормально, то сегодня нужно два тега:
sport:soccer=yes
sport:volleyball=yes
Получилось впихнуть? Конечно. Можно найти воллебольную площадку? Да запросто:
“sport:volleyball”=“yes”
Никаких регулярок вообще никому или разбиения по ; в коде.
Для обратной совместимости с предыдущими программами можно указать ещё один тег-костыль:
sport=multi либо sport=soccer
phone=* тоже в исключения, нет смысла их разделять на теги. У телефонов нет смыслов poi. Вы не ишете по 11цифрам-значениям. Напротив, для спорта, вам нужен только определённый спорт.
Не нужно писать sport=multi, это почти ничего не значит. Это подойдёт только для совместимости со старыми программами.
То же что и с телефонами, смысла различать их нет как разные POI, пока что у нас нет массивов вместо тупой строки value (tag=value), придётся их писать через ;. Как только появятся массивы, тут же перетегируем без точкозапятых.
Насчёт alt_name= еще можно согласится, то old_name=* точно нельзя смешивать с name=. old_name= значит старое имя, name=* для текущего и действующего.
Про old name: как вариант можно договориться использовать не old_name=, а was:name=. Но это чисто наше Российское соглашение будет, дубов в tagging@ сдвинуть нереально.
