361

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

Что касается потери данных, то теряется разница между “10а” и “10А”. Существенно это или нет - сказать невозможно. Но вполне вероятна ситуация, когда это может оказаться принципиально существенно.
При оценке “существенности” необходимо помимо прочего учитывать:

  • многоязычность - соответствие заглавных и прописных букв однозначно лишь в пределах единственного алфавита,
  • неточность границ образки, из-за которой в обрабатываемую по алгоритму для некоторого алфавита область может попасть часть объектов, подписанная с использованием другого алфавита,
  • возможность ошибок пользователей, в частности, замена одной буквы по аналогичную ей по начертанию другой буквой. При этом не факт, что обе буквы одинаково пишутся в обоих вариантах. Пример: маленькие “у” и “y” совпадают, а большие “У” и “” “Y” нет.

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

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

362

В принципе подход верный, но как и любой другой подход имеет ряд ограничений.
Вот мне кажется, что в данном конкретном случае как раз мы сталкиваемся с ограничением на использование: в некоторых полях (в первую очередь “name”) могут встречаться настолько разнообразные данные, что ложные срабатывания сделают просто невозможной работу: представьте, что Вы загружаете некоторый фрагмент данных (например, в josm), обрабатываете его, пытаетесь записать, а в ответ получаете список из 30 “ошибок” которые предлагается тем или иным способом исправить. Пусть на первый раз Вы обнаружили, что 10 из этих “ошибок” на самом деле ошибками не являются, а по поводу остальных 20 ВЫ ничего сказать не можете, т.к. делали их не Вы, и недостаточно хорошо знаете те районы, в которых эти “ошибки” обнаружились. Вы, естественно, не делаете никаких исправлений и нажимаете кнопку “оставить как есть”. Такое продолжается на протяжении последующих 50 сессий работы с josm. Затем Вы делаете реальную ошибку и как обычно получаете список из более 30 строк, но, как обычно, уже не смотрите этот список и отправляете на сервер данные с ошибкой.
Итого: из-за многочисленных ложных срабатываний с одной стороны Вам постоянно напоминают об “ошибках” с которыми Вы ничего не можете сделать, что Вас несколько утомляет, а с другой - реальные ошибки так и остаются невыявленными т.к. теряются в массе ложных срабатываний.

Так вот, мне кажется, что поле addr:housenumber так же, как и name относятся к тем полям, которые не следует пытаться автоматически исправлять.

363

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

364

Во-первых, бот для этого и нужен, чтобы 10а, 10 корп.4 приводить к единому виду 10А и 10 к4 аналогично. Просто нужно тоже бороться с хаосом. Сейчас существует бот AMDmi3, который приводит названия улиц в порядок. Где же там негативные последствия? Что он поломал или разрушил? Я лично не заметил. По моему мнению, базу тоже надо приводить к виду, иначе можно без конца пилить конвертеры.
Во-вторых, разницу между латинской и русской “у” бот тоже замечает.
В-третьих, когда работал этот бот, то претензий к нему не было. Все он сделал правильно и точно. Поэтому страхи, что придет этот страшный бот и все разрушит, не к месту. К тому же, все можно откатить, если пойдет не так.

365

А давайте запретим andriano? Жалоб и критики много, предложений мало (точнее нету). В чистом виде потеря времени на чтение его стонов.

andriano, я серьезно, хватит ныть. Деструктивизмом здесь никто не будет заниматься. Но провести ботом часть ручной работы (по приведению адресной информации к каноническому виду) давно пора. Либо, если ты против бота, делай это сам. Если не хочешь сам - не мешай остальным.

366

Можно я вставлю пять копеек прописных истин…
1)Если бот приводит к потере информации, то надо локализовать и отключить кусок, приводящий к такой потере, пусть даже ценой потери эффективности бота. Однако это не значит, что от бота надо отказываться вообще.
2)О каком объеме мы говорим? Объемы в сотни ошибок проще сделать руками по валидатору - заодно просветить автора ошибки.
3)Как часто ошибки вновь плодятся? Бот, который надо прогонять раз в месяц, даже раз в несколько месяцев - проблема грамотности редакторов. И накануне прогона по всем применениям будут идти корявые данные. Возможно нужно писать более четкие правила, шире их доводить до участников и т.д.

367

Вот и объясните, зачем нужно приводить к 10А, если на табличке написано 10а?

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

368

Может мне кто объяснит, зачем нужно приводить номера домов к виду “10А”? Кому от этого будет лучше?
В ОСМ есть масса полезной работы для бота: удалить пути без тегов не входящие в отношения, разослать письма авторам тегов типа “highway=ул. Ленина”, поправить, пока это не превратилось в большую проблему “role=123” на “role=bno:123” или что-то пригодное для дальнейшей обработки. Зачем делать бесполезную?

Лично меня дома в формате “10А” устроят точно в той же степени, что и “10а”, но мне жалко чужого времени, которое могло бы пойти на что-то более полезное.

369

Зачем удалять? Надо теги проставить. Вот это как раз работа для человека, а не робота.

вот это да, очень нужная функция. Я двумя руками “за”! Без шуток.

это ещё что такое?

