Поиск кратчайшего расстояния на графе дорог. Протестируйте

[SS_Rebelious]

То что в хелпе написано - понятно. Нужно просто дополнить информацией о том, как настраивать плагин.

[Voltron]

Она исправлена в 1.8, в 1.7 этого нельзя делать из-за "заморзки" кода.

Эй, какая заморозка? Тут 1.7.4 скоро будет с исправлениями. Ткни меня в коммит, попробую перенести. Или сам сделай. Это же багфикс, если правильно понимаю, а не новый функционал.

[stopa85]

Причины бага две:
1. Сначала я использовал сбалансированные деревья с ключом QgsPoint. Однако они памяти едять в квадрате больше простых массивов (об этом я как-то раньше не задумывался, пока в своп не ушел ).
2. У SS_Rebelious - особенность работы QgsSpatialIndex, пример жуткой регрессии.

Поэтому я переписал почти весь плагин. Появился QgsGraph вместо std::map< std::map< ... > >, библиотека network_analysis вместо utils.h, Стратегии назначения свойств ребрам графа вместо зашитого кода. Топологическая толерантность реализована совсем по другому (и рассчитана только на исправление ошибок округления. Которые иногда в 1е-8, а иногда 1е-4)

Можешь считать меня лентяем, но нужен 49-й pull request. Сойдет за баг-фикс?

UPD: Не можно конечно смержить, а потом подрезать библиотеку network-analysis, но кода, свеженького там будет ого-го.

[stopa85]

Это же багфикс, если правильно понимаю, а не новый функционал.

Я думаю это называется рефатроринг.

[Pifagoroff]

Удалил сообщение...

[Voltron]

Можешь считать меня лентяем, но нужен 49-й pull request. Сойдет за баг-фикс?
------------------------------8< поскипано ------------------------------
UPD: Не можно конечно смержить, а потом подрезать библиотеку network-analysis, но кода, свеженького там будет ого-го.

Ого. Как говорится, внушает. Завтра попробую засунуть в 1.7, о результатах отпишусь.

Я думаю это называется рефатроринг.

Рефакторинг-рефакторингом, но и баги же там исправлялись.

[Максим Дубинин]

Pifagoroff, мне кажется достаточно уже критиковать RoadGraph, ошибки в OSM - не его проблема.

[stopa85]

Рефакторинг-рефакторингом, но и баги же там исправлялись.

Баги исправлялись везде.

А вот с этим

1. Сначала я использовал сбалансированные деревья с ключом QgsPoint. Однако они памяти едять в квадрате больше простых массивов (об этом я как-то раньше не задумывался, пока в своп не ушел ).
2. У SS_Rebelious - особенность работы QgsSpatialIndex, пример жуткой регрессии.

Без рефакторинга ничего не сделаешь.

[Voltron]

К сожалению, в 1.7 исправления не войдут из-за значитеьных изменений в коде, это позиция релиз-менеджера.

[stopa85]

К сожалению, в 1.7 исправления не войдут из-за значитеьных изменений в коде, это позиция релиз-менеджера.

Ну... как бы само-собой.

[Aleksandr Dezhin]

Возможно я что-то не понял, но судя по скриншоту модуль умеет считать корректное расстояние для слоев в WGS84, там показано число и время близкие к реальности. У меня же на слое в WGS84 получается какая-то петрушка - длина все равно в градусах похоже. Переключение СК проекта на меркатор конечно частинчно решает проблему, но может быть прикрутить то, что делали для вычисления длин на геоиде и глобусе?

wrong_length.png (79.97 КБ) 13330 просмотров

[Aleksandr Dezhin]

И еще мне кажется была бы полезна возможность указать "стоимость" прохождения ребра в явном виде, наряду со временем и дистанцией. Я сейчас занимаюсь штукой, которая на на основании osm-файла генерирует корректный роутинговый граф с запретами поворотов и прочими плюшками. Соответственно расширением я пользуюсь, чтобы посмотреть получающийся граф и поэкспериментировать с ним (потом он будет в pgrouting загружен). Расчет стоимости прохождения там получается довольно сложный, и не хочется его пересчитывать в условную скорость.

[stopa85]

Возможно я что-то не понял, но судя по скриншоту модуль умеет считать корректное расстояние для слоев в WGS84, там показано число и время близкие к реальности. ...

Перепроецирование на лету пробовали включать?

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

Сейчас я имею почти готовый surface-cost-analysis (скриншот). И я обдумываю как бы свой road graph и эту хрень объединить единым интерфейсом.
Лучшее что мне приходит в голову это дать пользователю возможность задавать произвольное количество критериев на любой вкус. Крутятся такие варианты:
- "Использовать длину" - просто дистанция,
- "Использовать значение того поля" - предвычисленная стоимость без привязки к дистанции,
- "Длину умножить на значение этого поля" - аналог стоимости,
- "Длину разделить на значение этого поля" - аналог скорости.
Соответственно на растрах вместо "значения этого поля" будет "значение пикселя такого-то слоя".

Пропадет простота, но зато появиться универсальность.
...
Делов то осталось на печенюшку. Надо просто сесть и сделать... а пока могу предложить только консоль python'а

[Aleksandr Dezhin]

Возможно я что-то не понял, но судя по скриншоту модуль умеет считать корректное расстояние для слоев в WGS84, там показано число и время близкие к реальности. ...

Перепроецирование на лету пробовали включать?

Ага, заработало Я просто не ожидал, что этот флаг хоть на что-то влияет при СК слоя = СК проекта.

[Aleksandr Dezhin]

Еще вот какая проблема есть: экспортируем проложенный маршрут во временный слой.
1) В аттрибутике этого слоя нет ни длины, ни времени
2) Если удалить этот слой из проекта без сохранения, то при удалении qgis валиться с сегфолтом.