полагаю, craft=frame
У shop=frame есть в описании и заказ.
Если знаете, что основной профиль - заказные рамы, а не готовые 10*15 или А4, используйте craft, как подсказывает коллега.
Минус craft’a - пока не описан, нет поддержки в ПО/рендерах.
Вообще, ключ shop не говорит о том, что заведение - это строго магазин, это может быть и мастерская (в английском языке слово используется в обоих значениях).
Как обозначить “соляную пещеру”? По сути - помещение с рассыпанной солью по полу 
и вот таким агрегатом. Там еще проводят какую-то галойогу (видимо дыхательную).
И как указать, что попасть туда можно только после предварительной записи?
если основная функция - занятия по йоге - то как спорт-центр + sport=yoga
если основная функция - оздоровление - то как amenity=doctors + по схеме healthcare
Ну там я так понял скорее второе, но контора вроде не совсем медицинская. Из healthcare не понял как это обозначить.
Чтобы понять, как обозначить по схеме healthcare, нужно больше подробностей. health_facility:type=office наверное + medical_system:ayurveeda=yes - но это я могу только догадываться.
предварительная запись - reservation=required
Как обозначить?
Пока единственное, что приходит на ум - leisure=playground
мне кажется, если основная функция - оставить ребенка на время под присмотром - то https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dchildcare
если основная функция - это именно развлечения (т.е. туда детей специально для этого везут) - то tourism=theme_park - такой маленький Диснейуорлд
Какая рабочая схема с разливным пивом?
Мне как-то ответили, что можно добавлять alcohol = draft_beer, пока так делаю, если появится что-то более правильное - переделать не составит труда.
А shop=beverages или alcohol ? В вики опять точного определения нет, т.к. этот тег стал жертвой демократии в OSM.
Есть еще вариант с http://wiki.openstreetmap.org/wiki/Key:drink
beverages или alcohol, как по мне, отражают только суть того, что в магазине продаётся, но без уточнений. Вот с drink интересно, там есть вариант, например, drink:beer = draught, похоже на пиво из бочат, яндекс перевёл даже именно как пиво в розлив.
тестовое сообщение
Ветка была сломана, ссылка на последнюю страницу вела на сообщение об ошибке. Починилась после удаления одного сообщения. Возвращаю его сюда в виде цитаты:
Подкиньте ссылку, которая там была, пожалуйста.
Как вы считаете, внутренняя часть здания здесь правильно обозначена?
По-моему, чего-то не хватает: https://www.openstreetmap.org/way/57959932
Выделенный контур - это inner-кольцо основного 12-этажного здания, но одновременно с этим контур обозначает еще и внутреннюю 5-этажную часть того же здания. То есть как будто нужно одновременно указать роль и inner, и outer + building:part=yes. Ну, или если совсем по-хорошему, делать новое отношение type=building, в которое включать внешний контур 12-этажного здания, мультиполигон 12-этажного здания (building:part=yes) и 5-этажную часть (building:part=yes). Внутренний контур будет являться членом мультиполигона (роль inner) и членом отношения типа building (роль part).
Правильно мыслю? Или то, что есть сейчас, тоже правильное? Уж очень смущает тег building:part на “дырке”.
Неправильно то, что “дырка” исключена из состава здания (building=yes). Полигоны building:part должны входить в полигон building, а дублирование building и building:part на одном объекте некорректно.
Как вариант правильного тегирования - оставить на полигоне-“бублике” все, что касается 12-этажной части, а все теги, касающиеся здания в целом (building и адреса) перевесить на внешний контур. Ну или 3 отношения создать (building с внешним outer и адресом и два building:part с соответствующей этажностью), тогда убрать все теги с линий - это уж дело вкуса.
Спасибо.
Ещё вопрос: а корректно ли вообще вешать тег building:part на части мультиполигона? Страница вики Simple 3D Buildings предписывает маппить с использованием отношения type=building, а не type=multipolygon. Ведь к мультиполигону надо относиться только как к геометрическому объекту, отдельные его части не могут иметь собственные свойства. А если имеют, значит они должны быть самостоятельными объектами с собственным тегом.
Озеро, вырезанное внутри лесного массива, будет иметь тег natural=water, что как раз сделает его собственным объектом, не имеющим отношения к лесу (и этому озеру не важно, является ли его контур inner-частью лесного мультиполигона - оно к нему не относится).
А вот building:part=* не является самодостаточным тегом, он как бы говорит нам, что остальные свойства здания (тип, access, название, building:material и всё прочее) должны быть взяты у “родителя”. А родитель без отношения type=building не определён, ведь факт принадлежности якобы “родительскому” отношению type=multipolygon еще не делает объект дочерним. Всё как с лесом и озером, озеро ведь не часть леса.
Отсюда я делаю вывод, что любые несамодостаточные (“уточняющие” теги, наподобие building:levels), поставленные на членов мультиполигона, являются результатом неправильного картографирования. Объекты с такими тегами надо сделать членом отношения type=building, выставив роль role=part, как сказано в Simple 3D Buildings. Это и только это явно сделает их дочерними для здания, сделает их не просто частью чьей-то геометрии, а самостоятельными объектами, а так же укажет, что теги отношения-родителя относятся и к нему.
Правильно рассуждаю?
Примечание: я пишу 3D-рендерер и поэтому пытаюсь выяснить, какой способ обозначения правильный, а какой заведомо неправильный, который рендерер может себе позволить отображать некорректно с пометкой “оно неправильно обозначено, исправьте”. (Естественно, по возможности я постараюсь правильно нарисовать даже неправильно отмапленные объекты, но в любом случае надо знать, что правильно, а что нет.)
Не совсем. Полигон building:part=* действительно не самодостаточен и является частью отношения type=building, на что также указывает его роль part. Но! Данный полигон выделяется лишь для того, чтоб показать на нём свойства, отличные от свойств других частей или всего здания, как то этажность, форма крыши, цвет и прочее. Общие свойства - адресация или один цвет вешается на отношение.
Дополнительно для таких зданий делают общий внешний контур с building=* и ролью в отношении outline для “совместимости с 2D рендерами”