Конвертер OSM -> MP

Помню как на заре была проблема с версиями отдельных модулей. В этот раз на удивление прошло как по маслу.
К вопросу. В этот раз поставил ActivePerl-5.20.3.2004-MSWin32-x64-300558. Порадовал. Все необходимые по умолчанию модули доступны в PPM. Но вот Math::Clipper отсутствует.

Прошу разъяснений и помощи!
Не могу создать poly-файл грницы со смещением (offset).
Раньше создавались без проблем, а сейчас ни в какую.
Может есть у кого готовое решение или это непорядок в моей системе или проект OSM уже не позволяет это сделать?

PS: Надоело создавать файлы вручную… :frowning:

А в чем заключается “сейчас ни в какую”?

В том, что раньше exe-шная версия прекрасно работала для получения границ со смещением, а сейча вообще никакая веряия не создаёт.
Perl-овская при создании вываливается в ошибку с указанием на Match::Clipper::offset.
Пробовал разные "Clipper"ы устанавливать, но в конечном итоге это ничего не даёт.
Папки Match/Clipper/offset (с файлом Clipper.pm) в наличии.
Вот и не пойму в чём дело…

Что-то намудрили, мне кажется, с библиотеками. Папки offset быть не должно. Должно быть как-то так Math/Clipper.pm

Проверьте, что библиотека подключена:

perl -le 'use Math::Clipper; print $Math::Clipper::VERSION'
1.23

А если скачать по ссылке в самом верху этой страницы? У меня она нормально отрабатывает все функции, в том числе и оффсет, которым пользуюсь постоянно.

gryphon Просил уже, но попробую ещё раз. А реально допилить getbound, чтобы из релейшена границы можно было вычитать другой релейшен? Пока только складывать их можно.
Пример: Хочу собрать границу Украины без Крыма, Границу Грузии без Абхазии и Южной Осетии и т.п.

Не проходит у меня данная проверка (ни с одинарными ни с двойными кавычками).
Файл Clipper.pm уже куда только не “размножил”, но результата нет.
Пробовал подключить данный модуль через cpan, но это так же ничего не изменило (хотя на экране что-то там мелькало зелёным текстом и достаточно долго - более 1 минуты).

Ну конечно же пробовал. Данная сборка у меня вообще ничего не отрабатывает, поэтому пользуюсь Perl-овской.
И что самое интересное - раньше на 32-й сборке Perl и ехе-шника всё работало, а вот с переходом на Win7+Perl64, стало как-то не совсем так.

**PS: **А можно вообще где-то ознакомиться со всеми ключами и их применением? Что-то справки я не нашёл в файлах (не вызывается).

Kostik - спасибо огромное!
Как всегда выручили. :smiley:
Разобрался… Для работы Вашей “ехе-шной” сборки у меня в папке была лишняя ненужная папка “OsmGetbound” (так и не понял как и когда я её туда отправил/создал :confused: ).
Удалил - и всё стало ОК!

Вопрос-1: как создать один общий полифайл из 2.3 и т.д. смежных?
Например иметь один общий полигон на 3 смежные области?

Вопрос-2: какие ограничения и с какой кратностью можно задавать параметр “N” при получении расширенных (оффсетных) границ?

PS: Повторюсь - может где есть подробная справка по ключам и краткому разъяснених их применения?

В теории, можно. На практике… надо подумать. Такой подход с вычитанием выглядит несколько противоестественно, у меня пока не сложилось в голове, как это можно органично вписать.

У меня такой потребности как-то и не возникало. Практически любую область нестандартной конфигурации можно составить из кучи маленьких регионов

Я посмотрю

  1. сделайте файл с алиасом в формате yaml, в нем текстовому имени ставится в соответствие идентификатор отношения или же массив идентификаторов, как то так
myregion: [12345, 12346] 

