Вообще-то, речь шла речь про избыточность RU. И, как указали выше, такая избыточность сделана в угоду какому-то софту. Что печально.
Такой вопрос - если на шоссе с 1 апреля по 30 октября ограничение скорости 80 км/ч, а в прочие месяцы - 60, то как корректней всего это отобразить?
maxspeed=80 и maxspeed:conditonal=60 @ (Nov-Mar) ?
Или лучше наоборот?
7 месяцев 80, 5 месяцев 60…
Для конвертеров, которые не понимают maxspeed:conditonal лучше бы maxspeed=60 и maxspeed:conditonal=80 @ (Apr-Oct)
Как обозначить построенную, но пока закрытую для пассажиров станцию метро (точнее вестибюль открыт, но посадочные платформы и выход в тоннель закрыты)? Конкретно речь идет про единственную пока построенную станцию в Омске “Библиотека им. Пушкина”? https://www.openstreetmap.org/edit#map=18/54.99399/73.36111 По идее вроде бы уже не construction=yes, preserved тоже не совсем подходит…
В том месте где проход закрыт
barrier=gate
access=no
Ну а вообще звучит, как магазин открыт, но там ни чего не продают. По факту на фиг такой магазин нужен.
При обозначении бассейнов возник следующий вопрос: многие из них входят в состав физкультурно-оздоровительных комплексов, соответственно их помечаем через leisure=sport_centre, но вот с обозначением самих бассейнов есть два варианта:
- Добавить к полигону ФОК тег sport=swimming (ну и дополнительно остальные виды спорта черз точку запятой при необходимости). Плюсы: лаконичность, явная связь бассейна и ФОК в котором он находится, отсюда и прямая связь для addr:, contact: и name. Минусы: вроде как этот способ мало где поддерживается, т.е. если искать бассейны, то места обозначенные таким образом отображаться не будут (да и просто при рендеринге их не будет видно); в теории возможна ситуация, что opening_hours ФОК и бассейна могут быть различны, что этим способом выразить будет сложно.
- Добавить точку внутри полигона ФОК и навесить на неё тег leisure=swimming_pool. Плюсы и минусы тут меняются местами по сравнению с предыдущим вариантом.
Как думаете лучше поступать?
Мне кажется, минусы уходят, а плюсы, как раз, во втором способе остаются :). Так как внутри полигона (а еще и поставить в нужном месте на полигоне), чем не явная связь. А addr:, contact: берутся автоматом с полигона.
Ох уж эта “явная” связь, которая якобы вытекает из того что база у нас географическая… Этот подход хорош в теории, но на практике же оборачивается дополнительным неслабым геморроем для разработчика. Вот например, можете ли вы показать софт который этой фигнёй занимается на практике? Представьте разработчика слабо знакомого с этими весёлыми обычаями “явности”, который пишет софт в котором имеется поиск по условным бассейнам с выводом названия, адресной и контактной информации, то как вы думаете каков будет его подход к проблеме? Отфильтровать leisure=swimming_pool (плюс не забыв ещё и о amenity=swimming_pool) и указать в карточке соответствующие теги. И вдруг оказывается что для ФОК нужно доставать эту информацию по другому, в первом подходе он просто произведёт дополнительную фильтрацию по leisure=sport_centre и sport=swimming (с учётом возможной множественности) и написанным ранее кодом просто создаст карточку или засунет это дело в адресный индекс, во втором же, ему придётся накручивать дополнительный код производящий геозапросы для поиска полигона гипотетического спортивного центра, принимать решение какого размера выбрать магический bbox для поиска, делать проверки на вхождение внутрь полигонов, разбирать возможные экзотические варианты и т.д. и т.п.
Весь нормальный софт, который заточен под osm и сделан не на коленке это обрабатывает.
Как насчёт того, что бы совместить оба варианта? Т.е. проставлять sport=swimming на контуре ФОК и добавлять точку внутри него с единственным тегом leisure=swimming_pool. Возражений против такого подхода нет?
Вот такого как раз не надо, так идёт дублирование, а значит искажение данных.
sport=swimming - это там где занимаются именно спортивным плаванием.
Не любой бассейн для этого годится.
Как обозначить музыкальную и художественную школу?
Воспользуйтесь поиском.
Каким поиском?
Ну это как-то не по OSM-овски. Есть такая ветка http://forum.openstreetmap.org/viewtopic.php?id=20352&p=3 и такой пропозал http://wiki.openstreetmap.org/wiki/Proposed_features/training
Парикмахерская для собак?
По taginfo нашлось такое:
56 shop=pet_grooming
16 shop=dog_grooming
8 amenity=dog_grooming
Те бассейны что располагаются в различных ДЮСШ/ФСК именно спортивные (про их тегирование в основном речь и шла), в России наоборот стоит поискать бассейны которые бы нормально подпадали под смысл тега leisure.
А почему, вы считаете, что в данном случае будет дублирование? У нас же точка с leisure=swimming_pool “явно” связано с полигоном спортивного комплекса, для которого через тег sport указываются (в идеале) все виды спорта которыми можно в нём заниматься, в т.ч. и плавание. Т.е. получается, что sport просто характеристика спортцентра, а точка уже непосредственно POI.
Вообще, имхо, привычный бардак с схемой тегирования… (даже не вспоминая про amenity=swimming_pool)
Потому, что эту явную связь используют пока для адресации, а не склейки всех тегов. Причём у вас это ещё в извращённой схеме, когда уточняющий тег у родителя.