Сборка OSRM - построение маршрутов

Да, печально. Проверил - всё так и есть (уезжает разворачиваться куда попало). C debug-ом там вообще тяжело, библиотеки же отладочные надо (+рабочая папка меняется)…

Иногда неправильно строит даже на крохотном кусочке карты без единого тега oneway, access и без ограничений на поворот. 64-битных ID тоже нет (максимальный - 1859717407): https://dl.dropboxusercontent.com/u/63393258/test2.osm.pbf

Можно для гарантии проверить osrm-routed под Linux, собранный из Windows-совместимых исходников… (проверяю на BSD)
(Может, патч кривоват? Вряд ли, конечно. Скорее всего, какое-нибудь преобразование типов по-другому сработало…)

Мне кажется, либо преобразование типов, либо среди библиотек что-то совсем win32 затесалось.
Под линухом код проверю.

ЗЫ: Можно продолжить по скайпу. Мой nredko

Можно, только у меня микрофона и камеры нет )
Мой код, оказывается, не был в репозитории, теперь вот:
https://github.com/alex85k/Project-OSRM/tree/develop-win

Если кто-то из заинтересованных спецов С++ может найти ошибку или несовместимость c VisualStudio в коде OSRM, приводящую к странным маршрутам - добро пожаловать!
https://github.com/DennisOSRM/Project-OSRM/issues/671
Из-за этого глюка OSRM под Windows неюзабелен… (мне казалось, что в ранней сборке ошибок не было, но это, наверное, не так). У автора нет доступа к VisualStudio (палёным в их краях не пользуются), так что вся надежда на вас )

Express же, нет?

Хмм, наверное - да, спасибо ) Даже консольный Windows 7 SDK может прокатить…
P.S. Уже кормлю его Boost-ом…

Пересобрал ещё раз с помощью Windows 7 SDK из консоли (вот мои батники: https://dl.dropboxusercontent.com/u/63393258/Build_OSRM.zip ) .
extract и prepare стали иногда вылетать, но баг в routed, кажется, куда-то испарился ))
Сборная сборка (2 старых exe +1 новый) на дропбоксе (32 бит не обновлял).
Автору OSRM доложил, он собирается всё проверить и починить.

Да, баг пропал. Оказалось,

abs((long long) id1 -id2 )

был неудачным решением с беззнаковыми длинными числами (long long добавил я из-за ошибки компилятора VS2012)…
Старый бесплатный компилятор из Windows 7 SDK этого не переварил и заставил исправить.

Итог - сборка работает (снова VS2012), Dennis перепроверяет для включения патчей в основную ветку.
P.S. 32бит тоже пересобрал. Желающие могут пособирать и сами - вот скрипты (нужен только ms-компилятор, git, svn, cmake и собранный boost)

Денис тоже хорош… Вот нафига было менять ApproximateDistanceByEuclid на ApproximateEuclideanDistance? Это что, принципиально???
Да и выносить часть функционала из routed.cpp в OSRM.cpp, а после этого делать все остальные бинарники зависимыми от этого OSRM.cpp… Теперь если хочешь перекомпилять routed, потому что присобачил свой плагин - будь любезен перекомпилять и все остальное…

Бл***ть, вот этого я никогда не пойму…

static void DecodeObjectFromBase64(ToEncodeT & object, const std::string& _encoded) {
<< static void DecodeObjectFromBase64(const std::string& input, ObjectT & object) {

Да, зависимости там образуют тот еще клубок (как у кота в лапах побывавший…). В проектах они даже не прописаны - все h-ки где-нибудь да используются… Может, со временем порядок наведется.

Наверное, в какой-нибудь умной книжке сказано, что выходной параметр первым в списке - это фууу)

Ладно, гению простительно :slight_smile: Зато он что-то еще подшаманил, и все стало сильно быстрее.
Под виндой стало работать в разы быстрее, чем раньше под линухом. 26 тысяч точек за 72 секунды против 2.5 тысячи за 56 сек.

А по сравнению с какой версией производительность так выросла?

твоя версия (основанная на develop, как я понимаю?) по сравнению с текущей веткой “мастер”.

Вопрос к знатокам - на OSM нет знаков “Сквозной проезд запрещен”, или их просто не учитывает OSRM?

Подскажите, в чем может быть причина - http://osrm.at/5Li - этот кусок OSRM не видит уже неделю.

Скорее что если функция называется DEcode, то недолжно параметру иметь тип ToENcode. А еще скорее всего где-то есть (или раньше по истории была) функция
static void EncodeObjectToBase64(ToEncodeT & object, const std::string& _encoded),

параметры которой в спешке тупо скопипастили, а теперь вот привели в порядок

Встречал уже такое, написал им в твиттер. Проблема оказалась то ли в ошибке импорта данных из OSM, то ли в их конвертере этих данных, сам алгоритм работал правильно.