Сейчас для этого есть вот такая штука: https://code.google.com/p/osm2mp-garmin-build/
Оно пока собирает только гармин, но расширить на другие не так уж сложно
CMake заточен под сборку кода. Для сборки карт проще будет использовать обычные Makefile.
Да, простой текст. Изучать не обязательно, обычно достаточно скопипастить пример или нагугленное заклинание :). Для Windows есть GUI, но он для “компиляции” проекта, не для написания.
Больше всего программисты похожи на кота, который приносит своему хозяину мышку, то ли для того, чтобы выразить ему свое расположение, то ли для того чтобы научить его охотиться. Но что человек не ест мышей и не способен на них охотиться, котам невдомек.
Вах, какие аналогии. Только всё поставлено с ног на голову.
Кот просто-напросто поймал мыша, которого можно с удовольствием схавать.
А какой-то странный человек зачем-то взял этого мыша, да ещё и удивляется, что он не поджарен и не под польским соусом.
PS
А возвращаясь к сравнению инструкций, первый пункт оной у osm2dcm оказался
- выклянчайте у Zkir виртуалку
В принципе я уже созрел для переделки этой утилиты на двуплатформенность. Win32 и Ubuntu, они у меня есть.
CMake мне в помощь.
Первый вопрос в который я уперся.
В этой утилите основная кодировка строк это (wchar_t*). Естественно в main() передаются параметры в этой кодировке.
В linux прграммах я могу использовать wchar_t и как настроить CMake под wchar_t?
wchar_t использовать можно, это точно (хоть он и будет разного размера на разных платформах), функции типа wcslen работать будут.
Проблемы могут быть только с _wfopen и WideCharToMultiByte, MultiByteToWideChar , причём иногда - серьёзные.
Ждем более полезного ответа от опытных товарищей.
deep125 Попробовал вашу утилиту на дампе России, в принципе намного быстрее (минут 15) чем загружает в память osm2mp, но из 4 процессорных ядер используется только одно. Возможно как то рапаралелить?
На самом деле не одно a 1.2 ядра. В основном время используется на чтение и запись, а это не паралелится. Хотя идейки на попробывать есть, движок позволяет.
А сколько времени это делает osm2mp?
Я не засекал, но только считывает в память при 32Гб оперативки он несколько часов, в 32гб не влезает и хочет ещё памяти, что берётся за счёт файла подкачки. 32Гб физической + 16Гб файловой памяти на Россию хватает, но время на обработку на Core i7 4.4Гц выходит за двое суток (я так и не дождался окончания).
Для чистоты эксперимента надо ещё попробовать, сколько этот файл винворд читать будет
В самом деле, что с чем сравнить-то хотим?
Меня спросили, я ответил.
Угу, только ответ был раньше вопроса:
“Налил ведро воды, получилось быстрее, чем Вася колет дрова”
liosha О чем спор то? Я написал про утилиту из топика, а так же прокомментировал скорость и прожорливость работы osm2mp. У меня нет претензий, только пожелания.
Вот я и хочу понять, какой глубокий смысл сравнивать скорость работы утилиты из топика со скоростью работы совершенно другой утилиты, да ещё и в нештатном режиме работы.
liosha Не собираюсь спорить. Мне как потребителю нужны “не шашечки, а ехать”.
Дык и куда ехать-то? В sqlite или в mp?
Естественного в этом ничего нет, потому как по стандарту argv - только char*.
wchar_t использовать можно (причём на nix он обычно полноценный utf-32, а не ucs-2/utf-16), но смысл его использовать есть только когда нужна быстрая посимвольная обработка не-ascii строк. Для обычных вещей (типа взять argv и передать в fopen) хватает multibyte строк в char/std::string. Это замечательно работает как с 8bit, так и с utf-8 локалями.
wchar_t - не самый полезный зверь.
В голову приходят boost::locale и ICU, которые могут пригодиться для упрощения жизни. Пока ничего более конкретного посоветовать не могу, будет возможность - залезу в код на выходных.
Add: Кстати, а какой получается размер базы по сравнению с pbf’ным исходником?
спасибо Ivan Komarov и AMDmi3
В рамках этого проекта wchar_t будет заменён на char. utf_8 рулит.
…
размер базы в sqlite ~ в 15 раз больше чем в pbf. Причем это не придел, это без вторичных индексов.