Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

pleshkovpa · 2012-10-03 18:50:37

Zkir wrote:

Перезапустил Украину, баги должны исправиться)

pleshkovpa wrote:

Куда то пропала липецкая область по состоянию на 16:26 03.10.2012. Нету даже в списке sad

Zkir, На текущий момент RU-LIP так и не появилась Может быть Вы посмотрите в чем дело?

Zkir · 2012-10-03 18:56:26

pleshkovpa wrote:

Zkir, На текущий момент RU-LIP так и не появилась Может быть Вы посмотрите в чем дело?

Не стоит так расстраиваться. Ничего непоправимого с ней не случилось. Липецкая область вернется в течение суток.

Last edited by Zkir (2012-10-03 18:57:28)

pleshkovpa · 2012-10-03 19:12:36

Zkir wrote:

Липецкая область вернется в течение суток.

Спасибо

dkiselev · 2012-10-03 20:58:52

Zkir, просто непонятно, под какой юзкейс они сейчас конвертятся в периметр? Это неудобно, что тебя смущает в том чтобы просто их выкидывать?

Zkir · 2012-10-03 21:06:11

Кто они? О чем мы вообще разговариваем?

Last edited by Zkir (2012-10-03 21:06:23)

ttg43 · 2012-10-04 01:45:59

в Кировской области много ошибок из-за связки hw=track до деревни, переходящий в hw=residential в деревне. с хайвеями почти не работаю - как стоит исправлять?
я так понимаю предпочтительнее использовать в данном случае связку hw=unclassified + hw=residential?

Last edited by ttg43 (2012-10-04 01:52:26)

Hind · 2012-10-04 04:03:02

Да. И когда меняете track на что-то выше, рекомендую проставлять surface=ground или смотря что там.

VikDD · 2012-10-04 05:34:42

Zkir wrote:

Почему конвертеры должены все время алгоритмически усложняться, чтобы угнаться за фантазиями графоманов

Это как раз и есть непринятый и неодобренный area:hw=*, а hw=*+area=yes был уже года два точно, как принят.
Ещё раз, проблема не в "карманах", а в площадях (например автодромы). С местными уширениями проезжих частей всё понятно и логично, не понятно почему все вдруг должны подстраиваться под СитиГид?

Monitor · 2012-10-04 05:51:59

Zkir, поправил poly-файл для Нижегородской области https://dl.dropbox.com/u/42229058/NIZ.poly Старался придерживаться всех рекомендаций, но если будут замечания пишите - поправлю.
p.s. прошу обратить внимание в районе Мурома-Навашино линию роли-файла пришлось подвинуть близко к границе области (<1км), т.к. эти города разных областей разделяет только река. Это допустимо?
p.p.s. и еще вопрос по Васильсурску, если делать по границе области то получается дорога изолят, т.к. прямое сообщение из области только паромом. Либо большой крюк по соседней области.

Zkir · 2012-10-04 10:49:38

Monitor, посмотрю.

VikDD

С местными уширениями проезжих частей всё понятно и логично,

Можно поподробнее, что понятно?

не понятно почему все вдруг должны подстраиваться под СитиГид?

Ни в коем случае не надо подстраиваться под Ситигид. Но мапперы должны сделать [электронную] карту, пригодную к конкретным применениям, в частности, к рутингу ( Самые известные рутеры - Навител, Семь Дорог, Гармин, OSRM, Ситигид, и требования у них одни и теже). Для этого ОСМ должен содержать в себе дорожный граф, поскольку все известные науке рутеры работают по дорожному графу. Причем этот граф должен быть простым способом извлекаем из данных осм. А не все более сложным, заумным и жадным до вычислительных ресурсов.

Last edited by Zkir (2012-10-04 11:06:43)

dkiselev · 2012-10-04 13:58:32

Ладно, про площади продолжим если наткнусь на реальные проблемы. Как быть с изолятами на островах?

VikDD · 2012-10-04 14:21:03

Zkir wrote:

С местными уширениями проезжих частей всё понятно и логично,
Можно поподробнее, что понятно?

Линия1:hw=*+width=*(в метрах по ширине проезжей части)
Линия2:area:hw=*, что бы уточнить "контур расширения" и видеть его отрисованным в мапнике/Навителе/Космоснимках/etc.

Zkir · 2012-10-04 14:29:42

dkiselev wrote:

Как быть с изолятами на островах?

Аккуратненько вносить в этот список:
http://wiki.openstreetmap.org/wiki/RU:L … _subgraphs

