Актуальные задачи, требующие искусства программирования

Зацепит и зацепит. Наверно я могу и так это потестировать, всем дорогам назначить один тип :slight_smile:

Делать.

Не очень понял почему останутся?

Любое пересечение, даже без общей ноды.

В этой карте некоторые развязки уже отвалились.

Требуется пересечение и рутинговая нода

Zkir

Зацепит и зацепит. Наверно я могу и так это потестировать, всем дорогам назначить один тип :slight_smile:

Объединение двухвеек в одновейки делать?
Делать.
Сделал.
Зрелище душераздирающее. Это с выключенным JoinAcute, с включённым ещё забористее.
Исходник и mp-результат по прямоугольнику Москва-Бологое - тут.
ИМХО, такой хоккей нам не нужен.

Если да, то останутся не объединённые двухвейные дороги в развязках.
Не очень понял почему останутся?
Хм, вроде не остались. Видимо, мои ощущения от старых версий JoinDirections

Любое пересечение, даже без общей ноды.
В этой карте некоторые развязки уже отвалились.
Требуется пересечение и рутинговая нода
А хорошо ли это? Есть места где реально только мост и всё, съехать с одной дороги на другую низзя.
Впрочем, в ближайшее поиск пересечения делать не буду.
Подходящей функции в коде нету, нужно городить новую с учётом всех исключений (попадание точкой на другую дорогу).

Это я выбрал европейские маршруты. Часть развязок естественно отвалилась. но если есть пересечение, 999:1 что есть развязка.
.

А, паневропейская обзорка дорог :slight_smile: Тогда да, с масштабе 2-5 км палюбасу будет переезд с одной дороги на другую.
Только там опять поди отрезков и точек тьма, опять памяти не хватит.

Хм… Ну покрути параметры алгоритма, если получится собрать нечто дающее приемлемый результат без учёта пересечений - тогда подумаем над пересечениями.

Она самая)

Попробую завтра

Так, докладываю о результатах.

Текущая версия mp_extsimp европейскую обзорку пережевывает и дает вполне приличные результаты. Но есть две проблемы.

  1. Кое-где выпали дороги - похоже на багу алгоритма.

До упрощения дорога есть :slight_smile:

  1. Зачем то паромы (0x1b) превратились в дороги.

И конечно отчаянно нужны пересечения.

Сама карта, для тестов, здесь:
http://Peirce.gis-lab.ru/misc/EU-OVRV.zip

Вырезало 0 меридиан, ± ~6 минут (т.е от -0.1 до +0.1 градуса). О_о
Уполз разбираться. Чую, хитрая засада в ClustersIndex…

Это уже вопрос к конвертерации.
Вей - паромный http://www.openstreetmap.org/browse/way/121724962
А в EU-OVRV.mp так:
; WayID = 121724962:0
; highway = trunk

По идее, смотреть на эти комменты вовсе не надо, а смотреть на тип (Type=). За развязки брать 0x08, 0x09, 0x0b. Конвертация-то уже состоялась.

.
очень ждем)

Ненененене, у меня все ходы записаны, я не зря это уточнил сразу же.

Это был ответ на вопрос можно ли :slight_smile:
Почитал код, насколько понял, осм уровень используется в сущности только для сравнения ‘важности’ дорог, что с чем соединять. Правильно?

Если бы там было

Много лучше от этого не стало. Но заменить чем-то ‘важность’ из highway=* в самом деле не так просто.

Ну в общем, всё что загружается из полилиний .mp - попадает в обработчик. Либо это должны быть дороги, либо их не должно быть во входном файле. Фильтрация “не дорог” исходной задачей не предусмотрена.

Ржака.
Data0=(48.0127110415158,-0.094733338658369),(48.0128229903524,-9.46952344360793E-02)
GPSMapEdit такого просто не понимает. Исправил
Пропатчил основную версию на гитхабе.

Смешно. :D. Сейчас потестируем.

Паром - такой же элемент карты, как и дорога. Более того, все полилинии, у которых есть routeparam(s) - дороги.

Но это это я и сам могу пропатчить (когда придумаю что сравнивать в CompareRoadtype()). А вот пересечения бы :wink:

CompareRoadtype - оно про поглощение. Надо добавлять константу в группу HIGHWAY_*, детектировать её по 0x1b и добавлять её в функции GetHighwayType, GetType_by_Highway, GetClass_by_Highway и GetTopLevel_by_Highway

Нельзя ли посмотреть почему такой выброс?

Ога, был баг в обработке превышения длины _link-а, исправил, на гитхабе тоже.
Однако даже с этим багом такого выброса у меня не наблюдалось. Какие параметры использовались?
У меня при EU-OVRV.mp от 2013.03.02 16:49:26 и выложенной мною версии mp_extsimp.bas в 130302.zip было всё нормально.

Обычно такой выброс происходит при глюке функции FindAiming, вычисляющей центроид развязки, когда она прицеливается по осевым линиям дорог при прямой дороге или слабом повороте и итеративный подбор уносит точку вбок.
Регулируется через параметр AngleLimit, передаваемый через CollapseJunctions2. AngleLimit - синус предельного угла, если все дороги сходятся под меньшим углом, то вместо итеративного прицеливания по осевым используется тупое среднее арифметическое, которое всегда внутри развязки, но мажет мимо осевых. AngleLimit=0.13 → 7.47 градуса. Если хотите задать 15 градусов, ставьте AngleLimit=0.26. При AngleLimit=1 всегда будет среднее арифметическое.

Параметры самые стандартные, я в параметрах ничего не меняю. В последней версией с выбросом все стало нормально,

но обнаружились вот такие артефакты:

http://www.openstreetmap.org/?box=yes&bbox=8.01445%2C49.50492%2C8.01445%2C49.50492

Нельзя ли посмотреть, почему они возникают?
Они плохи тем, что мешают искать настоящие тупики.

Слушайте, а почему тема про сбор задач превратилась в общение Zkir и OverQuantum про какую-то упрощалку дорог? Может, разбить?

Потму что упрощалка - это одна из “Актуальных задач, требующие искусства программирования”.
Если тебе не хватает общения - присоединяйся :slight_smile:

Этот артефакт - результат плохой параллельности двух направлений дорог. Даже на скрине видно как направления сходятся к нижнему краю.
Функцию JoinDirections3 от этого “заносит” и она делает приличный излом схлопнутой дороги.
Рисунок
Потом JoinAcute ткнувшись в точку A определяет, что точка C близка к отрезку AB (76 метров) и при этом точка C близка к точке B (96 метров).
Оба эти расстояния меньше длины схлопывания (100 метров) и таким образом B и C можно схлопнуть в одну точку - D. AD таким образом становится тупиком.
ИМХО, надо выправлять параллельность. Либо поставить поменьше длину схлопывания (JoinDistance) - 1й параметр у JoinAcute.