Из геометрии, ага. Напомню одну цитату из прошлых обсуждений, которую вы наверное пропустили:
И вы думаете, что такие “данные” будут лучше чем прямое использование геометрии и границ, даже частично где-то поломанных? Только если вас не заботит качество результата.
Это по нашенски - снести теги в целой области, и ждать - а не появится ли у кого претензий!
Лично я обрабатываю local.osm целиком, поэтому наблюдаю у себя лишь статистически уменьшение доли “точно” адресации в пользу “приближенной”, но ввиду того, что вывод у меня осуществляется в алфавитном порядке, идентифицировать конкретную область, за счет которой произошло ухудшение, не удается.
Даже при радикальной смене самого кода, иерархическая структура изменяется очень незначительно.
И если интересует не сам код, а именно место объекта в структуре, может оказаться, что и с устаревшим кодом (как самого объекта, так и включающих его объектов) его место в структуре не изменится.
Т.е. с практической точки зрения неактуальный код может оказаться либо почти либо в точности так же полезен, как и актуальный.
Давайте говорить только за себя.
Я использую OSM для тех задач, для которых считаю нужным, и таким образом, каким считаю рациональным.
Вполне допускаю, что у Вас другие задачи и другие способы их решения.
Но не думаю, что это повод пытаться навязать мне свое мнение либо затруднить мне решение моих задач, даже если лично Вы их не понимаете.
Совсем недавно на одном из программистских форумов мне преподали ценный урок.
Вопрос был в преобразовании числа в строку типа: “123” → “сто двадцать три”. Я заметил, что в некоторых случаях преобразование совершалось с ошибками (типа “дванадцать” вместо “двенадцать” или “четыренадцать” вместо “четырнадцать”), о чем написал автору. Он возразил, что такая точность для его задачи вполне приемлема.
Понятно, что в финансовых документах такое недопустимо, но у них была ситуация с низким качеством печати квитанций, из-за которого не всегда однозначно можно было распознать цифры, а текстовая строка, хоть и была не совсем правильной, устраняла эту неоднозначность.
В общем, из этой переписки лично для себя я вынес вывод, что спектр реальных задач намного шире, чем может показаться, и “неточные” данные могут быть полезны в той же мере, что и “точные”. Все зависит от конкретной задачи.
Угу, только кладрокоды были проставлены по ещё менее полным данным.
А вы сравните процент поломанных границ с непроставленными кодами.
Да-да, но вы почему-то думаете что КЛАДР-бот её как-то решил.
Вы обманываете сам себя. Как минимум, взяв те же алгоритмы, по которым действовал бот, можно получить
но куда интереснее бодаться за тухлятину в базе.
Не-а, вы видите уменьшение доли одной приближенной адресации в пользу другой приближенной, причём вторая считается контролируемо и по новым данным.
Алсо, посчитал процент проставленных кладрокодов. Их уже меньше четверти для улиц и меньше 8.3% для домов.
Да, только это уже не является кладром. А то так можно addr:housename = “торговый центр” хранить. Польза вроде как есть, но по смыслу не то и не там.
Непосредственно для места объекта в структуре существует роль subarea в отношении boundary и тег is_in.
Но это не повод хранить в кладротегах то, что кладром не является.
Теоретически Вы правы.
Ровно в той степени, в какой теоретическая возможность написать некоторый алгоритм равна реальным данным, полученным в результате работы уже написанного алгоритма.
Но данные мне нужны уже сейчас, а повторять работу по написанию алгоритма, проставляющего КЛАДР-коды, у меня сейчас нет ни времени, ни желания*.
Тем более, что результат этой работы, очевидно, будет того же порядка качества, что и у КЛАДР-бота.
Так какой смысл повторять работу, если уже есть результат примерно совпадающий по качеству с результатом предполагаемой работы.
И еще интересный момент.
КЛАДР-бот проставлял 3 cladr-тега и несколько addr-тегов.
Вопросы:
Небольшая статистика по наличию cladr-тегов (напомню, что cladr-бот работал в 2009-2010 годах):
февраль 2011 г
cladr:code - 247121 шт.
cladr:note - 3336 шт.
апрель 2013 г
cladr:code - 211510 шт.
cladr:note - 3105 шт.
Кто может объяснить, почему наряду с проставленными ботом кодами cladr:code, cladr:name и cladr:suffix удаляются проставленные ручками cladr:note? Разве это не вандализм?
Зачем введен новый тег kladr:user, назначение которого в точности повторяет назначение cladr:note?
Кстати, на апрель 2013 г тегов kladr:user насчитывалось всего 1900 шт, т.е. по количеству они не дотягивают не то что до cladr:code, но даже до cladr:note.
Неверно. Алгоритм уже написан - просто возьмите его из кладробота.
Неверно. Запустив алгоритм вместо использования существующих данных, вы получите данных как минимум в 4 раза больше умножить на устаревание кладр умножить на устаревание ОСМ умножить на теоретическую возможность улучшить алгоритм.
Разумеется надо удалять всё. addr:postcode там такая же помойка что и коды.
addr: теги уже многие руками людей перерабатывались, а postcode найти уже будет непросто правильные - неправильные ибо всё смешалось, но теги cladr: от этого нужности точно не приобрели…
“Хороший” способ удалить эти теги был упомянут - удалять те, которые не внесены вручную. Правда, это посложнее)
Технически это не сложно. Меня больше беспокоит то, что вот они-то как раз могут быть корректными и кем-то использоваться, и не менялись только потому что из-за удивительного стечения обстоятельств проставились ботом правильно.
Господа, а можно удаление обсуждать в теме про удаление, благо таковая есть.
Эта тема - про применение.
Например про то, почему adriano использует для определения вложенности кладр неизвестной достоверности, а не предназначенные для этого теги. Какая объективная причина тому есть?
А вообще есть какой-то резон сейчас ставить kladr:user или нет? Я видел у себя в области cladr:code, ну и стал сам ручками его добавлять - а тут вот оно как оказалось - что он и не нужен вовсе.
kladr:user ставится для исправления ошибок автоматического сопоставления, cladr:code - для ручного сопоставления.
Соответственно kaldr:user добавляется если вы пользуетесь (или проверяете) какую-то автоматическую сопоставлялку и находите несоответствие, которое вызвано нельзя исправить уточнением в OSM e.g. валидатор границ
Данный валидатор уже давно не работает 
Хотя был очень полезным инструментом. Только для него нужно было проставлять тэги oktmo:user с кодом ОКТМО из валидатора.
BTW - кто нибудь пробовал связаться с автором валидатора и попросить его код?