Нет категоричной формы, это во-первых. Во-вторых, попробуйте указать несколько адресов на POI или на контуре здания. Мой вариант подразумевает реальность решения «задачи геометрической вложенности» для получения адреса из адресных точек. Да, по поводу того, что это уже делается я погорячился (принял желаемое за действительное), но что это работающий метод — факт. Рендеринг тоже «не напрягается» в этом случае никак, он делает то и так, как делал раньше.
Где эта схема работает?
Явное указание не требуется. Алгоритм, вычисляющий адрес, «видя» угловой дом с адресными точками и нашпигованный точками-POI без адресных тегов, интерполирует адресную информацию на все вложенные объекты. Алгоритм, найдя пачку POI с адресами или дом с адресованными входами, ничего не будет делать, кроме извлечения готового и записи в какой-либо «свой» формат. Не должно быть мешанины, когда и здание имеет адрес/а, и каждый вход в нём же имеет свой отдельный адрес. Или такое где-то есть? Даже если так — не вижу в этом никакой проблемы: индивидуальные (уникальные) адреса тогда имеют приоритет, а интерполяция не применяется.
Да, будет проблема с POI, где прописан адрес криво и он отличается от адреса на контуре здания (псевдоуникальный). Так это и сейчас проблема и с этим надо бороться, что и предлагается в виде упорядочивания системы адресации. Чем больше внесений одного и того же адреса разными людьми (и при неразберихе в методике), тем выше вероятность появления ошибок и ухудшения качества данных. Более того — это просто неизбежно изначально, из-за полного раздрая в этом вопросе.
Это правильно замечено, НО форум — лишь удобная площадка для обсуждения и выработки подхода (разве не очевидно?). А потом ничто не мешает внести это на страницы wiki, вместо той каши, которая сейчас там предлагается для «употребления». Подход «придумай всякую отбалдятину и чёрт его знает, как это будет работать» явно тупиковый. Мой подход основан на рабочем опыте, выраженном в конвертерах, рендерерах, поисковых системах (геокодерах).
«Делай, что можешь, с тем, что имеешь, там, где ты есть.»(c)
Про попробуйте ниже, то что задача геометрической вложенности решаема - никто не спорит. Но это не равно задаче сопоставления адреса - ПОИ. Возникают случаи когда сопоставление неоднозначно.
Это четыре разных схемы для указания нескольких адресов на контуре здания/контуре пои/контуре точки.
Где работают - смотри taginfo.
Давай на ты?
И алгоритмы работы с адресами кого из них ты смотрел?
Как собираешься отделять адрес на адресной точки и адрес указанный в пои чтобы назначит его дому? Очень часто вижу, что торговые сети вообще не парятся по такому поводу - во всяких свидетельствах и лицензиях, висящих в магазине, значится дом 2, а по факту дом 2 строение 1. Поэтому адрес с пои я бы вообще никуда не брал, кроме него самого.
Это не совсем корректная фраза, по крайней мере для СПб. “Литера” есть абсолютно у всех зданий. Адреса в традиционном почтовом понимании (типа “дом 2”, “дом 2 корпус 5”, “дом 2в”) относятся не к домам, а к владениям, на которых может быть одно или более строений, обозначаемых литерами. Но в подавляющем большинстве случаев строение только одно, обозначаемое литерой А, соответственно ее обычно не пишут. Хотя иногда она проникает и на таблички домов.
В Москве, помнится, примерно то же самое, только вместо литер — “строения”, обозначаемые цифрами. Есть подробный официальный документ об этом.
Имел в виду не территориально «где?», а в каких приложениях.
Мне алгоритмы смотреть бесполезно (разве принципиальную схему, не более). Могу судить только по результатам, только в качестве пользователя. Nominatim работает? Да. На osm.ru свой поисковик, если не ошибаюсь. Весь околонавигационный OSM-софт (7ways, OsmAnd, Mapsme, карты под Garmin, Navitel, ПроГород, был ещё СитиГид). Мало?
Вся новизна в том, чтобы начать использовать геометрию с участием адресных точек, ничего сверх. А для этого надо целенаправленно упорядочить внесение данных на этапе «я хочу, а как же мне это сделать?» (документацию читать сейчас, скорее вредно, чем полезно).
Повторюсь в который раз: если у точки есть свой уникальный, особенный, отличный от всех и реально применяемый адрес, то никто же не запрещает вносить его именно (и только!) для этой точки. Реально применяемый я понимаю так, например:
а) выдаётся водителю «разнарядка» на день/дни работы, в ней расписаны точки разгрузки товара с адресами и в накладных эти адреса прописаны;
б) делает человек заказ в интернет-магазине, указывает свой домашний или рабочий адрес;
в) в учредительных документах кафе прописан адрес.
О случаях ошибок, недосмотра и чистого идиотизма говорить нет смысла, т. к. с этим не справится никакая схема тегирования. Можно лишь сократить вероятность, а значит и количество разных ошибок и неточностей, внеся большую ясность и единообразие.
А, то есть теперь я пометку “fixme/note=уточнить адрес” теперь поставить не могу, адресация на входе тоже отваливается. Уж молчу про всякие source, syrvey и прочие anyTagForYou.
Вот даже всю тему читать не охота, хотя стоит. Вот вам аргумент для street-отношений, что б не заносили в каждый дом тег wikipedia= … → гляньте на страницу (внимание! Хунта не дремлет!) (к примеру) [улица Артема](http://uk.wikipedia.org/wiki/Вулиця Артема (Донецьк)), и нажмите на кнопку глобуса викиминиатласа или ‘показать карту’… И решайте чего оно стоит - связывать все обьекты улицы через названия на каждом обекте, или все обьекты группировать по общем!.у названию единой сущеости.
Если есть подобные примеры ‘на костылях’ приведите, интересна сложность их реализации.
Возможно. Поэтому и говорю, что аналог литеры там называется “строение”. Документ именно про нумерацию московских строений имелся в виду. Хотя грань между инвентаризацией и адресацией довольно хрупка. Литеры СПб - это тоже не почтовый адрес, а скорее учетно-инвентаризационный.
Ребята, что касатся двойных (и более)) адресов копайте в сторону отношений! Они все єто позволяют! Хотя схему тегирования элементов отношений есть смысл, и потенциал, расширить.
Надо признать, что для однозначной привязки адресных точек ко всем «адресуемым» объектам — лучшего способа, чем отношение, не придумаешь. associatedStreet увязывает линии дорог-улиц с уже адресованными объектами (street+house). Оно не решает проблемы «мультиадреса» у объекта или кучи объектов с одинаковым адресом (который может быть ещё и «мульти»).
Требуется отношение вроде associatedAddress, в котором будут address+object. Само отношение не будет нести никаких тегов, а станет тем каркасом и фильтром, который снимет обязательность (но не желательность!) геометрической привязки и всяческие другие неоднозначности и лишние операции.
«Принято» бояться отношений, но страшного ничего нет и многое (если не всё) становится на свои места.
Так почему бы не воспользоваться хорошим «инструментом» в виде relation type=associatedAddress?
Оно, в свою очередь, может (но не обязано!) — по аналогии с мастер-маршрутами — быть включено в associatedStreet в роли house, и никто не уйдёт обиженным.
Этот способ привязывает только саму адресную точку и контур дома (как замечено выше). А где решение по поводу
?
Ведь упирается вся эта кухня в точечные POI. Кстати, associatedStreet в показанном примере по сути ничего не меняет. И без этого отношения будут спокойно отыскиваться и точка, и контур дома по соответствующим адресным запросам (только улицу надо, как сейчас, прописывать, конечно).
А поменять картинку должен associatedAddress, где будет всё красиво и просто.
Вот сделал вандальную правку для дома сугубо примера наглядного ради. Просьба к Эдуарду: после ознакомления сжечь откатить, чтобы никто не волновался.
А ежели понравится — так оставляйте, будет почин.
На случай, если Эдуард поспешит с откатом, создал в своей вотчине (сам и прослежу) предлагаемое отношение. Обратите внимание, что оно является дочерним по отношению к associatedStreet, которое создал попутно. С этим вовсе не обязательно заморачиваться, делал только для примера.
В данном примере можно добавлять сколько угодно адресных точек, включаемых в отношение и автоматически «адресующих» все объекты (от контура здания, до POI), а впоследствии легко и просто добавлять сколько угодно POI с тем же эффектом.
Адресные тэги проставлены и на здание, и на адресную точку. Дублирование, что есть нехорошо. Рекормендую в таких случаях вообще не создавать адресную точку, а здание с проставленным адресом включать в отношение дважды: один раз с ролью object (чтобы показать адресуемый объект), второй раз с ролью address (показать, что именно отсюда следует брать адрес).
Зачем нам это труднопроизносимое в camel-Case-стиле тэгирование – “associatedAddress”? Давайте назовём тип отношения просто “address”. Несколько раз набирал “associatedAddress”, пальцы запутывались в клавишах каждый раз.
