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

Zkir · 2013-03-01 21:27:07

А хорошо ли это? Есть места где реально только мост и всё, съехать с одной дороги на другую низзя.

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

Last edited by Zkir (2013-03-01 21:27:51)

OverQuantum · 2013-03-01 21:35:24

Zkir wrote:

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

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

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

Zkir · 2013-03-01 21:48:23

Она самая)

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

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

Zkir · 2013-03-02 14:30:27

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

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

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

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

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

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

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

Last edited by Zkir (2013-03-02 14:47:13)

OverQuantum · 2013-03-02 17:53:53

Zkir wrote:

1. Кое-где выпали дороги - похоже на багу алгоритма.
http://Peirce.gis-lab.ru/misc/mp_simp/m … _roads.png

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

Zkir wrote:

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

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

Zkir · 2013-03-02 18:18:09

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

Уполз разбираться. Чую, хитрая засада в ClustersIndex..

.
очень ждем)

OverQuantum · 2013-03-02 19:07:55

Zkir wrote:

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

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

Zkir wrote:

1) Есть ли возможность по RouteParam или иначе сориентироваться, какой тип highway был в исходном osm, включая _link/ не _link?
Да, можно. Перед секцией в мп есть комментарий, в котором сидит исходный тег. (это стандартная выдача osm2mp.pl)
; WayID = 145406054:0
; highway = tertiary
[POLYLINE]
Type=0x05
...

Zkir · 2013-03-02 19:42:29

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

Zkir · 2013-03-02 20:21:39

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

; WayID = 145406054:0
; route=ferry

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

Last edited by Zkir (2013-03-02 20:22:24)

OverQuantum · 2013-03-02 20:45:11

Zkir wrote:

Если бы там было
; WayID = 145406054:0
; route=ferry
Много лучше от этого не стало. Но заменить чем-то 'важность' из highway=* в самом деле не так просто.

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

Zkir wrote:

1. Кое-где выпали дороги - похоже на багу алгоритма.
http://Peirce.gis-lab.ru/misc/mp_simp/m … _roads.png

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

Last edited by OverQuantum (2013-03-02 21:18:33)

Zkir · 2013-03-02 21:16:58

Data0=(48.0127110415158,-0.094733338658369),(48.0128229903524,-9.46952344360793E-02)
GPSMapEdit такого просто не понимает. Исправил

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

Либо это должны быть дороги, либо их не должно быть во входном файле. Фильтрация "не дорог" исходной задачей не предусмотрена.

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

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

OverQuantum · 2013-03-02 21:25:27

Zkir wrote:

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

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

Zkir · 2013-03-02 23:34:32

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

OverQuantum · 2013-03-03 12:27:54

Zkir wrote:

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

Ога, был баг в обработке превышения длины _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 всегда будет среднее арифметическое.

Last edited by OverQuantum (2013-03-03 12:46:25)

Zkir · 2013-03-14 21:47:58

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

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

http://www.openstreetmap.org/?box=yes&b … 2C49.50492

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

Last edited by Zkir (2013-03-14 21:49:54)

Zverik · 2013-03-14 22:09:47

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

KonTur · 2013-03-15 05:24:34

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

OverQuantum · 2013-03-15 21:30:02

Zkir wrote:

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

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

Zkir · 2013-03-15 22:15:02

таким образом B и C можно схлопнуть в одну точку - D

Может я чего-то не понимаю, но если BC можно схлопнуть, то тогда AB и AC можно схлопнуть тем более - эти отрезки короче.

OverQuantum · 2013-03-15 23:19:53

JoinAcute занимается склеиванием близко лежаших отрезков. Находясь в точке A, алгоритм определяет отрезки AB и AC как лежащие достаточно близко для склеивания в один.

Ещё можно Дуглу-Пеккеру эпсилон увеличить, тогда оно этот выступ спилит. 30 метров должно хватить.
Параметры были подобраны, чтобы хорошо обрабатывать улицы и развязки.

Last edited by OverQuantum (2013-03-15 23:25:59)

