Работая с генпланами обнаружил что в ОСМ есть традиция - рисование границ НП полигонами (часто с landuse=residential на весь НП) которые не имеют никакого отношения к реальным границам. Собственно вопрос состоит из подвопросов:
Вей place=town имеет какое-то отношение к границе города или это просто некая ОСМ-ская абстракция?
Насколько правильно рисовать веи place=town если нет понимания где эта граница проходит?
Насколько я понимаю отсутствие полигона НП это одна из “ошибок” с которыми очень активно боролся один из валидаторов, но я не уверен в этом. Уж очень косвенное отношение к реальности имеет большая часть таких “границ”.
Один из принципов последующего уточнения, тут как раз кстати.
Не то чтобы ошибка, сколько вывалевшийся целый пласт данных при его отсутствии. Просто ещё года 3 назад не было никаких схем от власти, тем более открытых. Поэтому нарисовано по обывательскому представлению территории НП.
Проблема с которой я сталкиваюсь при уточнении данных - открывая JOSM иногда видишь границу НП состоящую из сотен точек и весьма нетривиальную. Очевидная мысль - человек тщательно прорисовал её исходя из какого-то знания, лезть в генпланы требуется какое-то время. Но при открытом плане становится видно что человек просто очень аккуратно рисовал границы НП по кромке леса, границе поля а потом как попало “оп-оп-и-все-готово”. Из-за этого от балды нарисованные объекты кажутся очень качественно сделанными. В результате “масштабы бедствия” кажутся совершенно несущественными.
Кстати, рассматривая границы НП обнаружил что чаще всего в Яндекс/Гуглокартах границы НП чаще всего очень неплохо соответствуют официальным, что конечно не правило но обычно неплохая быстрая проверка чтобы понять что с границами у нас не всё очень хорошо.
Граница населенного пункта нужна в том случае, если в этом населенном пункте уже проставлены имена улицам. Без этого адресный поиск работать не будет.
В остальных случаях, в осутствие точных данных, вполне можно обойтись и точкой.
landuse=residential обозначает “территорию, используемую жилой застройкой”, к административным границам этот тег не имеет никакого отношения, а если он повешен на тот же контур, то это очень грубая абстракция.
Что касается гуглов и яндексов - поскольку им карты делают наемные фрилансеры, они используют то, что им удается получить.
Ровно по этим самым причинам я всегда говорю, что внося любые данные об условном делении (административное деление, собственность, охраняемые природные территории) всегда стоит добавлять source к тому, что вносите или исправляете, чтобы было максимально легко понять потом, откуда это взялось, нужно ли уточнение и так далее. Аналогично http://www.openstreetmap.org/way/116508647
Полигон НП требуется для расчета маршрутизации (например скорость движения внутри НП и снаружи него разная), при обработке адресации - посему отсутствие полигона НП не есть хорошо.
Как правильно отрисовывать небольшие населенные пункты?
Итак, что я понял из ВиКи:
правильно отрисованный населенный пункт должен быть мультиполигоном, состоящим, как минимум, из двух элементов: точки, описывающий данный населенный пункт (label) (для поиска) и внешней границей населенного пункта (для отрисовки на экране и адресного поиска в случае обозначения улиц/домов).
Тэги Label (как точки) и мультиполигона должны быть одинаковые.
Линию внешней границы населенного пункта никак не тэгировать (просто линия, можно указать в NOTE, зачем она тут есть).
Если помимо внешней границы населенного пункта указываются кварталы (или что то иное) с тэгом landuse (indastrial, residental и т.д.) их в мультиполигон не включать.
Но возникли вопросы:
Почему JOSM при проверке ругается на Label?
Обойтись без внешней границы населенного пункта (она как правила непонятна и в большинстве случаев отрисовывается “на глаз”) и включать в мультиполигон полигоны кварталов (с тэгом landuse) можно лишь в случае отсутствия адресного поиска как “временную меру”
Можно ли считать дорожные знаки въезд/выезд в/из населенного пункта (5.23.1; 5.24.1; 5.23.2; 5.24.2; 5.25; 5.26) как место пересечения внешней границы населенного пункта с дорогой.
Прокомментируйте правильность понятого мной.
Ответ желательно давать аргументированный (с ссылкой на правила).
Спасибо.
По п 1. Почему неверно?
Акцентирую внимание: “ПРАВИЛЬНО нарисованный населенный пункт…”
Давайте вопрос на подвопросы разобъем:
Населенный пункт это точка или все же некоторое пространство на плоскости?
Вопрос не в точка не точка, а в мультиполигоне. Он там вообще не при делах. Связь между точкой и полигоном - геометрическая вложенность. Поэтому и все остальные действия с мультиполигоном тут не при делах.
И да считайте, что эти знаки от балды.
насчет знаков - согласен (был уверен, но уже посмотрел и изменил позицию):
ГОСТ Р 52289-2004 “Технические средства организации дорожного движения ПРАВИЛА ПРИМЕНЕНИЯ ДОРОЖНЫХ ЗНАКОВ, РАЗМЕТКИ, СВЕТОФОРОВ, ДОРОЖНЫХ ОГРАЖДЕНИЙ И НАПРАВЛЯЮЩИХ УСТРОЙСТВ”
5.6.28 Знаки 5.23.1 и 5.23.2 «Начало населенного пункта» применяют для обозначения начала населенного пункта, в пределах которого действуют требования Правил дорожного движения, устанавливающие порядок движения в населенных пунктах.
Знаки устанавливают на всех въездах в населенный пункт на фактической границе жилой застройки
Слово “ФАКТИЧЕСКОЙ” является ключевым (Хотя как landuse=residental вполне тянет).
Но насчет остального - спорно.
Точка и полигон - равнозначные объекты.
Мультиполигон - объединяющее понятие (в нем могут быть и точки и полигоны).
Вопрос - нужны ли эти объекты вместе? И тут учитываем рендеры. (Я знаю правило: НЕДОПУСТИМЫ ПРАВКИ ПРИМЕНИТЕЛЬНО К РЕНДЕРУ). Это значит - особенности рендера отображать в дополнительных описаниях.
Я пользуюсь Гармином. Там есть поиск “населенный пункт” и адресный поиск “в пределах населенного пункта”. Для поиска населенного пункта - нужна точка. Для адресного поиска - зона где искать… Следовательно: нужна и точка и полигон.
Нет, мультиполигон — это исключительно последовательность линий, образующих замкнутый контур, иногда с дырками, иногда из нескольких несвязанных частей.
Точки в отношение мультиполигона (type=multipolygon) никогда не включаются.
Есть отношения, похожие по свойствам на мультиполигоны, например, type=boundary. В него могут включаться точки.
Технически, включение точек в мультиполигон и использование роли label - избыточны и нормально не документированы. То есть, если это сделать, то не удивляйтесь, если валидаторы и т.п. будут ругаться. Описание отношения типа “мультиполигон”, естественно, роль label не упоминает: http://wiki.openstreetmap.org/wiki/Relation:multipolygon
Если какой-то софт не умеет сам искать место для подписи, использовать точку place=* и т.п., то внесение данных, которые позволяют влиять на отображение названия в этом софте, а больше никакой нагрузки не несут - это рисование под этот самый софт.
Вы, вероятно, путаете два понятия - multipolygon (мультиполигон) и relation (отношение).
Как я уже сказал выше, отношение типа мультиполигон - документировано, в него входят только линейные объекты (не точки) и роль label для него в документации не определена.
Отношения (вообще, теоретически) могут включать линии и точки, но что это за отношение, для которого роль label для точек документирована?