Протокол взаимодействия в валидаторами

Alno · 2012-04-19T14:39:25.000Z

Zkir:

закачивал бы результаты валидаторов, показывал бы ошибки как ошибки

Именно это и планируется. И именно для этого предполагается использовать запрос по BBOX.

Zkir:

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

Я лично об этом не думал, возможно у Евгения были такие планы, но я не вижу принципиальных проблем это реализовать (с хранением отметов о фиксах в базе openstreetmap.ru).

Но тут есть проблема - ошибка, помеченная как пофикшенная на openstreetmap.ru не будет отображаться как таковая в каком-то другом месте, где отображаются данные валидаторов. То есть, в идеале за отметками о фиксах должен бы следить сам валидатор. Но будет ли он это делать?

Alno · 2012-04-19T14:42:16.000Z

PShA:

Это лечится введением идентификаторов ошибок на время между обновлениями. Благо они у всех есть в том или ином виде.

На самом деле это не является обязательным требованием к валидатору.

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

ErshKUS · 2012-04-19T15:17:04.000Z

А в связи с обновлением валидаторов, а завел тему http://forum.openstreetmap.org/viewtopic.php?id=16283 , и тогда можно будет клипать валидаторы с часовым интервалом обновления но это так, на будущее и те кто хочет работать с симпл схемой

Zkir · 2012-04-19T15:26:56.000Z

То есть, в идеале за отметками о фиксах должен бы следить сам валидатор.

Как раз валидатор следить за фиксами НЕ должен. Его задача простая - пройтись по данным и выплюнуть список ошибок. Следить же за фиксами должен багтрекер.

Но будет ли он это делать?

Мои - в ближайшее время не будут.

Но тут есть проблема - ошибка, помеченная как пофикшенная на openstreetmap.ru не будет отображаться как таковая в каком-то другом месте

По-моему, это совсем не проблема. Насколько я понимаю, openstreetmap.ru как раз и задумывается как то место, гда пользователи должны смотреть на данные валидаторов (универсальное рабочее место пользователя).

И я так и не понял зачем нужен BBOX. Не легче ли раз в сутки (или в указанный интервал работы валидатора) зачитать его данные оптом?

Larry0ua · 2012-04-19T15:45:36.000Z

Может так?
Валидатор - средство нахождения ошибок. По обновлению валидатора он дергает осмру и отдает ему файл/линк на файл со всем списком ошибок. Тогда осмру - средство отображения ошибок. Там их можно помечать закрытыми, комментировать и т.д (если надо).

Правда, нагрузка на сайт возрастет значительно…

А я уж думал, дело зашло о средстве обновления для валидаторов - чтоб они с минутными/часовыми диффами работали и были постоянно up-to-date и выдавали диффы ошибок, а не парсили всю страну-планету, например… Ускорение должно быть значительное, если правильно поставить на поток, ну и запускать их можно будет чаще
Можно это дело совместить - валидаторы будут дергать на осмру только новые и закрытые баги за свой период обновления, а у ошибок будут статусы:

новый баг (получили от валидатора, никто не фиксил)
закрытый пользователем (ждем от валидатора подтверждения закрытия)
закрытый-ошибка (валидатор не подтвердил закрытие после обновления)
закрытый-проверенный (удаляется через день/неделю после обновления валидатора)

//upd - похоже, про минутные валидаторы - это к соседней теме, точно

Alno · 2012-04-19T15:54:23.000Z

Zkir:

Как раз валидатор следить за фиксами НЕ должен. Его задача простая - пройтись по данным и выплюнуть список ошибок. Следить же за фиксами должен багтрекер.

Ок, вообщем-то согласен, но нужен этот багтрекер. Пока делаем взаимодействие с валидаторами напрямую, потом скорее всего допишем функции багтрекера на openstreetmap.ru или еще куда. Не все сразу.

Zkir:

Мои - в ближайшее время не будут.

