Ок, для начала phone=contact:phone можно проставлять, для обратной совместимости, так сказать, но реально, contact:* правильнее. Получаем хороший namespace, который описывает именно “контактную часть”, на неё можно повесть один conditional, например, и не надо будет гадать когда можно звонить, когда мне ответят на e-mail или во сколько можно ждать обновления статуса заказа на сайте, потому что я прекрасно знаю, что время работы contact’а и opening_hours вполне могут разительно различаться.
У меня встречалось что контактный телефон (contact:phone, администрация), отличался от телефона бронирования столов и доставки (booking:phone, delivery:contact:phone)
А разве я написал, что они не отличаются? Как раз наоборот, они отличаются и вносятся каждый в свои теги.
Только теги должны относиться к неймспесу “контакты”
contact:<тип соединения>[:<название подразделения>]
Т.е. будет contact:phone:booking=, contact:phone:delivery=, contact:website:booking=<booking.site.com>, contact:website=<site.com> ну и т.д.
Тут криво получается (впереди идут контакты, а не с кем именно контакт, но напомню, что в url тоже идут от обратного, поддомены пишутся в обратную сторону, а перед ними ставят юзера и протокол, которые должны, при такой идеологии, в конец писаться), но не потребует заводить отдельных booking=yes, delivery=yes и прочих бестолковых тегов.
Что так, что так, она будет переменная, т.е. от [<название подразделения>:]contact:<тип соединения> ни чего не меняется, но при первом варианте, хотя бы, можно сделать “получить все контакты организации”, либо потом уточнить “получить все телефоны организации”/“получить все твитеры”/“получить все сайты” и т.д., но нельзя “получить все контакты отдела доставки”. Но, contact:= - лучше, чем просто (phone,twitter,website,facebook etc)=
так если это банк, бренд и оператор уже будут заняты самим банком
в общем, посмотрел еще раз - не только оператор бренд и нейм будут заняты банком, но и сам ключ “amenity”. То есть как впихнуть переводы в банк я в итоге не понял как. И еще есть два типа точек денежных переводов - где можно положить деньги (перевести) например в салонах мегафон, евросеть; а есть где можно и снять (только в банках). Как обозначить еще этот признак?
на оверпассе смотрел, ничего подобного нет, и там все точки отдельно от банков http://overpass-turbo.eu/s/9B0
Тогда да. Или две отдельные точки рядом. Или одна точка и на неё навесить два relation type=node http://shtosm.ru/all/uzly-bezumiya/ с разными тегами, тогда противоречий не будет.
Имеется национальный парк Самарская лука, в котором есть следующие зоны:
заповедная территория (посещать нельзя, только в определеные экскурсионные места по платным путёвкам)
особо охраняемая территория (посещать нельзя, за исключением дорог общего пользования, либо по специальным туристическим маршрутам по платным путёвкам)
рекреационная територия (посещать по платной путёвке, но гулять по территории можно свободно)
зона традиционного землепользования (можно посещать свободно)
Зоны расставил от самой строгой до самой нестрогой (4-ю можно вообще не обозначать).
1-ю обозначаю как leisure=nature_reserve и boundary=protected_area, как бы намекая на запрет посещения
2-ю обозначаю как просто leisure=nature_reserve, как бы намекая на меньшую строгость на запрет посещения
3-ю не знаю, как обозначить (она слишком нестрогая, хотя и доступна только по платным путёвкам).
4-ю обозначать не надо, т.к. это фактически отсутствие какой-либо особой зоны.
Что посоветуете насчёт №3 и правильно ли я поступаю с 1 и 2?
На всякий случай: я создаю велосипедную карту Самарской области (http://cycletrailmap.romanshuvalov.com/) и поэтому все эти зоны считаю нужным на OSM нанести. Естественно, по тем правилам, которые приняты в OSM, а я уж стиль своей карты подредактирую под то, что получится в OSM. Но важно, чтобы все зоны отличались тэгами. То есть чтобы был отличительный признак каждый зоны.
P.S. Геометрию зон беру из Положения о национальном парке (Приказ минприроды России, в тексте положения есть данные для карты зонирования)
Надо проставить теги access как сказали выше. Зоны с разными уровнями защиты сделать отдельными отношениями boundary=protected_area. У каждой свой protect_class. И еще одно отношение охватывающее все зоны. На него повесить все общие теги типа имени охраняемой территории, protect_title и т.д. Есть ещё тег site_zone=*, но я честно говоря не понял как автор пропозала предлагает тегировать им.