Прелесть какая. А ты ориентацию для точек делаешь параллельно соответствующим улицам?
LexIgnatov, вообще все дома могут выпасть из города, если город подвинуть. У нас нет никакой привязки к addr:city, а только по вхождению в полигон города. Почему вдруг для домов с адресами должно возникнуть исключение?
а еще может придти кто-то, и дороги разъединить.
Зачем? Если номер через дробь написан на табличке, в оф документах, паспортах жителей, зачем пополамить его и разносить по разным частям здания?
насчет того что выяснить просто в каком полигоне точка, я бы не сказал, один домик еще не сложно и может быстро, но на мировой/российской базе прогнать все точечные адреса на проверку вложенности в полигоны с тегом здания, ну не знаю…
а это нужно, например для определения у точки poi адреса
в питере, кстати, не все дома, имеющие несколько адресов, пишутся через дробь
возьмем дом Мурузи (у него 3 адреса):
addr:housenumber = 24/27/14
addr:street = Литейный проспект
addr:street2 = улица Пестеля
addr:street3 = улица Короленко
на доме таблички 24/27/14, разумеется, нет
делить здания на куски считаю глупостью, ставить доп. адресные точки тоже. получается, дополнительные адреса в таком случае надо ставить отношениями или использовать addr2 + addr3
кстати, в пользу точек также использование для соединенных домов (10,12,14,16) где нельзя точно определить границы соединений, или являются одним домов. Конечно можно и через запятую перечислять. Тогда через запятую можно и угловые дома писать
Хотим мы или нет но нам надо придти к одному решению, т.к. мы ломаем мозг как пользователям, так и программистам двойными/тройными стандартами
На сколько я понял сейчас серьезной проблемой addrN является необходимостью дорабатывать софт, а его много и не всякий мы можем изменить (да и кто это будет делать).
А минусом точек является не привязанность к зданию (тут можно предложить ставить точку на полигон здания, например там где аншлаг) все таки дом по ошибке легче переместить (да и JOSM не ругнется на простой объект, а натравливать на такие объекты - ад). Если ставить точку на полигон, то и упрощается определения принадлежности адреса к зданию. Я понимаю, что сейчас закричат, что нельзя ставить номер на стене, адрес это внутреннее свойство, но может тут пойти на уступки?
ИМХО точки более гибки
ИМХО точки более гибкий вариант, но с точки зрения модели данных происходит странное - контур дома и его адрес оказываются вещами не связанными 
Опять же ИМХО - точки оптимально решение для навигаторов/рендеров, addrN: - для обработки и целостности данных. Если будет некое отношение в котором дом и его адреса сольются - буду за точки А так это вроде как независимые объекты …
Всё-таки, мне не понятен аргумент про “дом переместят, а точки останутся”. Кто будет перемещать дом и с какой целью?
- новички, но тут как бы и город можно, но дом проще, он меньше. Да и JOSM не крикнет, т.к. у домов малое число точек (обычно)
- например из-за глюка программы (у меня самого так было, передвинул несколько домов, хорошо до выгрузки заметил), или просто по неаккуратности (хотя тут и тег можно удалить), но согласитесь что геометрию испортить проще.
P.S. просто если границы периодически сдвигают и что то выпадает, то дома проще сдвинуть и ошибку сложнее определить, т.к. точечные адреса вполне вероятны, тут нужен анализ изменения или лог
В этой модели это не “адрес дома” а просто адрес. Причем “здание” может иметь несколько адресов, даже если оно вовсе не угловое.
Zkir, однако, Берлин. Это не там где ОСМ наиболее прогрессивно?
Значит у них точки.
Кстати да, если несколько адресов, не 1-4, а 10-20, то схема addrN: уже не очень смотрится. Ибо, перебрать даже 10 тегов, а некоторых системах еще и в ручную перечислить - совсем не айс.
Имхо, прежде чем спорить о схемах задания адреса, стоило бы сначала разобраться с объектами адресации. А они, что характерно, в разных случаях разные - иногда это дом, иногда фасад дома, иногда подъезд, а иногда вообще нечто, не имеющее отношения к самому строению. И в разных случаях схемы нужны разные, поэтому обсуждать что-то без конкретных примеров бессмысленно.
(одновеременно стал писать о том же )
Начинаю понимать… addrN хорош для задания одного-двух альтернативных адресов (типа наших угловых) - это именно второй и т.д. адрес ** того же самого здания **. Точкой его ставить можно разве что для совместимости (такие точки можно генерировать при конвертации).
А вот когда дом состоит из частей с разными адресами - его надо либо резать, либо ставить адресные точки (всякие таунхаусы, адресация по подъездам и просто дома , расположение частей котоых неизвестно. То есть, точка вполне официально может заменить непрорисованный фрагмент дома, как она сейчас может заменять непрорисованное здание. В таких случаях напрашивается идея адресные теги на контур здания не ставить вообще (собственно, все, наверное, так и делают).
мы вроде как говорим об почтовой адресации. Но получается что тема из угловых домов перешла в вопрос адресации здания с несколькими адресами.
по подъездам всё просто, один подъезд - один адрес. Про остальные прошу высказаться остальных, сам с таким не встречался
Нет, мы не можем говорить о почтовой адресации, потому что объектом почтовой адресации является не строение, а некое лицо (адресат). Поэтому говорить имеет смысл об адресации строений.
В некоторых странах дома не нумеруется а подъезды Вот у них точно нет проблемы угловыми домами
В центре Рима тоже крайне интересно с номерами домов В каком-то здании я насчитал порядка 20 адресов … только в ОСМ этот дом не подписан. Вот один из типичных примеров - http://maps.google.com/?ie=UTF8&ll=41.898045,12.483644&spn=0.005151,0.011362&hnear=%D0%A1%D0%B0%D0%BD%D0%BA%D1%82-%D0%9F%D0%B5%D1%82%D0%B5%D1%80%D0%B1%D1%83%D1%80%D0%B3,+%D0%A0%D0%BE%D1%81%D1%81%D0%B8%D1%8F&t=m&z=17&layer=c&cbll=41.898151,12.481559&panoid=mYkriSGI_XTq-C2IpcuQ-Q&cbp=12,60.2,0,2.46, почти под каждой аркой свой “номер дома” - 260, 261, 262, …, 269.
То есть схема с точками гибче. Но вот сопоставление адреса POI по такой схеме не однозначно. Т.е. точка с табличкой с точки зрения truth on the ground это просто информационная табличка.
Схема с точками - это однозначный костыль для рендереров. Если мы хотим придерживаться объектовой модели, то она не годится.
А разгадка одна — требование уникальности тегов. В то время как удобнее было бы иметь произвольное количество одинаковых тегов и групп тегов. Но нельзя.