370

Я не проводил полномасштабного анализа, но судя по всему в России номера домов регистронезависимы. Поскольку большая часть алгоритмов обработки и, особенно, поиска (обработке проще все перевести в верхний) наоборот регистрочувствительна, то…

Кроме того это в большей степени касается не регистра букв, а формата написания корпусов и строений. Какая потеря информации может произойти при замене “корп.” на “к” я не знаю. Впрочем по мне лучше наоборот, но в вики записано именно “к”.

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

371

Сталкивался ли кто-нибудь с ситуацией, когда “10А”, “10а”, “10 А” и “10-А” означали четыре разных адреса? Если такого никто не встречал - это действительно следует причесать к одному виду.

372

Кстати есть какой-нибудь документ, регламентирующий запись адреса в Эрефии?

373

Ну вот разницу между 10А и 10 лит. А хорошо знают жители одного приморского города…

374

Литеры - это другое, там действительно важен регистр. А вот за буквенными индексами номеров ничего подобного не замечалось.

375

Вот я, скажем, человек, а не бот (уж поверьте на слово).
Я открываю жосм/полтач и вижу там вей без малейших признаков тегов (понятно, что увидеть я могу его только в ОСМ-редакторе, т.к. ни рендеры, ни конвертеры такого не показывают).
И какие теги я, как человек, должен там проставить? (Честно говоря, я в таких случаях решаюсь проставлять один единственный тег building=yes, что делать с прочими линиями, не напоминающими периметр дома, я не знаю)
Поэтому, думаю, кроме автора в этом все равно никто не разберется. Практика показывает, что проще сделать с нуля, чем разбираться в чем-то явно неправильном. Поэтому - удалять. Ну либо - сначала рассылать письма авторам, а если не поправят - через 2 недели удалять.

Вот с этого и надо было начинать.
Т.е. с анализа того, какие именно ошибки встречаются в ОСМ чаще всего.

Для тех же, кто такой анализ не проводил, сообщаю, что есть идея (кстати, по моему мнению - хорошая) - осуществлять адресацию т.е. привязку домов к улицам в виде отношений: одна улица - одно отношение, где указывается id самой улицы и в качестве ролей членов должны фигурировать сами номера домов по данной улице.
Так вот, за этой хорошей идеей закрепилась явно порочная практика - указывать в качестве роли сам номер дома без каких-либо отличительных признаков, что противоречит стандарту, противоречит смыслу role и является потенциальным источником ошибок, т.к. задача отличить номер дома от любой произвольной текстовой строки алгоритмически неразрешима, т.е. гарантированное отделение одного от другого возможно только вручную. Но процентов на 98 это можно автоматизировать. Хотя бы для того, чтобы:

  1. Пока не накопилось слишком много данных, оставшиеся 2% можно будет разобрать вручную.
  2. Т.к. многие рисуют по подобию, создать прецедент если уж не совсем “правильного” рисования в данном случае, то, по крайней мере такого, которое впоследствии может быть алгоритмически приведено к безусловно правильному виду адресации, когда такой вид будет согласован и принят.
376

Ладно, думаю хватит флудить. Я написал автору бота с просьбой его снова запустить. Там и посмотрим результат.

377

Это плохо само по себе.
Значит, Вы не видели результатов подобного анализа, и Вам трудно представить, с какими “особенностями” порой приходится сталкиваться.
ОСМ на интересующей нас территории содержит десятки миллионов объектов и среди них неизбежно встречаются такие “которых не может быть в принципе”.

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

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

Объясняю:
Сначала идет дом номер “10”, потом “10А”, потом “10Б” и, наконец, доходит до “10К”, что совсем не то же самое, что “10 корп.”. Заменяя “10 корп.” на “10К” мы объединяем две различные сущности в одну, что и есть потеря данных.

Еще раз повторюсь: на изготовление и отладку бота расходуется человеческое время, а его лучше использовать на что-то более продуктивное.

378

Я был свидетелем первого запуска бота, могу сказать, что он умеет отличать 10К от 10 корп. N. Еще он действует по строго точной схеме, если есть затруднения, он прописывает это в тег fixme. Была одна проблема, что он залез в Республику Беларусь, но позже это исправили, со следующих правок не было никаких нареканий.

379

Бот уже есть, осталось его снова поднять. Не знаю, про какое время на разработку вы говорите

380

Чья-то идея - это ещё не строгое правило для всех. И такой системы адресации нет в вики. Не было ни пропозала, ни голосования.

Пока есть реально три системы адресации:

  1. addr:housenumber и addr:street на доме, плюс name, name:ru, name:uk, name:en в тегах отрезков улицы.
    Самая известная и много где употребляемая схема. К сожалению, с мультиязычными адресами там пока проблема (у liosha не получается их обработка в конвертере)
  2. белорусская схема адресации с релейшенами, где всё завязано на релейшены
  3. схема Карлсруэ. Использует для каждой улицы релейшен с ролями street и house. Используется в Украине.
    http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema#Using_relations_to_associate_house_and_street_.28optional.29

Для литер придумали тег addr:letter (кстати, это тег тоже ещё толком не утверждён).