В Москве есть Зеленоград и Акулово - в них куча домов должны быть без addr:street (и даже без его аналогов)
Понимаю. Тогда, наверное, разные правила надо применять к разным объектам.
Прошёл. Скорее всего должны быть, но лучше проверить на местности или с помощью авторитетных источников. Это всего лишь подозрительные, но при этом валидные объекты.
Но все-таки их больше 0? Значит, даже в Москве надо применять разные правила валидации?
Ну и неправильно. Такой приём даёт невалидный результат.
Это не проблема валидатора. Это проблема средства автоматической проверки полноты адресных данных.
Есть проблема: текущая схема не различает пропущенные улицы и адресацию по району.
Можно, конечно, считать все данные полными и игнорировать проблему.
А можно попытаться придумать способ различения правильно адресуемых по территории домов от домов с незаполненными улицами.
Спор насколько применим термин “невалидные” к неполным данным считаю заранее неконструктивным и не приближающим нас к решению проблемы.
Scondo, тогда нужно про каждый возможный тег придумать, как обозначать его отсутствие, и везде его обозначать 
amenity:no=yes
natural:no=yes
sport:no=yes
etc
А то вдруг кто-то подумает, что просто забыли обозначить
Но ведь пишут же скажем oneway=no и т.п. 
Три решения:
- валидатор не считает ошибкой незаполненную улицу, как вариант, может выдавать предупреждение или же ошибку, но по настройкам пользователя.
- валидатор должен знать в лицо все места, где улица в адресе отсутствует законно, то есть имеет свою базу таких мест.
- валидатор берет информацию о законности из ОСМ. Информацию можно занести или в каждый дом (что-то вроде addr:street=no / addr:emptystreet=yes) или куда-нибудь в район/населенный пункт.
Первый вариант вообще ничему не мешает. Тот, кто работает с Зеленоградом - может в любой момент отключить эту проверку, если она мешает.
Второй вариант тоже ничему не мешает. Только добавлять в базу придется через какой-то специальный механизм (веб-интерфейс или письмо автору).
Третий вариант позволяет любому править информацию о допустимости таких адресов в конкретном месте, но будет замусоривать ОСМ.
Первый вариант должен работать по-любому - пункты 2)/3) ведь могут и не сработать где-то из-за отсутствии для них информации.
“и т.п” нужны для изменения дефолтов, а у addr:* вроде никаких дефолтов и нет
Для указанных тегов нет случаев, когда они предполагаются, но отсутствуют. В отличии от addr:street.
Причем, если вы обратите внимание на предложенный мной вариант, то я как раз не считаю, что надо говорить есть улица или нет. Я считаю, что надо смотреть к чему привязан дом.
Подниму связанную тему.
Не адресация, но группировка.
Обычно при поиске (в нафигаторах) дома группируются по улицам, но если улицы нет, то не всегда получается удобно и/или общепринято.
Пример: Зеленоградские адреса без улицы, но дома по ним при поиске принято группировать по микрорайонам (которые в адресации никоим образом не участвуют). Иначе получаем длинный список в тысячу с гаком элементов.
Больше того, даже адреса с улицами зачастую люди ожидают увидеть тоже сгруппированными по микрорайонам/районам и т.п., хотя в адрес эти понятия вовсе не входят.
wowik, группировать, если нужно, вполне можно (и даже удобно) по начальным подстрокам.
Никаких дополнительных обозначений при этом не требуется.
Вот и addr:street точно так же не должен предполагаться.
addr:street - необязательный элемент и никто не должен предполагать его наличие. Я это вам, как зеленоградец, точно говорю!
В отечественной адресации вообще ничего заранее предполагать нельзя 
! В адресе, как мне кажется, нет ни одного обязательного элемента 
Если это и проблема, то не схемы. Схема просто не предназначена для оценки полноты данных.
Проблема может быть решена только при помощи внешнего по-отношению к ОСМ источника информации.
Глядя на данные только из ОСМ эту проблему не решить.
А, по-моему, называние вещей своими именами и отделение одних сущностей от других позволяет прибилизиться к решению.
Действительно можно, действительно не требуется, но не удобно. Опять же, алгоритм определения какие подстроки брать для группировки надо зашивать в конвертор/навигатор?
Видал я такое, так часть первого микрорайона и десятого сваливают в одну кучу, а другую часть первого и одиннадцатый сваливают в другую и т.п.
корп 100
корп 1001
корп 1002
корп 1009
корп 101
корп 1010
корп 110
корп 1101
корп 1102
корп 1109
корп 111
корп 1110
При отстутствии “информации о законности” проблема не решается. Поэтому это решение, наверное, будет работать, если второе предложение будет начинаться так: “Информацию нужно занести…”. Будет ли внесена эта информация?..
Однозначно нет!
Это просто способ убрать ругань валидатора, если она кого-то достала в конкретном месте. Больше в этой информации смысла нет.
А вообще-то нефиг мапить под валидатор ! И чего бы ему не жить со своей базой?
А как эта проблема решена во всяких Дубль ГИС и прочих картах для навигаторов?
Это не чушь, это другая концепция:) Там имелось ввиду, что addr:street - это название того объекта, к которому относится номер. Улицы, квартала, района, НП. Номер же так или иначе должен к чему-то относиться. По-моему, это вполне имеющий право на существование подход к схеме адресации.
Вот очень плохо, что не предназначена. Наличие избыточности, позволяющей находить и исправлять ошибки - благо, а не зло.
А если никакой проблемы нет, то и менять ничего не нужно. 
?! Номер относится к зданию/строению/сооружению.
А расширение-размывание смысла addr:street - плохая практика. Соотв. концепция вряд ли имеет право на существование.
Ну, м.б. не очень
Это бесспорно. Но где в ОСМ такое практикуется?
Ага, говорим “партия” - подразумеваем “ленин”.
Не надо было тогда использовать слово “улица”.
Да, только это совсем-совсем другая схема. У белорусов такая была: a2, a4, a6 и связи между ними через релейшены.
А в нашей схеме addr:* развёрнуто прописываются элементы, а связи явно не указываются.