Вот картинка, как из верхнего варианта автоматически можно сделать нижний? боты, плагины для josm?
пока никак, только руками.
можно написать плагин для CommandLine.
я потихоньку пишу плагин для работы с отношениями и мультиполигонами, но его ждать долго.
а рендер и конвертеры такое дело понимают?
А смысл? JOSM на такое не ругается, если только линия 3 не должна стать участком границы…
Рендер точно понимает.
Смысл в том, например, что тогда например линия 3 может стать оврагом (забором) или любым другим линейным объектом, без необходимости дублировать точки. Рендеры отлично понимают.
Или например, если линия 3 достаточно сложна, то не приходится ее два раза по одним и тем же точкам рисовать.
Вообщем мультиполигоны на удивление рулят, и вообщем сама по себе сущность довольно хорошая, особенно когда сталкиваешься с рисованием природных объектов, озёр болот лесов, вроме того, как я понимаю в нынешней версии api OSM мультиполигоны рекомендованы к применению. Вот я и думал что может есть какой бот, который приводит из старого варианта в новых с мультиполигонами, вроде задача довольно тривиальная и автоматизируемая.
Это очень спорно. Изначально это просто костыль, нужный, чтобы обойти ограничение апи на 2000 точек в вее.
а я думал, это осознанный шаг на пути к более объектной моделе OSM
liosha, может и костыль, но чертовски удобно, когда вместо десяти веев рисуешь один и включаешь его в полигон (представьте по дороге идут граница области/района/леса/поля/ещё чего-то…) да и вообще, появляется довольно простой способ расширять/уточнять объект, не перерисовывая, а дорисовывая его.
Вот только дорогу приходиться бить на куски. И еще замечательная возможность правя дорогу поломать нафиг границу области, района (это проще всего и в josm не увидишь), лес, поле и что там еще…
Честно говоря не люблю такие мультиполигоны. В большом количестве их юзабилити меньше, да и новичок ногу сломит. Не говоря уже о том что потлатч не так хорошо работает с ними.
Удобство как раз очень сомнительное: вместо одной стандартной геометрии имеется куча кусков, из которых эту геометрию как-то надо собирать. Причём ещё неизвестно, соберётся ли она вообще, потому что никаких средств на уровне апи для её проверки нет.
Ну и отдельная песня про расхлябанную модель данных, в которой однотипные объекты оказываются на двух разных уровнях иерархии.
Ну так для обычных замкнутых веев тоже нет ничего.
liosha насчёт расхлябаной модели данных, с этим пожалуй соглашусь, а вот насчёт мультиполигонов, это пожалуй наоборот шаг к более структурированной системе данных, и к более что-ли “возрослой” картографии, другое дело, что для новичков в редакторе стоит как-то более прозрачно представлять мультиполигоны, а для продвинутых, это пожалуй единственный способ вообще рисовать сложную геометрию, по крайней мере альтернатив не очень-то и видно. Плюс там-же где-то прослеживаются зачатки объектного подхода к данным.
Почему?? Про замкнутый вей всегда известно, что он будет кольцом
Я про разнообразные ошибки типа самопересечений, С-образных полигонов, дублей сегментов и пр.
Кроме того, API не знает какие веи должны быть замкнутыми.
Категорически согласен с этим. Не далее как вчера по бингу выпиливал болото из лесного массива на границе последнего. Без м/п пришлось бы обклацывать два раза.