Должны соблюдаться следующие условия:

1. По дорогам в изоляте хоть на чем-то автомобильном ездят.

если не ездят, нужно дороги переделывать на что-нибудь другое - highway=path|pedestrian|bridleway и т.д.

2. (для островов) Паром или иное регулярное автомобильное сообщение с островом отсутствует.
3. (для деревень) Какая либо автомобильная дорога в большой мир отсутствует вовсе . Доступ по реке, железной дороге, самолетом.

Наличие грунтовки, пусть даже плохой/разбитой, уважительной причиной для добавления в список не является. Единственную грунтовку в населенный пункт следует обозначать highway=unclassifies+surface=unpaved.

Last edited by Zkir (2012-10-04 14:33:56)

dkiselev · 2012-10-04 15:10:08

Там всамделешные острова - речь о Хорватии. А с паромом, поразбираюсь на часть островов он есть.

Zkir · 2012-10-04 15:17:00

VikDD wrote:

Линия1:hw=*+width=*(в метрах по ширине проезжей части)
Линия2:area:hw=*, что бы уточнить "контур расширения" и видеть его отрисованным в мапнике/Навителе/Космоснимках/etc.

Я с этим согласен 100%. Но практика в некоторых регионах, к сожалению, ровно обратная, обозначать карманы hw=service+area=yes, много такого добра: http://peirce.gis-lab.ru/qa/RU-CU-bak/rd-map. Вопрос: мне к нему надо приспосабливаться(если да то как), или переобозначить area:hw=service?

dkiselev wrote:

Там всамделешные острова - речь о Хорватии. А с паромом, поразбираюсь на часть островов он есть.

Если есть, лучше всего его просто обозначить, как здесь написано

Last edited by Zkir (2012-10-04 15:21:22)

andriano · 2012-10-04 17:02:27

Zkir wrote:

Валидатор работает по актуальным данным...
...Напомню, выгрузки в Ситигид делаются для тех карт, которые получили в валидаторе оценки A и B.

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

Собственно, этот порочный круг давно знаком и для него существуют стандартные методы борьбы, из которых можно отметить, минимум, два:
1. Доступ ко всему архиву версий.
2. Доступ к двум версиям: текущей и последней стабильной.

PS. Посмотрел - информация обновилась.

Last edited by andriano (2012-10-04 17:15:01)

esaulenka · 2012-10-04 17:24:12

andriano wrote:

валидатор запускается "по актуальным данным", т.е. по выгрузкам.

это неверное утверждение

Sergey Astakhov · 2012-10-04 17:24:20

andriano wrote:

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

Не так. Ошибки в валидаторе просто не пропускают выгрузку на следующий этап (формирование конечной карты).

Zkir · 2012-10-04 19:57:25

Обновились RU-NIZ и RU-SAM с новыми границами.
Проверяйте что получилось.

andriano · 2012-10-05 17:13:12

Sergey Astakhov wrote:

Не так. Ошибки в валидаторе просто не пропускают выгрузку на следующий этап (формирование конечной карты).

Значит, я неверно понял, что подразумевается под "актуальными данными".
В принципе, указанный подход логичен, хотелось бы только знать постоянную времени обновления информации в валидаторе. Я считал, что она не превышает 2-3 дней, поэтому и поднял вопрос.

Zkir · 2012-10-05 22:46:53

andriano wrote:

Хотелось бы только знать постоянную времени обновления информации в валидаторе.

Она не вполне постоянная, и зависит от привходящих факторов (обновилась ли выгрузка на гислабе, и удалось ли ее скачать). Текущее значение можно посмотреть тут: http://peirce.gis-lab.ru/rss

В этом отчете она называется "Показатель латентности III" и рассчитывается как средняя разница* между текущим моментом времени и последней известной правкой. * Среднее значение считается по картам RU-xxx, т.е. в этом показателе учитывается только Россия

На данный момент значение "постоянной" 2.6 дней

Last edited by Zkir (2012-10-05 22:50:41)

andriano · 2012-10-06 08:56:19

Zkir wrote:

Текущее значение можно посмотреть тут: http://peirce.gis-lab.ru/rss

Ну, средняя температура по больнице малоинформативна.
Лично я столкнулся со следующим:

