1

Вот картинка, как из верхнего варианта автоматически можно сделать нижний? боты, плагины для josm?

2

пока никак, только руками.
можно написать плагин для CommandLine.
я потихоньку пишу плагин для работы с отношениями и мультиполигонами, но его ждать долго.

3

а рендер и конвертеры такое дело понимают?

4

А смысл? JOSM на такое не ругается, если только линия 3 не должна стать участком границы…

5

Рендер точно понимает.

6

Смысл в том, например, что тогда например линия 3 может стать оврагом (забором) или любым другим линейным объектом, без необходимости дублировать точки. Рендеры отлично понимают.

7

Или например, если линия 3 достаточно сложна, то не приходится ее два раза по одним и тем же точкам рисовать.

8

Вообщем мультиполигоны на удивление рулят, и вообщем сама по себе сущность довольно хорошая, особенно когда сталкиваешься с рисованием природных объектов, озёр болот лесов, вроме того, как я понимаю в нынешней версии api OSM мультиполигоны рекомендованы к применению. Вот я и думал что может есть какой бот, который приводит из старого варианта в новых с мультиполигонами, вроде задача довольно тривиальная и автоматизируемая.

9

Это очень спорно. Изначально это просто костыль, нужный, чтобы обойти ограничение апи на 2000 точек в вее.

10

а я думал, это осознанный шаг на пути к более объектной моделе OSM

11

liosha, может и костыль, но чертовски удобно, когда вместо десяти веев рисуешь один и включаешь его в полигон (представьте по дороге идут граница области/района/леса/поля/ещё чего-то…) да и вообще, появляется довольно простой способ расширять/уточнять объект, не перерисовывая, а дорисовывая его.

12

Вот только дорогу приходиться бить на куски. И еще замечательная возможность правя дорогу поломать нафиг границу области, района (это проще всего и в josm не увидишь), лес, поле и что там еще…

13

Честно говоря не люблю такие мультиполигоны. В большом количестве их юзабилити меньше, да и новичок ногу сломит. Не говоря уже о том что потлатч не так хорошо работает с ними.

14

Удобство как раз очень сомнительное: вместо одной стандартной геометрии имеется куча кусков, из которых эту геометрию как-то надо собирать. Причём ещё неизвестно, соберётся ли она вообще, потому что никаких средств на уровне апи для её проверки нет.

Ну и отдельная песня про расхлябанную модель данных, в которой однотипные объекты оказываются на двух разных уровнях иерархии.

15

Ну так для обычных замкнутых веев тоже нет ничего.

16

liosha насчёт расхлябаной модели данных, с этим пожалуй соглашусь, а вот насчёт мультиполигонов, это пожалуй наоборот шаг к более структурированной системе данных, и к более что-ли “возрослой” картографии, другое дело, что для новичков в редакторе стоит как-то более прозрачно представлять мультиполигоны, а для продвинутых, это пожалуй единственный способ вообще рисовать сложную геометрию, по крайней мере альтернатив не очень-то и видно. Плюс там-же где-то прослеживаются зачатки объектного подхода к данным.

17

Почему?? Про замкнутый вей всегда известно, что он будет кольцом

18

Я про разнообразные ошибки типа самопересечений, С-образных полигонов, дублей сегментов и пр.

19

Кроме того, API не знает какие веи должны быть замкнутыми.

20

Категорически согласен с этим. Не далее как вчера по бингу выпиливал болото из лесного массива на границе последнего. Без м/п пришлось бы обклацывать два раза.