Говорю же нет, только один тег-костыль:
amenity=yes // либо очень любимый вам amenity=<смысловойтег13>
amenity:<смысловойтег1>=*
amenity:<смысловойтег1>:description=Его зовут 1
amenity:<смысловойтег500>=*
amenity:<смысловойтег500>:description=Его зовут 500
Как только программы научатся обрабатывать <смысловойтег1>, <смысловойтег500> тогда amenity=yes можем убить (или оставить в назидание) как бессмысленный пережиток прошлого.
Что значит amenity прямо сейчас??? Какой программе нужно выполнить запрос *amenity=**, покажите мне кусок кода этой программы, я скажу насколько она сломана и откуда растут руки у кого.
Смысловые-группы-изоляторы для тегов точно да (не в рамках API 0.6), без них никак не обозначить два объекта мира одной точкой (любой геометрией):
- amenity=atm
- amenity=bank + name=Сибирьнефтьденьги
Это требует очень сильных статистиков которые очень быстро будут разрабатывать алгоритмы классификации и ранжирования в OSM. Этот подход могут позволить большие компании с штатными людьми, для хоббистов и набегающих-убегающих программистов в OSM это будет тяжело вести такую постоянно эволюционируют штуку. Мы с “жесткими” тегами не очень быстро растём (в плане сложности иерархий, у нас до сих пор всё лепят под amenity=, man_made= только потому что “их миллионы, посмотри сам”.
Понял вашу затею, вы пытаетесь упростить “говорливые теги” pub=yes и “ref:ИНН”=* до отдельных символов.
- Это проще, реально проще вам (тому, кто знает соответствия)
- Это тяжело учить (вы точно знаете весь *компактный *синтаксис регулярок?)
- Это тяжело документировать без изменений всей инфраструктуры (от Taginfo до iD, JOSM, не говоря уже о программах которые используют данные), это сверх-важно для OSM. Cсылку на описание pub=yes (или amenity:pub=yes) просто исправить переправив на amenity=pub.
Да, они исключения потому что не ищут по 11значным цифрам телефона и конкретному значению напряжения.