А если такой вариант - оставляем на домах addr:housenumber, addr:street и addr:city и при этом отказываемся от полигонов place? Решаем сразу две проблемы - адреса и дублирование точка/полигон для НП.
Информация о границах НП в РФ официально содержится либо в ГП (принимается раз в 5 лет), либо в СТП (принимается раз в 10 лет). Эти данные обычно отстают от реальности, поэтому границы тупо проводятся по очертаниям жилой застройки, никак не верифицируются и по большому счёту ничем не лучше границ судебных участков, которые недавно выпилили.
Дублирование place=* (с name=*) на точке и полигоне - наверное, единственный отход от базового принципа “один объект в реальности - один объект в OSM”. Было бы круто убрать хотя бы в России это исключение. Как я понимаю, в поиске тоже будет 2 результата: точка и полигон?
Ради убирания задвоения подписей на основном стиле сейчас в России пошла в обиход практика “обвести границу НП в чуть сжатом виде второй линией, чтобы разнести по ним теги landuse= и place=”. Это выглядит как полный костыль. А ещё раньше был тег place_name по той же самой причине. Можно бороться с мапингом под рендер, принудительно заставляя терпеть подписи, а можно устранить системно причину их появления.
Судя по вики, основная цель дублирования - работа конвертеров, которые берут адресную информацию с полигона (информация внесена в 2011 году). Но они в любом случае при наличии addr:city на здании будут брать его, т. к. адреска в OSM есть и вне пределов границ НП + адрес может быть исключением и не совпадать с тем, что выводится из границ. А больше ни за чем эти полигоны в том виде, в каком они у нас есть, и не нужны.
Нет проблем с синхронизацией тегов на полигоне и точке place, т. к. остаётся только точка.
Проще следить за границами, т. к. уже не будет пересечений границ административных и НП, меньше путаницы.
Для справки: в английской вики на Key:place сейчас рекомендуют ровно то же самое.
Вот так изящно и без костылей у них была решена проблема с задвоением сущностей.
Вообще это не совсем одно и то же: одно границы, другое значимый центр, аля точка притяжения. Так же у нас и части здания, по твоей логике, один и тот же объект и их следует удалить. А двух-вейные дороги как?
И потом само предложение даёт только головняка, вместо одной единожды нарисованной границы, ты предлагаешь заниматься копипастой тегов, как будто больше заняться не чем.
А потом, визуальный контроль при таком подходе вообще на уровне плинтуса. Если я скачал границу я сразу увижу, что часть домов на новой улице находятся за ней и надо бы её подправить. А что делать с addr:city,
я не вижу где такой тег вообще есть
я не вижу его содержимое и насколько оно корректно, надо постоянно выяснять, а где я
И по итогу окажется, что вылавливать косяки будут, только после того, как опа, номер дома на карте есть, а в поиске нет.
Учитывая, что вкупе с этим рекомендуется использовать полную Карлсруэ - думаю, только вопрос времени, когда Apple, FB и прочие начнут ломать у нас всё по этим рекомендациям. Я бы предпочел все заранее оформить, готовясь к неизбежному
Опять же, все примеры в RU:Addresses включают в себя простановку addr:city на домах.
Так а если предметно: есть ли пример конвертера/навигатора/приложения, которое берет информацию о городе в составе адреса с полигона place и при этом игнорирует/не отдаёт приоритета тегам addr:city, проставленным на зданиях в этом городе?
Вот нашёл. Здание https://www.openstreetmap.org/way/574967295 у которого addr:city=Плотинная . Номинатим на главной при поиске строки “улица Гайдара 37А” подставляет Камень-На-Оби. При поиске той же строки в osmand, maps.me, magic earth все подставляют название города.
Более того, если я верно трактую засветлённые серым строки, то города с полигонов place и admin_level=8 были проигнорированы именно по причине наличия прямого указания НП на контуре дома. В чате же высказывалось предположение, что при наличии контура границы номинатум наоборот игнорирует адресные теги этого уровня на зданиях внутри.
Плотинная здесь не из тегов линии. Nominatim нашел полигон place с таким именем. Это деревня рядом с городом Камень-на-Оби. Если бы этой линии не было - Nominatim ничего бы с таким названием не вывел.
Геометрически линия здания находится внутри другого полигона place: Камень-на-Оби. Его название Nominatim тоже вывел в результатах.
Какой из этих полигонов использовать в addr решает UI. Сайт openstreetmap.org использует последний, Nominatim UI первый ) В данном случае “Плотинная” ошибочна и правильно использовать геометрию - у нас по закону в населенном пункте не может быть адреса из другого НП.
А какие у UI есть возможности, чтобы определить нужный результат? Наугад или самому дополнительно считать геометрическую вложенность?
И я правильно понимаю, что в случае отсутствия обоих полигонов place (и города, и деревни) и присутствия на здании тега addr:city Nominatim выдаст ровно один результат с тем городом, что на здании?
В ходе обсуждения в телеграм-чате были выявлены следующие (возможные) кейсы использования place:
Nominatum (разобрано выше)
Определение скоростных ограничений в НП в автонавигаторе
Overpass умеет делать запросы через named area
Для разного рода урбанистических проектов, расчета плотности населения и т. п.
По поводу навигаторов. Скоростные ограничения RU:urban сейчас проставлены на подавляющем большинстве дорог; на тех, что ведут в/из города - уж точно. Ни на русской, ни на английской вики нет рекомендации использовать для этого полигоны place. Что стоит сделать - так это доставить их на мелких дорогах внутри НП, где вообще может быть жилая зона, и потому ограничение в 60 км/ч не спасет.
То есть уже есть 4 разных варианта трактовки этих полигонов:
Для адресации. Тут вопрос курицы и яйца: чтобы так его провести, надо для начала собрать эти адреса на местности или с ПКК, нанести их все вместе с addr:city, а уже потом обводить полигон и, возможно, удалять addr:city с домов. Смысл последних двух действий неясен: если НП уже есть на всех зданиях, то охватывающая его геометрия и не нужна, и незачем удалять правильные теги и городить лишние контура в базе. Если же на части зданий адресов нет, то включать их в полигон НП не сильно лучше, чем вычислять эту часть адреса по ближайшей точке place=* - в любом случае результат будет “на глазок”.
Просто чтобы обвести застройку (не обязательно жилую). Тут большой вопрос, а место ли таким данным в OSM. Это ведь то же самое, что хранить, например, контура обводки водоемов с прибрежными полосами для каких-либо экологических проектов или нарезку для Навитела. Новой информации это не вносит и этому место в своей базе у того, кто использует данные.
Для расчета скоростных ограничений. Тут требуется, чтобы полигон пересекал входящие в город автодороги ровно в тех местах, где стоит табличка начала населенного пункта.
По генплану/СТП. Обновляются редко и хотя в таком виде полигон хоть отдалённо верифицируем, но вряд ли послужит практическим задачам. Потому что границы оттуда могут не обязаны совпадать ни с дорожными знаками, ни с границами существующей застройки, ни с адресами.
Когда урбанист использует полигон place для своего проекта или кто-то делает запрос к нему в Overpass, то он на самом деле вообще не знает, чему будет соответствовать полученная выборка и как трактовать результаты. Табличка на дороге может быть в одном месте, а последний дом с адресом по данному НП - задолго до неё. То есть либо часть домов не посчитается, либо навигатор будет неверно подсказывать. А скорее всего в геометрии будет лежать что-то среднее и не соответствующее ни тому, ни другому. Они используются на данном этапе не от хорошей жизни, а исключительно за неимением более детальной и верифицируемой информации для этих целей. Вот прямо сейчас массово их удалять, пожалуй и правда не стоит.
Поэтому на текущем этапе следует прописать на нашей вики то же, что и в английской: что полагаться на информацию с этих полигонов не следует - ни для адресации, ни для навигации, ни для расчетов. И это действительно соответствует реальности.
А что следует сделать - так это проставлять addr:city на зданиях, реальные скоростные ограничения на дорогах и разметить зоны жилой и прочей застройки, чтобы по ним можно было считать плотность населения. Тогда со временем сами полигоны place станут бесполезными и отомрут естественным порядком. Главное, повторюсь - чёткое указание, что на них не надо завязывать новые процессы и пытаться придавать им какой-то особый смысл.
я бы сказал, на подавляющем меньшинстве, даже в Москве… откуда такие сведения? Вот ВООБЩЕ любой maxspeed - настолько редко он проставлен http://overpass-turbo.eu/s/148R
А RU:rural за городом только на крупных магистралях встречается, и то далеко не везде
Оверпасс меня временно (надеюсь) забанил за превышение квоты запросов с IP адреса, поэтому пришлось оценивать по карте на Taginfo. Я вообще с замиранием сердца думал, что там по России только отдельные пятна будут. Ну что ж, тогда тем больше резона их проставить
Загородные ограничения на применимость place же не влияют. Понятно, что на каждой лесной дороге их проставлять нет смысла, да и непонятно как. А вот по дорогам, которые в пределах нынешних полигонов place и не имеют скоростных ограничений, можно даже в рулетку будет задание соорудить, если ещё не.
Есть ли замечания по предложениям в последних 2 абзацах?
Есть небольшие замечания.
Прописать, что addr:city надо брать в первую очередь с полигона place, что проставлять addr:city на зданиях внутри этого полигона не нужно, что полигоны эти никуда не денутся и не отомрут.
Никакой магии нет. openstreetmap.org всегда показывает последний в списке.
Не понятны несколько моментов:
Как теперь обозначать в OSM сущность из реального мира под названием “Граница населенного пункта”. Если такая сущность есть, чем она удобней (мульти-)полигона с place=*. Если эта сущность вообще не нужна, что делать с аналогичными по смыслу “приблизительно обозначенными” границами районов, городских районов, областей, федеральных округов, заповедников и пр.
Единственный минус сокращенной схемы, указанный в стартпосте - возникновение ошибок адресации повреждении полигона НП. Допустим, мы не используем автоматизированные инструменты контроля качества и находим и исправляем ошибки (опечатки, вандализм, законодательные изменения в адресах) вручную. Что будет проще: отследить и исправить одну линию или все объекты внутри? Спрашивает бывший вахтёр из центральных областей РФ.
В чём вообще проблема? Хотите полную адресацию, пишите addr:place на здании. Никто не возражает, хотя некоторые будут рады, если вы потратите это время на леса в Смоленской области. То же касается ресурсов, потраченных на прописывание и администрирование скоростных режимов. Если ПО не умеет работать с сокращенной схемой, его нужно переписать или предварительно готовить для него данные. Нужна помощь?
Юзкейсов для таких полигонов в практике сильно больше, чем мы расписали в чатике. Завтра придёт человек, который “оспаривает эту схему, ссылаясь на то, что вики-страница не есть результат голосования сообщества”. Какие у нас для него аргументы? И нужны ли Сове наши аргументы? Он обиделся.
В любом случае, в вики необходимо указать, что в России в силу сложившейся практики использования границ населённых пунктов, не рекомендуется их удаление. Для удаления нужно голосование. Но оно вряд ли пройдёт.