но никто ничего никуда не передает, просто с помощью КЛАДР вводится информация в ЭВМ.
Право использования КЛАДР ограничивается правом на воспроизведение (запись в память ЭВМ, архивное копирование и инсталляция) и правом пользования (осуществление действий, связанных с функционированием КЛАДР в соответствии с ее назначением).
А вот собственно назначение КЛАДР:
КЛАДР, предназначен для … стандартизации представления адресной информации в целях:
корректного ввода адресной информации в ЭВМ пользователем;
корректного представления адресной информации в электронных документах;
унификации способов представления адресной информации при информационном взаимодействии, в т.ч. межведомственном;
автоматического распознавания адресной информации при ее обработке, отождествлении и сортировке;
унификации способов хранения и обработки адресной информации;
автоматического определения по адресу связанной информации (отделения почтовой связи, кода административно – территориального образования, налогового органа и т.п.);
сокращения объемов адресной информации как при ее передаче (по каналам связи, на магнитных носителях), так и при хранении в базах данных;
унифицированного контроля и других видов обработки адресной информации.
Короче, в OSM кладр и кладр-коды использовались по прямому назначению, в целях унификации адресной информации и автоматического контроля, при хранении ее в базе данных (osm) в строгом соответствии с лицензией.
В отквотированном речь идёт о использовании КЛАДР как отдельной базы. Т.е. “можете не хранить/передавать сразу кучу номеров и строк, а передавать один кладрокод, а остальное получать из КЛАДР налету”. Поэтому cladr:code хранить можно.
А вот когда у нас в тэгах хранится cladr:name и cladr.suffix, это однозначно “предоставление доступа третьим лицам к компоненту КЛАДР”.
Ситуация следующая: в базе присутствуют некоторые данные, связанные с или взятые из КЛАДР.
- cladr:name, cladr:suffix на улицах.
addr:postcode на улицах от туда же и не всегда верно (намого чаще не верно)
addr:city на полигоне нп, вместо addr:district, еще и с устаревшими/не верными данными
Я за удаление! Пока ещё никто не привел пример прямого использования данных тегов. Не используется = не нужно. При это за более чем год после остановки кладр бота никто не озаботился его реанимацией. Так что, ИМХО - стирать.
а та информация мешает кому-то?
а по какой причине стопанули бота?
UPD: “Прежде, чем разрушать что-то, будь уверен, что сможешь создать нечто лучшее взамен.” ©
Я смотрю, выпиливание и стирание тегов - новый тренд в ОСМ.
Привет от building=entrance и addr:street
Какой тренд? Данные давно являются неживыми. Тут только два варианта - реанимировать бота по проставлению кода или удалить мусорные данные. Третьего не дано. За пару лет бота никто так и не реанимировал …
Не знаю как для улиц, а вот cladr:suffix для НС бывает полезным.
Не знаю как для улиц, а вот cladr:suffix для НС бывает полезным.
Ему придумали замену — official_status:ru
а та информация мешает кому-то?
Я об этом ясно написал, по-моему. Одну нельзя иметь в базе по лицензионным соображением, другая изначально неверена, а всё вместе стухло. При этом то же самое всегда можно получить напрямую из (свежего!) КЛАДР.
А НП я пока трогать не планирую.
Что за “удалятельский” зуд поразил в последнее время ОСМ?
Насколько я понимаю:
- если тебе нужны какие-то данные - сносишь их в ОСМ,
- если обнаружил ошибку - исправил,
- если лично тебе какие-то данные не нужны - игнорируешьо их,
- но удалять - не сметь! Ибо - вандализм.
Что же касается бота, то, думаю, он определенную часть работы сделал и больше гн нужен. Остальное следует делать ручками, а именно - проставлять теги новых объектов и исправлять те ошибки, которые бот в свое времяч допустил. Реанимация бота никого смысла не имеет - она лишь увековечит имеющиеся ошибки.
Это нормально - когда нужно проделать большой объем работы, который невозможно на 100% формализовать, то сначала то часть, которую можно, делаент бот, а по окончании его работы - остатки разгребаются ручками.
Поэтому факт остановки бота не может служить аргументом в пользу ненужности данных - это рациональный этап работы, который закончен.
В конце концов, если есть соображения по поводу замены одних тегов на другие (кстати, зачем?), то разумная организация этого процесса:
- расставить заменяющие теги,
- провести валидациию новых тегов с существующими кладр-тегами,
- только после этого поднимать вопрос об удалении ДУБЛИРУЮЩЕЙ информации.
Хочу подчеркнуть: именно ДУБЛИРУЮЩЕЙ, а не той, которая по чьему-то мнению не нужна.
PS. Лично я использую только cladr:code, но категорически против удаления, т.к. исхожу из принципа: “внося свою лепту, не выноси чужую”.
PPS. По поводу “протухшей” инеформации: вношу альтернативное предложение - удалять как протухшие любые данные, которые не редактировались в течение 12 месяцев.
andriano, не читатель?
… а всё вместе стухло. При этом то же самое всегда можно получить напрямую из (свежего!) КЛАДР.
А НП я пока трогать не планирую.
Кстати, есть подозрение, что именно из-за этого соглашение на КЛАДР и запрещает редистрибуцию. Чтобы не выдавали непоймешь что непоймешь какой давности за КЛАДР.
В отквотированном речь идёт о использовании КЛАДР как отдельной базы.
Нет, в нем идет речь об использовании КЛАДР вообще. Про отдельную базу там ничего не говориться.
Поэтому cladr:code хранить можно.
А вот когда у нас в тэгах хранится cladr:name и cladr.suffix, это однозначно “предоставление доступа третьим лицам к компоненту КЛАДР”.
Ахренеть! кладр-код хранить можно, а адреса нет! Напомню, Кладр получен коллекционированием адресов [налогоплательщиков], имеющимися в обиходе. Никакого исключительного права у ФНС на адреса нет.
Ну на адреса нет, а на классификатор адресов есть. В то по вашей логике можно сказать, что никакого исключительного права у гугл-транслейт на перевод нет. Буду брать их перевод и заносить к себе в базу.
Нет, в нем идет речь об использовании КЛАДР вообще. Про отдельную базу там ничего не говориться.
“Использование КЛАДР вообще” и есть отдельная база. А тут речь идёт о её распространении.
Ахренеть! кладр-код хранить можно, а адреса нет!
Суть базы в хранении данных и обеспечении связи между ними. Один код - не часть базы. Код в паре с любым другим полем из КЛАДР - часть.
Я за удаление этого мега-мусора!
Один код - не часть базы. Код в паре с любым другим полем из КЛАДР - часть.
Почему именно в паре, а не весь набор полей? Сам по себе КЛАДР код в своей структуре несет значительный объем информации: принадлежность к субъекту, району, НП и т.д.
Кладр код кстати тоже не считаю нужным, сопоставление другой базы с нашей не наша задача, тем более что сопоставить можно всегда по name*. Да сложнее, но это нужно тем, кому нужно. Если у нас будет десятка 3 баз, нам что все их коды прописывать для привязки баз? Я думаю это глупо и задача нейтральной стороны, которая обрабатывает данные обоих баз.