Помоему нам нужно структурировать то что наобсуждали.
Что адресуется? Здания, участки, что еще?
Что мапим? Аншлаги, Адреса по прописке, почтовые адреса, как выбираем если они конфликтуют?
Дальше табличка с различными случаями зданий по столбцам:
Одно здание с одним адресом. Здание с пристроем. Здание с секциями (делить не делить на части). Здание угловое с несколькими адресами по разным улицам. Здание учавствующее в нескольких видах адресации: жилой комплекс/здание + улица дом – к примеру. Что еще я забыл?
И способы задания адреса по строкам: точками, streetN, addrN, с распиливанием. Ну и выбрать какой способ для какого случая удобнее - и как его лучше применять. К примеру ставить ли точки с адресом внутрь пристроев и т.д. Ну или хотябы ранжировать какой способ рекомендован для какого из вариантов, какой нет и почему.
Как будет обрабатываться: Пои по адресу, адреса для пои, пои по зданию, адреса для здания, конвертация, геокодинг.
Просто мне кажется что обсуждение “поплыло”.
Я могу нарисовать в вики. только обычно в пылу дискуссии на форуме в вики не особо смотрят.
Согласен. Но дискуссия кончится, а вики-то останется! Вики - дело благородное.
Постараюсь цивилизованно попридираться, когда что-нибудь будет готово (у самого с точными формулировками не очень, так что не лезу).
Да, об этом и речь. Просто к carlsrue никто придираться не будет, поэтому её можно было бы выделить отдельно (и пометить как неприменимую к сложным случаям). Но это на усмотрение автора.
Давайте вернемся к обсуждению. Я конечно могу сделать как чуваки с lanes general extension: голосуем, раз, два, три – кто не успел возразить - тот опоздал, но толку не будет.
Табличку я всетаки заводил как иллюстрацию к обсуждению а не как ответ на все вопросы.
Итак, что я думаю по теме:
A (Земельные участки) - если участок отмечен полигоном - отмечать через карлсруе простовляя тэги на полигон. Если внутри есть строения с отличным адресом - то их так же адресовать через атрибуты на контуре здания. Если полигона нет - адрес задавать точкой, (а лучше добавить полигон). Если адресов у участка несколько - AddrN
B - карлсруэ
С (здание с пристроем / из секций с 1 адресом) - копируем тэги на все секции.
D (угловое без пристроек) - AddrN (продолжаем спор с Питером )
E (угловое с пристройками) -AddrN, тэги с адресами копируем на все куски здания.
F (длинные здания, имеющие несколько формально выделенных секций с разными адресами для удобства) - распилить на секции, тэги на секции. Это не тоже самое что распилить домик по диагонали, лишь бы в мапнике красиво было.
G - не знаю что будет лучше распилить или 2 точки внурь воткнуть (если в здании будут пои - то за распилить).
H - AddrN, кто бы сомневался что я его выберу.
I - Атрибуты ставим на сам релейшен. За полигоны с накладывающимися/сопрягающимися аутерами - я бы ругался, хотя вроде никому это проблем особых не создает. Но всеравно бяка.
Вот что я подумал на днях, как разработчик поисковика. addrN сложно поддерживать SQL-скриптами кроме addrN (1-4) еще есть всякие сочетания, которые надо учитывать и это не просто. Я понимаю что под рендеры/навигаторы/пр. мы не рисуем, но надо к ним тоже прислушиваться, если данными будет тяжело пользоваться, то и программ не будет. А кому нужны голые данные, которые нечем обработать/посмотреть?
** ErshKUS понял, что его поисковик не совсем правильно работает по addrN схеме, и научить будет не просто *
P.S.
В “C” предлагаю отношения, они как бы для этого, чтоб не дублировать информацию и указании единой сущности. А так получаем дублирование адресов и не ясно ошибка это или так и надо
A (участки) - возможно ли что-то кроме Карлруэ? Участки с несколькими адресами мне неизвестны.
B (нормальные одиночные дома) - Карлруэ без вариантов, но стоит уточнить, что если форма неизвестна, надо ставить точку с адресом и building=yes.
С (дом из кусков с 1 адресом) - согласен, либо копируем теги (хотя адреса будут повторяться - для валидации не очень), либо поддерживаем адрес на неком отношении (building? multipart? multipolygon с несколькими outer?). С учётом 3D в среднесрочной перспективе без отношений всё рано никак.
D - если у углового дома два номера (первая 15 = вторая 22), то однозначно AddrN, а если номером (на табличке, в паспортах) является 15/22, то надо думать и обсуждать.
E - сначало с обычными угловыми решить надо
F - я за распил на секции, но в случае неизвестной формы секций (всякие дома-кресты-загогулины, замапенные без знания планирорвки) можно согласиться с точками внутри (точка = где-то здесь секция 100а).
G - принципиально не отличается от F, но расположение известно реже. Либо грубо делить, либо точки.
H - да, тут AddrN наиболее логичен (если в доме нет двух сущностей с разными адресами). Точки внутри только в случае POI.
I (мультиполигон) - теги на мультиполигон. Кусковые дома с разными адресами делим на мультиполигоны
Ну, главное - чтобы первый адрес искал). А дальше - если поиск по тегам делать (названия магазинов, операторы АЗС, и. т. д.), то прочие теги всё равно обрабатывать… Можно OSM-препроцессор сделать для выдёргивания адресов.
Препроцессор полюбому нужен. Если следовать тому как AddrN задумывалась то доп адресов - один, в собо тяжких случаях - 2. Схема не задумывалась для случая F. (Это я к тому, что вариант, обрабатывать первые 4 - вполне годен).
По поводу склейки пристроек с основным зданием релейшеном, вроде еще в предыдущем обсуждении предлагалось. Тут будет проще с рендерингом (т.к. адрес указан 1 раз) но сложнее с препроцессингом пои. по всей видимости если таковой писать - то надо будет его учить как распространять адреса на пристройки, возможно используя релейшен, так и наоборот, для рендера оставлять адрес, к примеру, на самом крупном, из соприкасающихся, куске.
Дом c адресом Улица1 д.1/2 может быть: Улица2 д.2/1, Улица1 д.1, Улица2 д.2.
addr:housenumber=1/2
addr:housenumber2=1
addr2:housenumber=2/1
addr:housenumber2=2
Не обязательно все на одном доме, но вариантов уже больше чем два и проверять придется все. Страшно подумать о домах 1/2/3. Вложенные циклы. Хорошо у нас ограничились 1/2 :).
Если addr:housenumber=1/2 + addr:street2 + addr:street то дом по запросу Улица2 дом 2, улица 2 дом 2/1 не будет находиться. При поиске точного совпадения не будет находиться и Улица 1 дом 1. Чтобы получить остальные адреса понадобиться препроцессинг. Ну либо, 2 запроса: на первый адрес + запрос с функцией которая переставит 1/2 на 2/1 и присобачит улицу из street2, проверив, что она есть. И опять же вы таким запросом выдернете адреса вида Улица 1 дом 1/2 и Улица 2 дом 2/1 т.е. вы не получите адреса дом 1 и дом 2.
С точками - свои заморочки с поиском пои, ну и опять же определить по точкам надо ли делать для дома составной адрес через дробь - невозможно.
Воткните 2 запроса addr:housenumber=1/2 и addr2:housenumber=2/1 - так, при нестрогом совпадении, вы найдете дом по всем четырем запросам. Т.е. без поддержки addrN:streetN (собственно в первоначальном варианте ее и небыло да и необязательно эту фишку поддерживать).
Давайте все же варианты сравнивать между собой. Написать недостатки любой из схем я и сам могу, да и не только я.
По хорошему, при подготовке данных нужно:
для рендеринга: соеденить дом1, дом 2 в 1/2 и оставить этот адрес на самом большом куске здания, удалив с остальных, либо сгенерировать 2 точки с адресами по каждой из улиц.
для поиска и обработки пои: наоборот проставить адреса всем примитивам здания нагенерив все возможные варианты записи адреса (1/2, 2/1, 1, 2 с соответствующими улицами)
*