(вот еще пример https://github.com/cheshire-mouse/osm-getbound/blob/master/aliases.d/finland.yml )
далее загружайте границу уже по этому имени, а не по id, указав ваш файл через опцию aliases

getbound.pl --aliases myaliases.yml myregion

полезными буду опции clip (сложить все полигоны) и onering (все полигоны одной линией, типа рисуем “не отрывая карандаша от бумаги”)

  1. N - это отступ в “градусах”, как таковых ограничений нет ( 1, 0.001, 0.00005, …)

  2. Если запустить getbound без параметров, он должен выдать список всех опций с краткими пояснениями

Понял - спасибки!
Ну и последний вопрос на текущий момент времени…
Как правильно понимать вот такую запись уровней в конфигах?:

level_h: [ 0, 0.016, 0.5, 2.5, 9 ]

Видимо через запятую кол-во уровней на которых происходит корректировка - так?
И главное - доли после точки, это как понимать физически?
Это отношение какое-то?
И относительно чего отношение и как они (эти отношения/записи) влияют?
Я пробовал и видно, что уровни как бы расширяются (подобие “LevelRange”), но в чём изюминка данной записи, по сравнению с LevelRange?

До какого уровня отображаются объекты в зависимости от их площади.

А если более конкретно?
Например в первом уровне есть запись 0.016 - это как понимать?
Или запись в 3-м уровне 2.5 - это как понимать?
Разве нельзя в зависимости от площади того или иного объекта (например полигон), прописать просто level_h:3?
Хочу понять физическое отличие в той или иной записи прописывания уровней и как понимать относительность значения цифр.

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

Попробуй. Пока в отдельной ветке testing.
https://github.com/cheshire-mouse/osm-getbound/tree/testing

Принцип простой: все отрицательные id-шники, которые добавлены в алиас, будут вычитаться из контура (по факту, просто инвертироваться outer → inner и наоборот). Немного поменялся алгоритм обработки ключа clip, раньше он работал немного неправильно (в 99% случаев это не будет заметно).

Спасибо, всё работает. Правда немного не разобрался как подсунуть свой файл .yml, сработало только когда отредактировал osm-getbound-aliases.yml

там две опции для подключения алиасов: aliases для отдельного файла, aliasesdir для каталога с файлами
у меня выглядит как-то так:

getbound.pl -api op_ru -singlerequest -aliases /garmin/getbound/etc/osm-getbound-aliases.yml -aliasesdir /garmin/getbound/aliases.d ....

Ну это в целом и так понятно было.
Вы ответили так, как будто бы самого ответа на вопрос(ы) вовсе и нет. :sunglasses:
Мои вопросы остались совершенно незамеченными:

Это отношение какое-то?
И относительно чего отношение?
Напрмер имеется полигон 100х100 метров.
Так вот… как понимать скажем число 0.016, 3.5 или 9 по отношению к данному размеру (площади) полигона?
Число 9 - это что?
В 9 раз мешьше?
В 9 раз больше?
Это масштаб производной отношения S/9?
И так далее…
И второй “незамеченный” вопрос - чем такая запись отличается по сравнению с примененнм level_*= * по отношению этого же самого полигона?
Неужели трудно вразумительно и конкретно ответить? :confused:

О финальном релизе, информация будет?

Про цифры - трудно. Все это было настроено настолько давно, что уже забылось за ненадобностью. Может быть есть в начальной части темы, а может я у Леши в аське интересовался…

Одна строка определяет сразу все варианты.

Если не путаю, то это квадратные километры (Землю считаем шаром)

Тут нет таких понятий, как релизы. Мне что-то понадобилось - добавляю и заливаю в репозитарий. Отдельная ветка сделана, т.к. не был уверен, в каком виде это впиливать, но раз у Kostik все заработало, наверное, так и оставлю.

Ну а что касается документации в целом, то “программа подробно задокументирована на языке perl” (c)
К сожалению, кроме https://wiki.openstreetmap.org/wiki/RU:Osm2mp , ничего нет. Т.е. если вам действительно приглянулся этот конвертер, чтобы разобраться во всех тонких моментах, иногда придется погружаться в чтение исходников. Ну а если вы узнали что-то новое и можете пополнить этим wiki, будет замечательно.