Я прекрасно вас понимаю в этом. Думаю, что другие авторы валидаторов тоже не имеют желания добавлять валидатору эти функции.

Zkir:

По-моему, это совсем не проблема. Насколько я понимаю, openstreetmap.ru как раз и задумывается как то место, гда пользователи должны смотреть на данные валидаторов (универсальное рабочее место пользователя).

Лично мое мнение - есть еще пользователи openstreetmap.by и openstreetmap.org. А еще могут появиться пользователи деревни X, которые запили свой сайт и хотят видеть результаты валидации на нем.

Zkir:

И я так и не понял зачем нужен BBOX. Не легче ли раз в сутки (или в указанный интервал работы валидатора) зачитать его данные оптом?

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

PShA · 2012-04-19T16:23:34.000Z

Запрос по ббоксу нужен для того чтоб можно было подключать левые валидаторы простой ссылкой, а не качать-разворачивать.
Если валидаторописать не хочет сам предоставлять такой сервис можно сваять простенький сервер, который будет отдавать полученный от валидатора дамп.
Не принципиально

Zkir · 2012-04-19T19:18:48.000Z

подключать левые валидаторы простой ссылкой

Это что за наезд такой, что значит левые???

Такая простая агрегация вряд ли прокатит. Вот универсальный багтрекер было бы клево. Хорошо что понимание этого кажется есть.)

Еще несколько замечаний.
Подумайте вот над чем. В одном валидаторе может быть несколько тестов, а в каждом тесте несколько типов ошибок. Поэтому было бы разумно, если бы валидатор отдавал описания ошибок тоже, вместе с краткой рекомендацией как ее починить. Как например здесь: http://peirce.gis-lab.info/qa/RU-SPO#errdescr

Что могу предложить лично я.
Есть xml’и с результатами валидации. Находятся здесь:
peirce.gis-lab.info/ADDR_CHK/{код карты по ISO 3166}.mp_addr.xml

Например: http://peirce.gis-lab.info/ADDR_CHK/RU-MOS.mp_addr.xml

Можете брать и использовать как хотите

Что я могу сделать:

вместо xml отдавать json’ы по тестам отдельно (но все равно в разрезе регионов).

Чего я не буду делать:

Поддерживать выборки по BBOX
Делать багтрекер

ErshKUS · 2012-04-19T19:25:55.000Z

ну значит сначало будем те кто будет по bbox

Alno · 2012-04-19T19:45:55.000Z

Zkir:

Подумайте вот над чем. В одном валидаторе может быть несколько тестов, а в каждом тесте несколько типов ошибок. Поэтому было бы разумно, если бы валидатор отдавал описания ошибок тоже, вместе с краткой рекомендацией как ее починить. Как например здесь: http://peirce.gis-lab.info/qa/RU-SPO#errdescr

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

Zkir:

Что могу предложить лично я.
Есть xml’и с результатами валидации. Находятся здесь:
peirce.gis-lab.info/ADDR_CHK/{код карты по ISO 3166}.mp_addr.xml
Например: http://peirce.gis-lab.info/ADDR_CHK/RU-MOS.mp_addr.xml

Можете брать и использовать как хотите

Круто, постараюсь в ближайшее время сделать кэширующий конвертер, отвечающий на bbox

Zkir · 2012-04-19T21:30:28.000Z

Alno:

Круто, постараюсь в ближайшее время сделать кэширующий конвертер, отвечающий на bbox

Если что, стучитесь в почту - zkir [гав] zkir.ru)

osmisto · 2012-04-20T06:47:19.000Z

Уря, аггрегатор валидаторов

Я согласен с Zkir, что BBOX не очень хорошо. Во-первых в работе это будет странно, отзумил я на область, а потом жду хз сколько, пока каждый из 50 валидаторов отдаст мне свой набор. А если кто-то ещё завис…?
Во-вторых, сами валидаторы станут сложнее, тогда как лучше было бы чтобы сложность была в одном месте, а в валидаторах минимум. Можно даже просто один json на все ошибки делать каждую ночь и дать на него ссылку.
И, в-третьих, если аггрегатор будет их к себе все выкачивать он сможет объединять маркеры на больших зумах и выдаавть “облачка ошибок с циферками”. Тогда на большом зуме будет видна общая загрязнённость, а не надпись “приблизь, а?”.

