Эти нужные слова — посёлок и деревня

Дык надо привести к единому!

И я сомневаюсь, что в одном районе посёлок Морской и Морской посёлок могут быть двумя разными нас. пунктами

+100 !!! К многоязычным name это также подойдет.

“поселок городского типа” - в чистом виде официальный статус и вне “официальщины” сложно его представить

Я проанализировав вопрос в теме упомянутой ранее пришёл к выводу что должно быть только full_name. Это позволяет разобрать такие странные названия которые тем не менее существуют - посёлок отделения “2-я Пятилетка” совхоза “Красное Знамя”.

Или вот ( http://www.regionz.ru/index.php?ds=290912 ):

*В состав территорий поселений Аннинского муниципального района входят следующие населенные пункты:
Пугачевского сельского поселения - поселок Центральной усадьбы совхоза “Пугачевский”, поселок октябрьского отделения совхоза “Пугачевский”, поселок первомайского отделения совхоза “Пугачевский”; *

Раз уж нашлись единомышленники…
Такой вариант видится мне разумным по нескольким причинам.

Есть очень много объектов, чье наименование состоит из имени собственного и некой статусной части (поселок, село, затон, овраг, балка, луг, роща … ). Тащить все это в имя, по уже приводившимся выше причинам - неразумно и вредно. Отбрасывать, в надежде, что потом появится классификация, которая позволила бы это хранить - неоправданная потеря информации. Хотя бы по той причине, что статусная часть далеко не всегда является каким-то официальным признаком, по которому есть или может быть создана система тэгов, и в таком случае, статусная часть просто пропадает.

Скорее, имеет смысл закладывать в схему обозначений возможность сохранить статусную часть в виде строкового свойства, которое не вписывается в какую-либо классификацию (исключая случай, когда классификация для нее все же существует). Такой способ позволит: а) не терять часть названия уже сейчас, б) хранить ее отдельно от имени собственного, не создавая проблем с фильтрацией и обработкой, в) в случае, если это кому-то понадобится в будущем, проанализировать эту часть и присвоить на ее основании и основании других свойств объекта какой-либо новый тэг, если будет создана классификация.

Повторюсь: естественно, пользоваться строковыми свойствами префикса и суффикса названия имеет смысл только тогда, когда более никак нельзя отразить эту часть названия в тэгах.

Преимущества данной схемы? Недостаток всё тот же: это требует доделки всего софта.

Не будет поддержано в 90% в обоих случаях и задачи не такие сложные. Другое дело, что в первом случае это будет воспринимается как некрасивость, которую тот кто желает, сможет исправить. А в другом случае это ошибка, так как не будут различаться одноимённые НП вовсе.

Этот аргумент будет иметь место, если будет ясно зачем что-то отрезать. Как, я думал, из первого сообщения должно быть ясно, статусная часть должна использоваться совместно, как при отображении, так и при поиске. Зачем может потребоваться часть без статуса — как раз совсем не ясно. Разве что для сортировки, но для этого есть sorting_name, и одним убиранием статусной части там не обойтись (нужно ещё, например, номера из начала убирать).

То есть, от всех желающих не ставить статусную часть в name хотелось бы:
— узнать практическую пользу от такого действия, дабы эти аргументы перевесили простое решение;
— почему те же самые аргументы не прокатили с улицами.
Если это нужно лишь для узкого круга технических и научно-исследовательских задач, то именно для этого я предложил дублирование, чтобы это не затрагивало всех остальных, ну или использовать другие используемые теги, типа cladr:suffix.

Выпилить статус если он известен из названия проще чем приклеивать.

for(String status_part:status.split()){
name = name.replace(status_part, “”).trim();
}

Используется 2 тега name и status без status:prefix status:postfix status:somewhereelse, они точно также интернационализируются не меняя схемы получения краткого наименования. Не надо париться с префиксной постфиксной записью и прочей ебаторией. При этом нет проблем определить стаус и фильтрануть по нему или еще какнибудь обработать. Это прокатит для статусной части в начале, конце, середине и вообще незнамо где. И вроде это уже предлагалось не раз.

А вообще, если уж статусная часть у улиц не мешает, чем она мешает у населенных пунктов? Там места для подписи - вагон. Взрослые поисковики ищут по вхожденим слов. Для искалок в навигаторах нужен манглер как для улиц. Который бы убирал, переставлял, сокращал статус. И не видно причин почему он будет сложнее чем оный для улиц.

А теперь тоже самое в виде патча к стилю мапника для osm.org

dkiselev
Осталось заставить мапник убирать статусную часть. Ах, да, мы же не рисуем под рендер… сначала вставить статусные части куда ни попадя, а реальные пользователи пусть трахаются сами. Главное - кошерность базы. Тогда проект надо было назвать OpenStreetDB.

(upd)
упс, опередили

Sergey Astakhov, а зачем? Я еще понимаю что улицы часто бьются на сегменты и длинные названия хреново влазят, но уж блин колхозы можно на мапнике подписывать томами из Льва Николаевича.

В чем простите меня трахотня, если подпись на мапнике будет содержать деревня, поселок, рабочий поселок, поселок городского типа? Трахотня что у нас поиск через жопу работает, нашли блин трахотню.

Не все так просто, как кажеться

И делается это на патчами к стилю мапника, а в виде плагина к осмосису, если уж так уперлось статусную часть с мапника сокращать. Ну или уж признаться всем наконец что name у нас для мапника и для подписей. А имя, которое имя собственное уникальное и все такое, фигачить в full_name, и на него же натравливать обрезалки/прибавлялки статусных частей.

Ок попрактикуемся в написании регулярок, добавим требование отсутсвия символов составлющих слова до и после вырезаемой статусной части.

В тулчейне мапника осмозис не используется.

Это как бы уже не первый год очевидно.
name - это основное отображаемое название

Либо если не нравятся регулярки


for(String status_part:status.split()){
         name = (" " + name + " ").replace(" " + status_part + " ", "").trim();
    }

За багрепорт спасибо :slight_smile:

Ну тогда должно быть очевидно, что строя адресную иерархию, основываясь по сути тлько на label объекта, не стоит ожидать что label будет уникальным в рамках региона.