- дата обновления данных валидатора по интересующему региону - свежая (в пределах 2 дней),
- дата обновления карт для Ситигид по тому же региону - старая (более 2 месяцев назад),
- валидатор "не видит" исправлений, которые внесены 3-5 дней назад,
- при этом по другому региону исправления становятся видимыми примерно через 2 дня,
и еще одно:
- валидатор работает с данными ПОСЛЕ конвертации в формат Ситигид, а не с оригинальными ОСМ-данными.

и какие выводы я мог из этого сделать? Только то, что конвертация в Ситигид приостановлена более 2 месяцев назад, а валидатор работает с последней (т.е. двухмесячной) выгрузкой.
Кстати, этому выводу не противоречит тот факт, что среднее время ожидания составляет 2.6 дня.

И еще, мне непонятен смысл средней величины в данном контексте.
Если у нас происходит регулярная обработка данных: с периодом одну минуту, одни сутки лил один месяц - этот период и есть постоянная времени. В этом случае подсчет средней величины неинформативен, т.к. постоянная времени будет мало отличаться от заданной извне константы - только за счет "плавающих" времен обработки отдельных частей.
Если обработка происходит по каким-то статистическим факторам (например, после каждого изменения либо по накоплении определенного количества изменений), то подсчет среднего целесообразен и интересен, т.к. помимо прочего характеризует интенсивность процесса, вызывающего необходимость обработки. Но если у нас часть данных обрабатывается регулярно, а часть обработки приостановлена, среднее теряет свою информативность, т.к. неверно характеризует как период обновления обрабатываемых данных, так и прогноз на обновление исключенных из обработки.

NetWormKido · 2012-10-06 09:51:36

Zkir wrote:

Обновились RU-NIZ и RU-SAM с новыми границами.
Проверяйте что получилось.

У меня вроде нормально (RU-SAM).

Zkir · 2012-10-06 10:11:42

валидатор работает с данными ПОСЛЕ конвертации в формат Ситигид, а не с оригинальными ОСМ-данными.

Это самый тонкий вопрос. "Оригинальные ОСМ-данные" совершенно не пригодны к какому либо использованию, в том числе к валидации. Тот же дорожный граф нужно сперва вычленить, при помощи довольно мутных правил. Тут играем, тут не играем, тут жирное пятно, тут рыбу заворачивали.
Про адресный реестр я вообще молчу.

Поэтому валидатор работает по польскому файлу, который является промежуточным этапом конверсии [osm-->mp-->cgmap]

И еще, мне непонятен смысл средней величины в данном контексте.

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

Так вот, набор регулярно обновляемых карт (Россия, СНГ, избранные страны) обновляется менее чем за двое суток (1.8). Среднее время, которое проходит между правкой в осм и попаданием этой правки в выдачу валидатора - 2.6 суток.

Ну, средняя температура по больнице малоинформативна.

А какую ты хочешь? Индивидуальная написана на каждом пациенте, например:

Код карты RU-PSK
Название карты Псковская обл.
Дата прохода валидатора 2012-10-06
Последняя известная правка 05.10.2012 23:08:46 (UTC)

интенсивность процесса, вызывающего необходимость обработки.

Нет, такой роскоши как обработка в зависимости от интенсивности процесса, например процесса починки багов, пока нет. Но хотелось бы)

Last edited by Zkir (2012-10-06 10:23:42)

Hind · 2012-10-06 11:02:14

А можно писать не только дату, но и время прохода валидатора? :3

Announcement

#976 2012-10-03 18:50:37

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#977 2012-10-03 18:56:26

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#978 2012-10-03 19:12:36

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#979 2012-10-03 20:58:52

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#980 2012-10-03 21:06:11

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#981 2012-10-04 01:45:59

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#982 2012-10-04 04:03:02

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#983 2012-10-04 05:34:42

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#984 2012-10-04 05:51:59

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#985 2012-10-04 10:49:38

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#986 2012-10-04 13:58:32

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#987 2012-10-04 14:21:03

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#988 2012-10-04 14:29:42

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#989 2012-10-04 15:10:08

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#990 2012-10-04 15:17:00

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#991 2012-10-04 17:02:27

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#992 2012-10-04 17:24:12

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#993 2012-10-04 17:24:20

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#994 2012-10-04 19:57:25

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#995 2012-10-05 17:13:12

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#996 2012-10-05 22:46:53

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#997 2012-10-06 08:56:19

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#998 2012-10-06 09:51:36

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#999 2012-10-06 10:11:42

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

#1000 2012-10-06 11:02:14

Re: Универсальный валидатор (рутинг, адресация) на базе конвертации в СГ

Board footer