osmisto · 2012-04-20T07:09:47.000Z

А ещё по протоколу:

В словарик с типами в “параметрах” можно добавить:

how_to_fix – инструкция (html?)
who_can_fix – anyone | resident

Последнее - очень нужная штука в фильтре, чтобы не загрязнять свой экран ошибками, которые не можешь поправить. Например поправить опечатку в имени тэга, или убрать дубоирование линий может кто-угодно. А вот узнать название остутствующей улицы уже нет.

Кроме того, есть ошибки, для которых нельзя найти координаты. Например, улица из Кадастра не указана на карте. Как их рисовать? Максимум, к чему можно это привязать - внутри границы города.

Валидаторы ошибаются, нужен способ обратной связи, когда маппер говорит, что это не ошибка. Нужно её скрыть в аггрегаторе, и отправить багрепорт создателю.

И в JSON-е с ошибками пропущен ID. Хорошо бы, если бы валидаторы сами генерировали ID для своих ошибок, и обеспечивали постоянство ID для одной и той же ошибки между обновлениями. Лучше них этого никто не сделает.

Update: я понял - description, это описание именно этой ошибки, а не типа! А описание типа похоже в text. Удалил это.

osmisto · 2012-04-20T07:18:19.000Z

Забыл про URL на ошибку в валидаторе. Если у какой-то ошибки сложное описание, с картинками, и т.п. То легче дать URL, чем пытаться всю эту информацию вставить в description.

Такие описания могут быть, например, в валидаторе дорожного графа. Когда создаются тесты вида "из пункт А в пункт Б маршрут должен пройти через: … " Ошибка для такого теста содержит как минимум правильный маршрут и неправильный. Две картинки, или одна совмещённая.

Alno · 2012-04-20T12:35:25.000Z

osmisto:

Я согласен с Zkir, что BBOX не очень хорошо. Во-первых в работе это будет странно, отзумил я на область, а потом жду хз сколько, пока каждый из 50 валидаторов отдаст мне свой набор. А если кто-то ещё завис…?

Ну если кто-то завис, то только он не отдаст, на остальных это не повлияет.
Но вообще смысл в сборе данных без BBOX похоже все-таки есть, да.

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

Какие-то валидаторы будут выгружать без поддержки BBOX, тупо json каждый день/час, их нельзя будет использовать без сервера-агрегатора.
А какие-то будут поддерживать запрос по BBOX - с ними можно будет работать напрямую с клиентсайда.

При этом протокол один, просто валидатор какие-то фичи из него поддерживает, а какие-то нет. Например сейчас есть флаги поддержки offset/limit, cors и jsonp. Видимо BBOX тоже придется сделать таким флагом.

osmisto:

И, в-третьих, если агрегатор будет их к себе все выкачивать он сможет объединять маркеры на больших зумах и выдаавть “облачка ошибок с циферками”. Тогда на большом зуме будет видна общая загрязнённость, а не надпись “приблизь, а?”.

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

pvp · 2013-06-13T15:04:02.000Z

Не совсем понял, что значит сообщение валидатора “Улица из адреса не связана с городом”.

AHTOH · 2013-06-13T16:07:30.000Z

Это значит что улица выходит за пределы place=city
Хотябы на чуть чуть

pvp · 2013-06-14T07:07:16.000Z

А чем это отличается от ошибки вида “Улица за пределами города”?

freeExec · 2013-06-14T07:12:39.000Z

Тогда она наверное совсем не входит ни в один полигон НП.

ErshKUS · 2013-06-14T07:20:31.000Z

тем что это могут выдавать разные валидаторы