Спасибо! Действительно на Linux сборка ваша. На Windows после переустановки Perl шел прямым путем по линейке liosha/osm2mp…
Теперь проблемы перевода нет. В очередной раз помогли по полной.
Ещё спрошу для общего развития. В теле getbound.pl значится Log::Any::Adapter 0.11 (‘Stderr’) = у меня ничего не установлено. Или значится Math::Polygon::Tree 0.061 qw/ :all / = в PPM был доступен и я установил версию 0.08.
Всё работает. Файлы территории создаются. Следует ли ожидать подводные камни в этом случае?
Или, каковы преимущества getbound.pl в этой сборке https://github.com/cheshire-mouse/osm-getbound ?
Спасибо!
Библиотеки устанавливаю периодически заново, при обновлении perl. Беру те, что есть на текущий момент в репозитариях. Каких-то проблем не заметил, но и глубоких исследований на тему “что могло поменяться” я не проводил.
В getbound я добавлял опцию clip, она объединяет контур, состоящий из нескольких (операция UNION над полигонами). Это удобно, если для области, которая вам нужна, нет единого отношения. В остальном - фиксы по-мелочам и алиасы.
Помню как на заре была проблема с версиями отдельных модулей. В этот раз на удивление прошло как по маслу.
К вопросу. В этот раз поставил ActivePerl-5.20.3.2004-MSWin32-x64-300558. Порадовал. Все необходимые по умолчанию модули доступны в PPM. Но вот Math::Clipper отсутствует.
Прошу разъяснений и помощи!
Не могу создать poly-файл грницы со смещением (offset).
Раньше создавались без проблем, а сейчас ни в какую.
Может есть у кого готовое решение или это непорядок в моей системе или проект OSM уже не позволяет это сделать?
PS: Надоело создавать файлы вручную…
А в чем заключается “сейчас ни в какую”?
В том, что раньше 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 - спасибо огромное!
Как всегда выручили.
Разобрался… Для работы Вашей “ехе-шной” сборки у меня в папке была лишняя ненужная папка “OsmGetbound” (так и не понял как и когда я её туда отправил/создал ).
Удалил - и всё стало ОК!
Вопрос-1: как создать один общий полифайл из 2.3 и т.д. смежных?
Например иметь один общий полигон на 3 смежные области?
Вопрос-2: какие ограничения и с какой кратностью можно задавать параметр “N” при получении расширенных (оффсетных) границ?
PS: Повторюсь - может где есть подробная справка по ключам и краткому разъяснених их применения?
В теории, можно. На практике… надо подумать. Такой подход с вычитанием выглядит несколько противоестественно, у меня пока не сложилось в голове, как это можно органично вписать.
У меня такой потребности как-то и не возникало. Практически любую область нестандартной конфигурации можно составить из кучи маленьких регионов
Я посмотрю
- сделайте файл с алиасом в формате 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 (все полигоны одной линией, типа рисуем “не отрывая карандаша от бумаги”)
-
N - это отступ в “градусах”, как таковых ограничений нет ( 1, 0.001, 0.00005, …)
-
Если запустить 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 ....