Это ни неправильный ОСМ, это неправильные инструменты для постобработки его.
Возможно, что “правильные” инструменты плохи, громоздки и неудобны.
Мы имеет то что имеем, но всегда хочется большего, разве это плохо? ОСМ не предназначен для рисования детальных карт (или area:highway уже отображается?) но ведь рисуем! ОСМ не подходит для 3D-карт но народ всё равно рисует - http://map.f4-group.com/#lat=55.7528673&lon=37.6220729&zoom=18&camera.theta=60.717&camera.phi=79.652
О чём это я? Если есть проблема, то может она глубже чем кажется на первый взгляд? Если есть проблема, может её стоит решить более комплексно? Может стоит думать не о косметических изменениях а о тщательно продуманных изменениях в API/подходе?
Проблема, собсно одна - указывать на проблемы желающих много, а вот решать их желающих очень мало.
Определенная избыточность в хранимых данных полезна.
Если данные вдруг разошлись, возможно их повредили.
Ведь хранят же люди контрольные суммы и т.п. и не считают, что это засоряет их хранилище.
Я как-то думал над такой темой, но несколько с другой стороны - смотрел со стороны дефолтных значений некоторых тегов. Например в деревнях высота дома в 99% случаев будет равна 1 этажу - соответственно нужно бы эту деревню обвести и повесить на этот полигон тег который указывает, что внутри этого полигона все дома равны 1 этажу, если не указанно другое значение. Вокруг города нарисовать полигон в котором указанно, что внутри все дороги асфальтовые (и отмечать только грунтовые, бетонные, плитку и тд.).
Но решил, что это пока никому не нужно - никто не поддерживает данную схему тегирования и значит она будет в данный момент бесполезна.
kapilov, это очень плохая практика, потому как любой новый объект автоматом будет подпададать под какие то умолчания, причём в вашем случае, вообще никак не связанный объект (какой-то полигон) будет задавать умолчания. Как вы по объекту узнаете, что кто-то оказывается нарисовал снаружи какой-то полигон и что-то там написал? Вы предлагаете для каждого объекта проверять пересечения и вхождения со всеми полигонами в базе?
Золотые слова! Именно это порой случается и с полигонами районов и т.п.
В результате у объекта меняется адреска. Иногда в неверную сторону.
Хотя бы с теми, что близко. Размер полигона ограничить. Или разнести большие и маленькие полигоны (с большими со всеми сравнивать, а с маленькими только теми что находятся недалеко от объекта). Все это нюансы реализации.
Ещё можно сделать по образу и подобию отношений (или ставить тег c номером набора стандартных тегов) - получится что нужно будет ставить 1 тег, а в самом отношении/наборе уже прописать те теги, которые нужно применить к основному объекту.
Это, как раз, верная идея. Иметь стили — сгруппированные наборы тегов.
В Ворде такое есть, но мало пользуются. В ТеХ’е без этого наоборот - не проживешь.
Это позволяет разделить логическую разметку текста от офрмления.
HTML CSS из той же оперы, но использование его далеко от идеала.
И что делать? Известна проблема - ломаные границы. Но почему они ломаные? Потому что не хватает геометрических примитивов. Закачивая данные из ОСМ у меня получается 5 сущностей:
- Точки
- Линии (состоящие из точек)
- Контуры (состоящие из одной или многих линий) - это удобно для моего приложения
- Области (в т.ч. и с дырками)
- Объекты (в том числе относящиеся к областям)
Если сущность - контур, то обязательно делается проверка на замкнутость. Если контур не замкнут, то на выходе получаем разрушенный геометрический объект. Если сущность - область, то делается проверка на корректную вложенность и отсутствие самопересечений. Объект это сущность другого порядка которая может быть привязана к геометрическим сущностям а может и к другим объектам.
Я не думаю что я высказал что-то оригинальное, думаю подобные схемы (и даже намного более элегантные) предлагались с самого начала. Но груз legacy убивает любое начинание … Вот и получаем кучу костылей, постфактум-валидаторов. И спорим - нужна избыточность данных или нет …
И что делать? Форкнуться в свой OSM, с игорными заведениями?
Вообще я не вижу смысла в поддержке старого. Т.к. даже программы типа линукса рано или поздно освобождаются от старого груза
lenux
Юношеский максимализм 
??? Надо попросить америкосов что бы перестали принимать старые стобаксовые купюры - ведь новые уже есть, цветастенькие Вам же уже говорили, что OSM не только для Вас - он и для других людей, которые на такие слова как “линукс” даже не реагируют… Раз ресурсы позволяют - должно быть максимально просто в редактировании - а Вы уже на основании того что имеется стройте свои базы так как Вам захочется… И у Вас все будет идеально…
Это в абсолютно равной степени относится и к тем кто радеет за мусор а базе.
Друзья, есть тут кто-нибудь, кто был бы за мусор в базе?
Встаньте, не стесняйтесь. Если вы сами против мусора в planet.osm, но знаете человека, который был бы за, назовите его имя.
Обещаю, что ничего особенного плохого с ним не случится.
Ну так и редактируйте в меру своих возможностей домики там дороги. Не знаете административное деление - не суйтесь, найдётся тот кто не только знает и может это внести. А втыкать грубо говоря на каждой точке is_in=мой город, только потому, что это умеешь и легко не стоит.
Если на ПОИ не проставлять addr улицы, то здесь не будет и ошибки: Есть магазин, магазин находится в здании, у здания есть адрес, здание находится на территории какого НП, НП входит в … суть вы поняли : )
Это самый веский аргумент?)))
Вы не понимаете, что проект ОСМ является международным, ОДНАКО некоторые традиции/позиции и еже с ними могут решаться в рамках отдельной страны. По сути мы сейчас и занимаемся в основном именно пересматриванием концепций в рамках РФ, а не америкосов, японцев и тайванцев : ).
Я не где не сказал, что я что-то строю. Действительно все строители баз сами строят - это даже и не обсуждается в теме. Да и AMDmi3 уже вам ответил.
Zkir +1 . Добавлю, кто мне скажет почему на этой точке мне не удалять addr:country addr:district addr:region с ней?
freeExec Вообще честно говоря прописывать addr не фига не проще. Потому что то требует определённой сноровки.Конечно если это одна деревня то не сложно, а когда их 6к это ад!
Мне кажется сам топик - пример того как легко живется с Лёшиным конвертером. Можно и так порассуждать про адресацию, и эдак… Не было бы osm2mp - разговор бы шел ровно в противоположном направлении, лепили бы is_in на здания и полный адрес на каждую POI. Благо в JOSM есть инструмент “выделить внутри полигона” 
Информация неверна? Удаляйте/исправляйте. Информация верна? Тогда зачем удалять? Иметь дополнительную информацию удобно. Слышали про такое слово “индекс” в базе данных? Он не нужен но хранится - для ускорения ряда алгоритмов. Так и здесь - появляется дополнительная возможность что-то поискать без привлечения стандартных тяжёлых методов.