И раньше были сомнения по поводу логики работы конвертера в вопросе выбора языка для выходного набора. Теперь сомнения обрели практическое обрамление.
Для примера беру Украину. Традиционный вариант - “target_lang: ru”, “default_lang: uk”. Надежда выудить все Русские наименования, а в случае отсутствия взять Украинские наименования и перевести. Для перевода задействован “–lt-yatr-key @list.key”.
и всё бы ничего, но обратил внимание - при отсутствии “name:ru” почему то тянется “name:en” вместо наличествующего “name:uk”? И не переводится?!
не потому ли что “name:uk” стоит ниже “name:en” по алфавиту? Почему не сработало прямое указание на “default_lang: uk”, как это возможно?
при этом есть просто “nane” и оно игнорируется (хотя стоит выше всех)?!
для меня давно напрашивалось оставить по умолчанию именно “name”, а не “name:uk”. Как это сделать? Не указывать “default_lang:”? Если “default” не указать, то какая последовательность будет для выбора языка по умолчанию?
опять же, если не указать “default”, то и перевод не состоится?! Яндексу надо знать с какого на какой переводить.
Я уже молчу про settings.yml. В какой взаимосвязи находится “label” с “target_lang:” и “default_lang:”. Попробовал в “label” загнать приоритеты в виде [‘name:ru’, ‘name:uk’, name ] и всё! Русский получил преимущество, Украинский встал на второе место…,
Разъясните приоритеты если можно. И может ли такое быть, что “default_lang:” не срабатывает? Может быть причина в том, что “target_lang: ru”, “default_lang: uk” включил не в командную строку, а в “navitel.cfg”?
Спасибо.
Объясните пожалуйста, если резать страну по регионам, ломается роутинг (не строятся маршруты из одной области в другую)
Знаю что на месте где идет обрезка, на дорогах должено появлятся свойство что эта точка external_node.
Какой ключ нужно использовать в osm2mp чтобы external_node появляся, при обрезке страны по регионам?
если речь про конструктор - то в GUI режиме может, см. Multi Chart… в пакетном - вряд ли
имхо смысла нет - увеличение времени конвертации растет по экспоненте в косвенной зависимости от объема польского.
по моим замерам - исходники до 100 мегабайт конвертятся в dcm несколько минут, около 150 - уже порядка 20 минут.
опять-таки - оперативка не резиновая, да и не забываем про ограничение для 32х битного приложения.
зы. если mplua еще интересует - могу выложить
Странно, у меня на дороге создаются два внешних нода, с одной и другой строны обрезки. А не может быть, что Ваша обрезка захватывает шире, чем граница дампа, и не пересекает дороги?
Marych73
Я режу osmconvert`ом по офсетным границам (чуть большего размера) с ключами -v --drop-author --emulate-osmosis --complete-ways --complex-ways, а потом конвертирую уже по точным. Всё стыкуется отлично.
У кого то сохранились старые версии getbound.pl? Пытаюсь на Linux запустить под perl 5.22, osm2mp там заработал как часы, а с getbound`ом засада. У меня две версии с разными ошибками не запускаются.
PS: Устал от глюков perl под виндой. Карты выборочно вылетают при конвертации, а под Linux те же самые без проблем.
user@user-linux-pc ~/Russia/getbound $ ./getbound.pl 60189 -o Russia.poly -onering
Smartmatch is experimental at lib/App/OsmGetbound/OsmApiClient.pm line 163.
Smartmatch is experimental at lib/App/OsmGetbound/OsmApiClient.pm line 167.
Smartmatch is experimental at ./getbound.pl line 154.
Downloading relation ID=60189
GET http://www.openstreetmap.org/api/0.6/relation/60189/full
Strings with code points over 0xFF may not be mapped into in-memory file handles
Can't open 'SCALAR(0x240b800)' for reading: 'Invalid argument' at lib/App/OsmGetbound/OsmData.pm line 94
Файл poly при этом не создаётся.
user@user-linux-pc ~/getbound1 $ ./getbound.pl 60189 -o Russia.poly -onering
Smartmatch is experimental at ./getbound.pl line 147.
Smartmatch is experimental at ./getbound.pl line 442.
Smartmatch is experimental at ./getbound.pl line 446.
Downloading relation ID=60189
GET http://www.openstreetmap.org/api/0.6/relation/60189/full
Strings with code points over 0xFF may not be mapped into in-memory file handles
read error at /usr/lib/x86_64-linux-gnu/perl5/5.22/XML/Parser/Expat.pm line 474.
Продолжил эксперименты с perl но уже в Windows x64, поставил strawberry-perl-5.24.1.1-64bit.msi, к инструкции в wiki дополнительно выполнил:
cpan -i match::smart Sub::Infix File::Slurp
osm2mp запускается без проблем, а вот с getbound те же самые проблемы что и в Linux:
C:\osm2mp\getbound>perl getbound.pl 60189 -o Russia.poly -onering
Smartmatch is experimental at lib/App/OsmGetbound/OsmApiClient.pm line 163.
Smartmatch is experimental at lib/App/OsmGetbound/OsmApiClient.pm line 167.
Smartmatch is experimental at getbound.pl line 154.
Downloading relation ID=60189
GET http://www.openstreetmap.org/api/0.6/relation/60189/full
Strings with code points over 0xFF may not be mapped into in-memory file handles
Can't open 'SCALAR(0x28b0660)' for reading: 'Invalid argument' at lib/App/OsmGet
bound/OsmData.pm line 94
PS: Но тут хотя бы имеется возможность установить более старую версию strawberry-perl, благо все дистрибутивы доступны в отличии от activestate perl. А в Linux на Perl завязана графическая оболочка.
PPS: Поспешил что osm2mp без проблем, файл примера из wiki в конце выдаёт ошибку, но файл MP создаётся:
All done!!
(in cleanup) Can't call method "DESTROY" on an undefined value at C:/osm
2mp1/lib/OSM.pm line 59 during global destruction.
Продолжил экспериментировать с strawberry-perl, опробовал помимо 5.24 ещё версии 5.20, 5.18 и 5.16.
getbound работает тока на 5.16. На 5.24-5.20 модули ставятся ощутимо быстрее, начиная с 5.18 начинают заметно медленнее ставиться и какие то модули перестают устанавливаться (например PerlIO::encoding). В связи с разницей в скорости установки модулей было бы интересно сравнить скорость конвертации эталонного файла. Не уверен что версия perl может влиять на скорость конвертации, но всё же.
user@user-linux-pc ~/getbound1 $ ./getbound.pl 60189 -o Russia.poly -onering
Smartmatch is experimental at /home/user/getbound1/lib/App/OsmGetbound/OsmApiClient.pm line 169.
Smartmatch is experimental at /home/user/getbound1/lib/App/OsmGetbound/OsmApiClient.pm line 174.
Smartmatch is experimental at ./getbound.pl line 201.
Name "main::DIR_ALIASES" used only once: possible typo at ./getbound.pl line 113.
Downloading relation ID=60189
GET http://www.openstreetmap.org/api/0.6/relation/60189/full
Creating polygons
Merging rings
Writing
All Ok
Я им активно пользовался, но в последнее время у них могут быть версии старше месяца по сравнению с основной базой. Поубирал везде, а вот немецким зеркалом наоборот стал пользоваться.
А можно по некоторым дополнительным ключам пояснить? Приведу тока те что не до конца понятны:
-singlerequest - download relations in a single request
(overpass only) одиночный запрос, зачем?
-file - use local OSM dump as input файл osm из которого будет браться релейшен?
-srcout - save OSM xml into file
(works for single relation or
for single request mode) что то вроде дампера всех данных внутри релейшина?
-clip - clip (union) rings Замыкает кольцо с разрывом (ошибкой в данных)?
-noinner - exclude inner rings from processing Предположу что убирает innerы, оставляя только outerы?
-writer - writer to use Добавляет подпись того кто выкачивает релейшин в нём?
-om - something to do with writer ?
-offset|buffer - enlarge resulting area by moving bound N degrees С offset понятно. А buffer?
Загружает все отношения одним overpass запросом. Позволяет избежать бана при загрузке большого количества границ, состоящих из нескольких отношений.
Сохраняет osm-файл, загруженный с сервера для повторного использования. Я использую, когда нужно сделать два poly для одного отношения (с offset и без), так быстрее и, опять же , меньше шансов, что забанят.
Объединяет соседние полигоны в один, удобно, если нужно собрать карту нескольких соседних областей.
noinner - вроде так
writer/om - как я понимаю, определяют формат вывода, на данный момент есть только poly
buffer - просто синоним offset