ё
А также с заглавной буквы или нет? До или после названия? Что писать в int_name и name:en?
Статусная часть же, со строчной.
Можно подробнее? Скажем список нп и примеры использования. Погуглил и ничего разумного не нашёл, только типа "There are many place names in England with the suffix “-thorp” or “-thorpe”. Ну так это суффикс, т.е. очевидная часть названия типа Дюссельдорф - “деревня на берегу реки Дюссель”.
Чисто для просвещения.
Сорри, подробностей я и сам особо не знаю 
Это действительно дико.
На чем еще прикажете основывать поиск, если не на name? (ведь name “занято” рендером).
name - собственное имя объекта - отражение объективной реальности, а не костыль, имеющий ограниченное применение.
Хотя, видел, существуют люди, которые пишут name=магазин - именно для того, чтобы слово “магазин” появилось на кате.
Отнюдь.
“Не рисуйте под рендер” подразумевает, что OSM - универсальная база, отражающая объективную реальность, а не заточенная именно под функцию рисования карт.
Т.е. что создание изображения карты - лишь “одна из”, но не единственная и не главная задача OSM.
А, следовательно, и тег name должен быть одинаково пригоден для любых геоинформационных задач, а не только для создания изображения карты (для рендера).
Это очень важный момент. Люди, имеющие представление об ОСМ по мапнику, зачастую даже и не задумываются о том, что список задач, для которых возможно применение ОСМ гораздо шире. А зря.
На мой взгляд, города (и только города из категории place) должны писаться без статусной части.
Все оствльное - со статусной, причем сама статусная часть в обязательном порядке должна быть в отдельном теге - для того, чтобы при необходимости отрезать статусную часть было бы точно известно, какие именно буковки следует искать и вырезать.
Чтобы не было неопределенностей, какова статусная часть у “станица Красное Село” или “улица Северная Набережная”.
Естественно, речь о собственном имени объекта. Но форма этого собственного имени бывает далеко не единственная, и сейчас речь о выборе этой формы.
Если интересна матчасть, погугли на тему “нормализация наименований”
Вот именно.
Поэтому, во избежание недоразумений, для фамилии имени и отчества обычно отволятся три разные поля. А уж как обращаться к нему в данной конкретной ситуации: “Петя”, “Петр Сергеевич” или “гражданин Кольцов” это уже зависит от множества факторов.
Главное - чтобы не приходилось обращаться “эй ты”.
Взглянул на всякий случай на то, как оформляет генштаб, а у них, как известно, кр. сест. тал. Статусные части «город» и «деревня» опускаются практически всегда, по крайней мере в их обычным месте, т. е. в начале названия. Отличить д. от г. можно по шрифту. Посёлок сокращается до одной буквы п. Достаточно простая и нехламная схема. Смотрел только центральную часть, за всякие аулы не скажу. Поэтому, думаю, по крайней мере для большей части России прокатит город (town и выше) и деревню (village и ниже) можно опускать, всё остальное — писать, т. к. остаётся только малая часть — в основном собственно посёлки и разная экзотика. Чтобы не путать опущенное и неизвестное, можно со статусом заполнить full_name.
Это если ФИО ограничено одним государством, этносом, временем, ведомством. Как только появляются Джон Смит, Остап-Сулейман-Берта-Мария-Бендер-бей, Вася «LLLyxeṖ», Конъитиро Нисияма, и прочие, начинаются костыли и пляски с бубном.
И при чем здесь генштаб?
ОСМ - не заготовка для бумажной карты, а универсальная база данных.
Поэтому информация в ней должна содержаться в виде, не зависящем от особенностей отображения карт.
Но при этом в машинно читаемом.
Т.е. вид представления, помимо прочего, должен допускать алгоритмически безошибочное пропускание статусных частей для городов и деревень (с возможностью отделения одних от других - для задания типа шрифта), а также усечения статусной части поселков до “п.”.
Но это совершенно не значит, что именно в таком усеченном виде информация и должна храниться в базе.
Она просто должна быть в таком виде, из которого рендер может сделать “генштабовский”.
Одновременно она должна обеспечивать возможность безошибочной сортировки и поиска как по собственной части имени, так и по статусной.
Это не менее важно (а, как правило, - более), чем “приличный” вид карты. Все-таки плохочитаемая карта - это частичная потеря функциональности, а сбой при поиске - полный отказ.
Начинаются.
Но практика показывает, что ограничение длины полного имени тремя составляющими - разумный компромисс.
И не нужно пытаться впихнуть все это в одно имя.
В общем, логика приводит к тому, что индивидуальная и статусная часть должны храниться в разных полях, причем, по факту, желательно, чтобы имелось также указание на то, в каком месте должна размещаться статусная часть.
Комбинация из полного имени со статусом и отдельно статусной части таким требованиям удовлетворяет.
Как пример компромисса. С теоретической точки зрения вообще не важно, какие форматы хранения используются, если есть однозначные правила получения всех необходимых данных. Вплоть до алгоритмов расшивровки всех этих п., М., Б… На практике желательно использовать способ, предоставляющий минимум геморроя. Раз осмщество видит проблему в обилии слов деревня, вот компромиссное решение с однозначными правилами трактовки и вроде без новых сущностей.
Только решение должно быть простым и понятным для иностранцев. Не только не для себя карту делаем
Вот именно.
При этом если первая часть - обязательное условие, то вторая - лишь скромное пожелание.
Собственно, Ваше предложение противоречит Вами же сформулированным требованиям - простоты и очевидности.
Гораздо проще и очевиднее - хранить все статусы, а не дифференцировать сначала по признаку город/деревня vs все остальное, а потом еще и по город vs деревня.
Требование на самом деле одно, и оно выполняется: наличие однозначной схемы. Остальное — пожелание, фитнес-функция, говоря языком математики.
А, возможно я не пояснил: здесь я писал конкретно про тег name. В остальных тегах хоть канкан пляшите 
Попробую зайти с точки зрения иностранца. Даже скорее инопланетянина. Я ожидаю, что основной тег name будет выполнять главную задачу, для которой сами названия и придуманы: однозначно идентифицировать объект (по крайней мере на заданном уровне адресной иерархии и типа объекта). Так что раз объекты могут различаться только именем или только статусом, то и то и другое должно так или иначе в это теге присутствовать. На самом деле мне, как иноплатенину не важно, что там, имя и статус, или прозвище и фамилия, но разные объекты должны иметь разные name.
Будет ли при этом статус фигурировать полностью, в сокращённом виде или закодирован иначе, вооружившись бумажкой с кодом я смогу найти нужный объект.
И полное написание статуса, и сокращение (вплоть до полного выкидывания в качестве одного из кодов) выполняют поставленную задачу. А вот факультативное употребление (как предлагали выше) — нет.
Полное указание статуса всегда и везде. Решение идеальное с точки зрения единообразия. Проблема в природной лени, которая не даст обозвать все деревни и и отфильтровать до желаемого уровня компактности при отрисовке. Поэтому и предлагаю компромиссы.
Короче, что бы ни было предложено, каждый раз находятся ярые противники.
Давайте уже каждый заинтересованный напишет конкретную схему обозначения наименований всех объектов типа place, с форматом тега name и прочих, если используются. Будем сравнивать конкретные предложения.
Идеал единообразия != Идеал юзабилити
Хранить полное наименование в official_name (можно и статус продублировать в official_status), но оставить человекопонятный name, в котором статусная часть будет в минимально необходимых случаях, как предлагал esaulenka.
Сразу вопрос: а может ли кто написать (допилить существующий) валидатор, который будет показывать полные совпадения в name для разных населённых пунктов в некой окрестности (1,3,5,10 км)? Такая функция позволила бы оперативно назначать статусы там, где это надо, да и вообще масштаб проблемы.
Думаю, уже здесь содержится ошибка.
Иванов Иван Иванович - полное имя (даже не рассматриваем “неполные” типа Ваня или Иванов), тем не менее, это не гарантирует единственности Иванова не только во Вселенной, но даже в отдельно взятой квартире.
Т.е. сама посылка неверная.
Наверное, в данном случае можно добиться уникальности единственным способом: добавить к полному имени полный же адрес, а также год (а на всякий случай и дату) рождения.
Но такой подход явно соприкасается с очевидной крайностью - задавать все свойства объекта в теге name, полностью игнорируя все остальные теги.
По всей видимости, надежную идентификацию все-таки следует предусмотреть не для отдельного тега, а для всей совокупности тегов в целом.
С этим трудно не согласиться.
Вполне логично.
При условии, что это не будет сопровождаться дополнительным условием - помещать статус именно в поле name.
Вполне логичным представляется вариант, при котором в теге name указание статуса будет именно факультативным при обязательном наличии дополнительного тега со статусом.
Логично.
Мое предложение:
- в name н/п использовать название, как правило, без статусной части. Допускается исключение, когда статусная часть по тем или иным причинам желательна,
- использовать отдельное (факультативное) поле для статуса. Если в name указан статус, наличие этого поля становится обязательным (чтобы знать, что именно при необходимости следует вырезать из name).
- в случае неоднозначности (как правило, наличие одноименных н/п в регионе) статус становится обязательным для указания (в обоих полях).
Мне кажется, такое предложение:
- обеспечивает уникальность и однозначность идентификации объекта (а при наличии дополнительных справочноков: ФИАС, КЛАДР, ОКТМО, ОКАТО, следовательно, и статус),
- не требует внесения существенных изменений в существующую базу (внесение статуса одновременно в поле name и дополнительное поле только при обнаружении неоднозначности).