Хочу заняться Байкалом, привести его в однородный вид. Сейчас там что-то невнятное из четырёх больших кусков и какого-то странного мультиполигона. Если ни у кого нет возражений, то сделаю Байкал одним большим мультиполигоном, в котором будет вся береговая линия из нескольких кусков и все острова.
Комментарии?
Есть ограничение на количество точек в линии. Из-за него приходится рубить на части.
Upliner про Байкал писал здесь: http://forum.openstreetmap.org/viewtopic.php?pid=61116#p61116
Вроде того, что не гоже использовать coastline для внутренних водоёмов. Что гоже - осталось невыясненным.
В данный момент береговая линия Байкала обрисована очень грубо. Если её уточнять, то ограничение на количество точек в полигоне вынудит сделать не четыре полигона, как сейчас, а десятки. Полный отстой будет.
Есть основной недостаток мультиполигона, заключающийся в том, что не выбрав весь мультиполигон не удастся определить, с какой стороны должна быть вода, с какой — суша. С coastline этой проблемы нет.
Это проблема рендерера, не так ли?
Есть гибридное решение - нарисовать мультиполигоном, указав на ways, его составляющих, natural=coastline. По сути-то, верно всё…
Это проблема API, или даже не проблема, а особенность такая. К сами знаете какой фразе это отношение имеет малое.
А вот гибридное решение плохо само по себе - получается, одна сущность обозначена дважды.
Еще помнится, что JOSM иногда ругается на направление полигонов воды, относительно них вроде тоже какая-то договоренность была, наверное такая же как и для костлайнов.
Понятно почему отменили. Одна и та же полилиния может быть как внешней частью острова, так и внутренней частью водоема. А уж в какую сторону рисовать линию, являющуюся границей двух озер при такой договоренности вообще определить нельзя?
Можно, конечно, ввести для мультиполигонов роли для линий (например right/left или inner:right), но тогда из-за порушится совместимость (причем в обе стороны, так как старый софт ждет inner и outer).
Во первых там появилась фича, которая не обрабатывалась старым софтом и не мешала новому понимать все уже наработанное, а здесь придется сломать уже работающее и или городить костыли для понимания старых мультиполигонов или просто их не понимать.
А во вторых я не к тому как накосячили когда придумывали эти мультиполигоны, а к тому как это можно разрулить сейчас.
Наиболее реальным видится вариант с введением своего варианта (например type=advancedpoligon ) и уже его продвигать на замену старому.
Какой-такой полигон? С ними все просто и понятно.
Речь идет о мультиполигонах, причем не о простых, с несколькими кольцами, а о навороченных, где отношение объединяет кучку обрезков линий, которые могут быть берегами реки, озера, островов и континета… ну а заодно и границами нескольких водоемов (реки и водохранилища, двух озер и т.д.)…
Ну почему же, сущность здесь одна - береговая линия. Coastline задаёт линию берега, natural=water в мультиполигоне - область воды.
Зачем роли вводить, если можно рисовать линии сразу в правильном направлении.
Как я понял, аргументы таковы:
coastline для внутренних водоёмов использовать нельзя, почему - не совсем ясно.
multipolygon использовать нельзя, потому что для рендеринга придётся вытаскивать из бд весь полигон, а он большой. Что в этом плохого - мне тоже не ясно. Нагрузка на систему? Ну так не в реалтайме же рендерится, можно и подождать - таких объектов, как Байкал, не так уж и много.
Какие варианты остаются? Верстать блоками из отдельных ways: natural=water, как реки? По-моему, это тоже не правильно, получается много избыточной информации, а на картинках видны швы (но это точно проблема рендерера, так что не в счёт).
Что в итоге?
Настаиваю на мультиполигоне. Метод полностью соответствует правилам рисования и свободен от всяких костылей.