Как я посмотрю, часто (я этим сам грешу) адреса ставятся на полигон с домом, но не на пристройку. Это плохо, потому что все POI, которые в этой пристройке находятся, остаются без адреса. Вопрос: какой на данный момент лучший с практической точки зрения способ задать им адреса? Проставить обычные addr: на пристройку, или объединить всё здание в мультиполигон с адресом на отношении (а на полигонах оставить только building:levels)? Кто нормально понимает мультиполигон? Судя по всему, мапник рисует адрес на всех полигонах, osmarender рисует один раз (молодец), mapsurfer один раз, но не понимает buillding:levels на полигонах, nominatim вроде такие здания не ищет (плохо). Лёшин валидатор работает нормально, geofabrik вообще не умеет.
Второй вопрос: что допустимо в addr:housename? Есть у меня выгрузка с housename, так там чего только нет - “Спортзал”, названия POI, названия ТСЖ, дублированный housenumber. Есть идея это почистить. Думаю, номер дома надо однозначно оставить в housenumber, из остальных полей (housename и name) - убрать. Название POI - в name, а что оставить в housenumber не совсем понятно. Думаю, название ТСЖ там вполне к месту.
Я в этом случае оставляю пристройку без адреса, а у POI добавляю адресную информацию. Сейчас, правда, Лёшин конвертор умеет вытаскивать адреса для POI из адреса полигона, но номинатим пока не умеет и берет адреса как раз из адресных тегов POI.
Смотря как объединить. Можно сделать мультиполигон не только для здания (с адресом), но и для отдельных его частей (с указанием этажности). Соответственно, в мультиполигон с адресом включить только внешние стены всего здания — тогда адрес будет рендерится один раз.
Поддерживается наверно не везде, но точнее сказать сложно — многие альтернативные рендеры давно не обновляются, в т.ч. вышеупомянутый MapSurfer. Cloudmade поддерживает, в других известных мне рендерах тоже не должно быть проблем — это стандартный мультиполигон. Nominatim находит университет (только что проверил), номера домов-мультиполигонов вроде не понимает, хотя может я не разобрался как там искать дома с корпусами и строениями.
А вот мультиполигон из наложенных полигонов вряд ли можно считать стандартным и топологически правильным.
Это, наверное, самый правильный вариант, но, блин, хреново это поддерживается в редакторах…
Ещё один вариант - не париться с мультиполигонами, а просто добавлять один общий адресный контур. Типа фундамент с адресом, поверх которого стоят здания с разными level-ами.
Так информация дублируется многократно, имхо не лучший вариант.
Это вариант. Но подходит не всегда - в приведённом примере здания отдельно, а university отдельно - это можно было и без мультиполигонов сделать. В моём так не получится - здание одно. Если только сделать части building’ами без адреса, а все вместе - адресом без building’а, но имхо это криво - адрес все-таки у самого здания, а не территории, на которой оно находится.
Формально нужно объединять все строения с одним адресом в отношение, на которое и вешать адресные теги. На практике это жутко неудобно. Я ставлю адреса на всё.
Не совсем по теме но ИМХО имеет смысл добавлять адрес к POI. С тегов зданий, наоборот убирать всякие amenty, shop и т.д. Должно быть просто здание, а всякие обвесы оформлять в виде POI.
Теги адреса у POI позволят однозначно его идентифицировать и использовать в проектах подобных этому: http://www.maps51.ru Правда, в этом проекте разрабртчик использует собственную базу POI, поскольку считает, что так ему будет проще поддерживать её в актуальном состоянии, плюс не хочет засорять ОСМ избыточной информацией. При этом он готов экспортировать данные в ОСМ (например, обновить время работы кафешки или изменившийся номер телефона, или вообще удалить точку,если заведение закрылолсь), вот тут почтовый адрес в POI просто необходим.
Дык он есть, только не на каждой точке, а один раз на доме. Приколько будет поддерживать mall с тысячей магазинов, задавая для каждого адрес. А особенно учитывая что у нас творится с адресами (по разным улицам, официальные и on-ground, с разными комбинациями дробей и т.д.).
Не согласен. Если заведение занимает все здание - то оно и есть здание и тэги должны быть на здании.
А я ничего плохого в адресации точек POI, как самостоятельных объектов не вижу, аля вывески на магазинах, на каждой вывеске или контактах фирмы на сайте тоже есть адрес, причем бывает и не редко, он отличается от адреса дома, строением там или дробью, или еще какой неправильной мелочью. И многие ли сервисы умеют вытаскивать адрес из полигона на точку? Или, например, сдвинули дом по подложке, а пара точек выехало за границу, кто за этим следить будет? Мы же не только к идеальной нормальной форме БД стремимся, в конце концов.
Если не умеют - пусть учатся. В перспективе адрес на доме ничем не хуже адреса на POI (потому как он есть). А лучше тем, что адреса (включая все разночтения с дробями и прочим) будут в одном месте, и будут работать для всех точек сразу, и дублирования нет. Хотя вообще говоря для POI имеет смысл юридический адрес указывать.
Я, и не только я, хочу видеть адрес точки при поиске сейчас, а не когда кто-то чему-то научится.
А что здесь поддерживать, название улицы поди не часто меняется?
Да и на адресацию на доме и на POI (которые на доме) немного по разному смотрю, адрес дома истиный и используется для адресного поиска и пусть показываются POI которые на этом доме, аля поиск по адресу в Яндексе, а адресная состовляющая POI дополнение к вывеске (как выше было сказано в этой вывеске адрес может отличаться от истинного), которая покажется при поиске POI, например по названию.
Так допилите поиск. Я в мапнике тоже хочу 3D здания, но я же не пририсовываю зданиям стены в проекции.
Надо в очередной раз напоминать почему люди хотят обозначать улицы relation’ами, сколько реально адресов обозначено в Москве и сколько при этом правильно?
извините, но я а) не буду перелопачивать тысячи собранных poi, добавляя им адрес, только потому что какая-то сомнительная программа не умеет вытаскивать адреса из содержащих их домов; б) не вижу смысла проставлять адреса для poi, потому что это всё усложняет и вносит избыточность, что мне, как программисту, работающему с базами данных и ценящему нормализацию, мозолит глаз.
Тогда присутствие в географических названичях слов “улица”, “остров” и т.д. должно просто бесить, ибо чудовищный косяк с точки зрения нормализации БД! Я этот явный мусор в названия не пишу, однако чуствую, что вменяемого рендера, который будет дописывать эти префиксы автоматически ожидать не стоит.
Не могу судить на 100% уверенно, но подозреваю, что индексирование точек POI посредством нахождения полигона, в котором они расположены требует существенно больших вычислительных затрат в сравнении с вульгарным строковым индексом. Впрочем, если ступни программиста покоятся на тёплом ящике с бездонными вычислительными ресурсами, тогда да, волноваться не о чем. Абсолютное большинство и не волнуется. Не оттого ли все геоинформационные приложения, работающие на мобильных платформах в плане быстродействия - унылое говно?
Абсолютно ничего не теряем, напротив, получаем взамен внятную и однообразную структуру данных, а не “в лес - по дрова”. Ставим POI и туда заносим все необходимое. Даже с точкит зрения рендера есть удобства - сохраняется номер здания на карте.
Вам не кажется, что архитектурное сооружение и организация, которая это сооружение использует суть разные вещи и эта разница должна имет отражение в структуре БД?
С точки зрения лени проблем не вижу, ибо редактировать POI намного удобнее. Их, как минимум, сразу видно в редакторе, а building - чёрный ящик. Пока не ткнёшь мышом, не ясно есть там чего или нет.
Опять же, если эффективному менагеру захочется внести свой “ООО Лабеан” в OSM, то весьма желательно подсунуть ему редактор POI типа этого: http://ae.osmsurround.org/ae/index чтоб он не перся самостоятельно править теги на buldinge, как говорится, “во избежании…”
Территорию больниц/детсадов при помощи POI и тегов на здании отмечать не собираюсь. Для этого есть другие средства.
Если один пишет “Строителей” другой “Строителей улица”, третий “Строителей ул.”, то, конечно, не получится. Ибо это уже не БД, а бордель. (Что мы и имеем в реальности.) Тем не менее, небольшие города обычно делаются “в одну харю” и там вполне можно соблюдать жесткие и однозначные правила адресации.
Однообразную - да, а вот на счёт внятности - не согласен.
Нифига подобного. Сразу видно только то для чего есть соответствующая иконка у редактора (по крайней мере в JOSM). Как только ставишь тег, который редактор не знает (например тот же office) - получаешь просто точку. “Пока не ткнёшь мышом, не ясно есть там чего или нет.”. А здания с тегами, известными редактору так же отличаются, так что не вижу особой разницы.
Какие именно?
На небольших объёмах хорошо работают даже самые кривые и примитивные алгоритмы. Хороший алгоритм тем и отличается, что его относительно легко и удобно масштабировать.