Увы, но без pos я не вижу как можно сохранить type=route.
Если порядок утрамбовать в role, получается ещё хуже.
role = path:3.1
role = stop:15
role = platform:15
ИМХО “адресная точка” итак существует, где-то это явно отдельная точка, где-то нет, с вытекающими ситуациями с угловыми домами и рендеренгом name вместо адреса.
Не соглашусь, если я Вас правильно понял, так как связь через теги не является строгой, те битые связи, сложность переименования и наличие неоределённости характерны для такого типа связи. У связи по ссылке таких проблем нет, то есть сейчас отношения обладают свойствами более подходящими для связей. Поэтому не соглашусь с выводом, что отсюда вытекает правило “Relations are not Categories”.
Конечно coastline это интересно, но по объёмности геометрии они не стоят рядом с адресом или улицами.
Уже сейчас есть отношения street, waterway. На простых объектах просто всё, трудности проявляются когда объект становится довольно сложным или появляются всякого рода связи между объектами.
Собственно данное предложение вместо запрета просто наделяет way и node свойствами relation (иметь ссылки на другие объекты), стирая различие между ними.
С другой стороны - переворачивается использование, теперь линия не сможет описывать несколько объектов с общей геометрией, ибо она и есть объект.
Да. Но зато связь через тэги проще проставляется и проще организуется в условиях не полной информации.
А связь через отношение сложнее редактируется. Маршруты общественного транспорта до сих пор ломают при разрезке улиц.
Простите, не совсем понятно про не полную информацию.
Позволю себе повториться: у всех подходов (теги/отношения/др.) есть минусы и плюсы.
Это вполне ожидаемо ввиду схемы данных при отсутсвии обработки разделения члена отношения. В текущих реалиях либо другую схему предлагать, либо корректно обрабатывать на уровне редактора.
Например, дороги нарисованы, но названий нет, отношений нет, вам известен 1 адрес у магазина. Вы его добавлете, создаёте отношение, в котором ровно 1 адрес. Потом кто-то добавляет другой адрес на этой же улице, может опять создать отношение той же улицы, опять с 1 адресом. Потом кто-то ещё может проставить название улицы. Ну и так далее.
Там нет ещё голосования. Да и судя по картинке в статье складывается впечатление, что отношение заменяет геометрическую вложенность, а следовательно не привносит ни чего нового, поэтому обречено на провал.
Как переведу (скоро) в статус «голосование», сделаю мини-инструкцию-образец. Пока можно ознакомиться с самим принципом и решить, стоит ли голосовать и как.
Оно заменяет все «мутные» на сегодня случаи и не только. Разумеется, оно не применимо к индивидуальной (уникальной) адресации входов и т. п., но там ничего нового придумывать и не требуется.
Добавлю ещё несколько соображений в пользу своего предложения. Есть несколько «побочных эффектов», позволяющих улучшить не только способ адресации.
Во-первых, это облегчение и оптимизация рендеринга адресной информации: располагая адресные точки на той стороне периметра полигона здания, которая (как правило) параллельна соответствующей ближайшей улице или примерно посередине условного центра фасада, мы однозначно задаём для рендера оптимальное место вывода номера здания. Это избавляет от необходимости совершать вычисления геометрического центра (особенно для нетривиальной геометрии) и оставляет место для названия, например.
Во-вторых, это позволяет сделать адресные точки интерактивными (без необходимости их генерировать, вычисляя место расположения) и выводить по клику адресную информацию.
В-третьих, учитывая, что это не «голые» адресные точки, а — часть отношения, включающего в себя все адресуемые объекты (в торговом центре, например, или офисном здании), то дополнительно ко второму пункту можно будет реализовать функцию «что находится по этому адресу?» с выводом, опять же, готового списка и без необходимости препроцессинга с учётом геометрической вложенности.
Адресный поиск также значительно оптимизируется, получая готовые таблицы адресов и привязанных к ним объектов.
UPD Свободно ищутся условные «Гончарная, 10» и «Ремесленная, 49» для одного углового дома. Запросы типа «Гончарная, 10/49» или «Ремесленная, 49/10» легко «выводятся» из отношения, где в качестве участников фигурируют точки с соответствующими addr:street/addr:housenumber.
На каком скриншоте адресная метка для здания гимназии адекватнее? (адрес: «проспект Победы, 29А»)
Первый
Второй
- Номера домов поворачиваются к улице например на ренедере Чепецк.нет, т.е. острой необходимости в дополнительном отношении нет.
- Основная масса всё равно требует геометрической вложенности, значит выйгрышь опять нулевой.
- А если вдруг не включили в отношение значит потеряли объект, опять минус.
- Разве дело в поворачивании надписей? В чём дело — выделено жирным, и не запрещает поворачивать как угодно и что угодно (что и делает совершенно спокойно чепецкий рендер). Только даже без вращения мы получаем наглядную, интуитивно понятную пространственную ориентацию адресных меток.
- Какая основная масса имеется в виду и для чего требуется вложенность?
- А если, вдруг — астероид 10 км в поперечнике? Странная аргументация и не менее странный вывод. Мультиполигоны накрываются полностью медным тазом, если малейшая ошибка есть и — что? Адресная точка же никуда не денется, равно как и POI, пусть даже не включённая в отношение (и у них всегда есть очень хороший «адрес», называющийся «координаты», который прекрасно учитывается в навигаторах, например, когда мы ищем ближайшие объекты, понятия не имея об их адресах)
И не существует такой системы, которая исключает ошибки. Их можно только минимизировать (ясно и просто описав правильный способ внесения данных и предоставив для этого удобный инструментарий) и дополнительно иметь «обходной путь» на случай неполноты данных или ошибок (те же координаты).
UPD Наглядный пример для первого пункта: »район частной застройки«(там в окрестностях можно найти примеры для наглядного сравнения, по которым ни черта не понятно: циферки и циферки)
Глянул в JOSM на все это глазами человека никогда ничего не вносившего в карты OSM (позвал его специально посмотреть) и попросил его рассказать что он по этому поводу думает - по поводу отрисовки нового домика, занесения его в релейшены и отметки адреса… Мне сказали что даже не будут пытаться понимать как это сделать - ибо все это не естественно. При этом обычная система без всяких этих рюшек никаких затруднений не создала… Я лично смотрю что даже так называемая “белорусская система” адресации была проще 
По поводу вращения надписей - все кто хочет уже научились их поворачивать как угодно, если мапник это не умеет делать - то ради него что ли городить такую хрень? К тому же такой внешний вид вывода номера домика на его границе как по мне - так совсем не хорошо…
P.S. Хочется процитировать профессора Преображенского из фильма “Собачье сердце” - после того как он услышал пение жильцов…
Смысл в том, что в текущих реалиях нужно поддерживать и текущую схему и предложенную. И в этом случае предложенная ни даёт никаких плюсов. Плюсы открываются, только когда мы откажемся от старой, но это не реально.
В том то и дело, что в приведенном примере с полигонов домиков удалены все теги адресации, то есть получается что если их оставить то будет полная каша адрески по состоянию на сейчас.
По мне - это недостаток. Ту работу, что можно сделать программно, без вмешательства маппера, вы пытаетесь свалить на его хрупкие плечи.
mixdm, ещё бы глазами Шарика глянули. А я вашему человеку так растолкую, что он сам кого хочешь потом научит.
Да при чём тут вращение? Оно может быть, может — нет, без разницы (мне на него начхать, и моё предложение не имеет к нему никакого отношения, если до этого было непонятно). Аргументация в стиле «совсем не хорошо» чем-то подкрепляется? У вас гипертрофированно закостенелый взгляд на OSM. И это сквозит открытым текстом в каждом сообщении.
Неужели, всё-таки, есть плюсы? Польщён слышать это от freeExec.
wowik, обо всём, что касается «хрупкости плеч» я полностью поддерживаю уважаемого BushmanK.
И на всякий случай напомню: в простейших случаях (домики частной застройки) даже не требуется отношение, чтобы всё работало (собственно, с этого я и начинал здесь). Оно становится очень удобным и желательным для однозначной привязки множества объектов к одному, а — главным образом — нескольким адресам.
А указанные дополнительные «плюшки» на то и дополнительные, что не являются самоцелью, но и не такие уж бесполезные.
Короче, ребята. Голосуем ЗА и сделаем «нереальное» реальным. Подробное описание в картинках и даже видео готов сделать, чтобы не возникало никаких недопониманий даже у хрупких новичков.
Я имел в виду Myth of Newbie, резюме оттуда же:
«My claim is that currently Newbie is a mythical creature, that serves for rhetorical (demagogic) purposes. Its imaginary character is ridiculous: shy, illiterate, clumsy, stupid, incapable to learn, emotionally unstable and fragile, aggressive, ignorant, but in the same time - precious and very important for further OSM improvement and development. These epithets are not my fantasy - I took it from different statements, where reference to newbies was used for reasoning.»
Да и на форуме он неоднократно об этом говорил.
Неоднократно всплывали обсуждения (как минимум, 1-2 года назад здесь, на форуме, и с пол года назад на ОСМ Радио) до боли простой схемы, а именно Карлсруэ на релейшене. Минимальное усложнение от всем привычного Карлсруэ, нужно лишь теги на релейшене указывать. Зато, тут вам и мультиадреска, и объединение пачки домиков в один адрес, и простор для расширений, как то, добавление веев улицы, адресуемый ландузе, мейн буилдинг (до которого мог бы строится маршрут по адресу в навигаторах) и т.д. и т.п.
Но вместо этого появляются пропозалы на значительно более сложные схемы со значительно меньшей “функциональностью”…