evgenykatyshev · 2013-04-01 17:34:12

Очень хочется видеть в JOSM слой http://ant.dev.openstreetmap.org/bingimageanalyzer
Оказывается его можно подключить как обычный слой http://ant.dev.openstreetmap.org/bingim … x}/{y}.png

Last edited by lzhl (2013-05-08 13:33:03)

evgenykatyshev · 2013-05-08 13:35:20

Хочется что бы в пресетах JOSM можно было сохранять последние выбранные значения чекбоксов и значений из списка возможных значений.

akks · 2013-05-08 13:55:02

lzhl wrote:

Хочется что бы в пресетах JOSM можно было сохранять последние выбранные значения чекбоксов и значений из списка возможных значений.

Это скорее в тему http://forum.openstreetmap.org/viewtopi … =6513&p=10

Слишком глюкоопасно - теги начнут расставляться сами (выбрали один раз bridge и все дороги начнут делаться мостами). Для этого есть Alt-A и список недавних тегов (Shift-щелками можно добавить несколько)

Zkir · 2013-07-29 18:33:36

Так, небольшой ап темы, чисто информационный.

Упрощалка дорог, разработанная OverQuantum и переписанная freeExec на java, исправно работает, уже не первый месяц, для получения обзорных карт разных стран и карты европейских маршрутов. Каких-то критических проблем пока не выявлено.

Как ни странно я сейчас использую оба варианта, и vb6 и java

Оба комрада от приза отказались, скорее всего в обозримом будущем приз будет назначен за какую-нибудь другую задачу:) Например, жизнь показала, что для еврообзорки нужна не только "упрощалка", но и "латалка дыр".

Об упрощалке, что было сделано и зачем оно нужно, я буду рассказывать в эти выходные на конференции SotM Baltic.

Last edited by Zkir (2013-07-29 18:35:50)

dkiselev · 2013-08-08 19:08:46

Сформулирую задачку, она несколько перекликается с упрощалкой но конечная цель - другая.

Хочется генерить атласы маршрута. Т.е. иметь возможность развернуть ту-же М10 в линию, сохранив километраж вдоль пути, информацию об одновейности/двухвейности, развязках, мостах, паромных переправах, наличии ограждения, прилегающих городах и пои. +Иметь возможность хотябы примерно пересчитывать относительный километраж - в широту долготу.

Если маршрут образует несколько подграфов (есть разрывы) выстраивать участки маршрута последовательно (Вычислить можно апроксимируя множество всех точек полилинией)
Вопрос с колььцевыми маршрутами - открыт.

На вход хотелось бы подавать osm/pbf
Для вывода хотелось бы подключать различные плагинчики.

Инструмент был бы весьма актуален для схем о.т. и длинных трасс/маршрутов.

Last edited by dkiselev (2013-08-08 19:10:54)

#301 2013-03-01 21:27:07

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

#302 2013-03-01 21:35:24

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

#303 2013-03-01 21:48:23

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

#304 2013-03-02 14:30:27

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

#305 2013-03-02 17:53:53

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

#306 2013-03-02 18:18:09

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

#307 2013-03-02 19:07:55

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

#308 2013-03-02 19:42:29

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

#309 2013-03-02 20:21:39

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

#310 2013-03-02 20:45:11

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

#311 2013-03-02 21:16:58

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

#312 2013-03-02 21:25:27

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

#313 2013-03-02 23:34:32

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

#314 2013-03-03 12:27:54

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

#315 2013-03-14 21:47:58

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

#316 2013-03-14 22:09:47

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

#317 2013-03-15 05:24:34

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

#318 2013-03-15 21:30:02

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

#319 2013-03-15 22:15:02

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

#320 2013-03-15 23:19:53

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

#321 2013-04-01 17:34:12

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

#322 2013-05-08 13:35:20

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

#323 2013-05-08 13:55:02

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

#324 2013-07-29 18:33:36

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

#325 2013-08-08 19:08:46

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

Board footer