Для базы данных в идеальном случае все должно быть по полочкам. Например, “улица” тоже не должна фигурировать в названии, а быть в отдельном поле, чтобы каждый сам мог решить выводить ее в полной или сокращенной форме, или вообще не выводить.
Но рендеры под это дело никто править не будет, да и поддерживать несколько полей сложнее, а видеть их на карте хочется, вот и засунули их в название.
Та же самое происходит и с озерами - люди хотят увидеть на выходе категорию, а рендеры их не выводят, вот и пихают ее в название. Вот тут надо бы и определиться, надо оно нам в названии всех озер или стоит почистить, и если надо, то сокращенное или полное. Стоит еще отметить, что в отличие от улиц, которые могут быть и переулком и проспектом и т.п., для озер однозначный тег имеется.
если есть документированный/используемый тег, типа обьекта в названии быть не должно. Это нужно где то в ид/мапсми написать большими буквами, чтобы избежать "Магазин “Магазинный магазин” " с тегом shop впридачу.
разумеется, если выбор тега затруднителен для того, кто рисует, то можно добавить note или поставить сокращение как с СТ. в перспективе это все уберем, переведем всю карту на name:be и построим коммунизм
Подобные дилеммы всегда упираются в выбор между: формально так, по факту так, хотелось бы (удобнее/правильнее) так. Чтобы не надо было искать компромисс, «усреднённый» вариант — должна быть крепкая взаимная обратная связь между теми, кто данные вносит (тегирует) и теми, кто их обрабатывает (под навигаторы, рендереры и т. д.)
Этой связи нет или она очень слабая. Поэтому и получаем на практике, что ежели формально раскидать типы объектов по префиксам или предполагать извлечение их прямо из основного тега, подписывать объекты по ref и/или name (и тут есть разные подходы, что сюда вносить), то получим по факту обрубки. Да, это с точки зрения БД, формальной строгости, конечно, прекрасно. Но по указанной выше причине выглядеть результат будет кастрированно (однообразно и непонятно), т. е. неудобоваримо для практического применения.
Тут бы тем, кто рендерит, например, показать хороший образец рендеринга формальной схемы тегирования (связанной с подписями объектов) и рекомендовать её как эталон. Но они его не показывают, а лишь приноравливаются (каждый по-своему) к тому «разброду и шатанию», который имеется во всём многообразии: что-то урезают, что-то игнорят, что-то переставляют, что-то комбинируют, выкручиваются, в общем. Примерно то же самое делают тегировщики: подстраиваются под имеющиеся рендереры, навигационное ПО и т. д.
А по-хорошему (для меня) надо договариваться на двусторонней основе: вы нам покажите «как надо, чтобы…» и «вот как это будет красиво и замечательно в итоге». Но этого не происходит, а идёт нескончаемый «бой», «непримиримая борьба» тегировщиков между собой — с одной стороны, и попытки рендерщиков более-менее адекватно обработать и показать хороший результат — с другой стороны. Пока между сторонами не появится связки-моста — ситуация не поменяется.
‘natural’=‘water’, ‘water’=‘lake’ у name ня пішам возера, але пішам у prefix
‘natural’=‘water’, ‘water’=‘lake’ у name ня пішам возера і ня пішам у prefix
‘natural’=‘water’, ‘water’=‘lake’ у name пішам возера
‘natural’=‘water’, ‘water’=‘lake’ у name пішам воз.
Шчыра кажучы варыянт са скаротамі шмат чым хібны, таму што гэта ўсё ж скарот.
Цікава што па статыстыцы што скінуў вышэй зараз з азёрамі больш ужываецца воз./возера, а з рэкамі наадварот не ўжываецца р./рака, таму б я прапаноўваў варыянт 1 ці 2.
Іншае пытаньне што рабіць з азёрамі, вадасховашчамі і іншымі варыянтамі, ці ў гэтым выпадку яны ня будуць падпадаць пад ‘water’=‘lake’.
Беру свои слова обратно. Однозначного тега нету ни для озера ни для какого другого объекта. Все теги являются относительными, и не позволяют вывести на карту нужную категорию. Представим, что британец делает карту мира и хочет для названий озер вывести префикс категории. Что он будет выводить имея только название и тег ‘water’=‘lake’ ? - ничего, так как перевод всех категорий на все языки мира включая местные в ренедр не засунешь и даже если и засунешь, не будет уверенности, что получено правильное соответствие. Поэтому вариант 2 отпадает.
С этой же позиции вынесение значения в name:prefix потребует задавать его для всех языковых вариантов.
Это будет выглядеть примерно так:
name
name:prefix
name:ru
name:prefix:ru
name:be
name:prefix:be
name:uk
name:prefix:uk
и т.п.
Это сравнимо с вынесением “улица” в отдельный тег. Не поддерживаю.
А что? - база данных. А для чего? - для карты. На карте всегда места мало. Да и смысл выводить полное слово то? Даже если предположить, что кто-то не карту рисует, а оперирует данными для каких-то своих расчетов, какая ему будет разница делать выборку по “озеро” или “оз.”? На локальных картах мы привыкли и будем выводить сокращенный вариант, и это же будем ожидать от международных проектов, а сами они не догадаются, да и навряд ли будут такие костыли вставлять для нас. Короче в сокращенном варианте вижу только пользу.
в первую очередь для конверторов. То есть не для прямого потребления людьми. И это дело конверторов делать user friendly для своего продукта, причём для карт это может один способ, для навигатора другой, а для покемонов третий.
Если конвертору понадобится обработать этот префикс, то так или иначе ему придется парсить name, и следовательно разницы между “оз.” и “озеро” ему будет никакой.
Никакой международный проект не будет прописывать правила определения истинной категории объекта из названия и вводить словари для перевода этих категорий индивидуально для каждой страны с учетом местных предпочтений. Все будут выводить имя из тега name как есть, потому как местным людям виднее, как его лучше отобразить на карте (навигаторах и покемонах в том числе).
И правильно LLlypuk82 отметил, что если кого-то что-то не устраивает, пусть придет сюда и скажет об этом. А то мы сами себе сложности придумываем и играемся с ними.
Предполагаю, что name:prefix/postfix задумывалось как то, что должно выводиться на карту вместе с name. Но пользуется ли хоть один рендер этим полем?
И кстати, тут же вопрос, почему мы решили использовать это поле для официальной категории населенных пунктов? Не правильнее ли было бы использовать поле типа official_place, а в name:prefix ставить “п.”/“д.” там где на карте нужно отличить рядом находящиеся нп с одним названием?
Я за вариант 2. – ‘natural’=‘water’, ‘water’=‘lake’ у name ня пішам возера і ня пішам у prefix
Если конвертеру надо названия с префиксами, то пусть берет “lake”, переводит его в нужный язык и сокращает, как ему требуется.
Откуда нам знать, что конечный пользователь, скажем, карты на белорусском на месте “возера” пожелает именно “воз.”, а не “взр.” “вз.” или еще что-то? То же самое и с “СТ” – place=allotments+name=*, а тот, кто конвертит, пусть сам решает, как хочет он видеть префикс для allotments на карте – “СТ”, “сад.тов.”, “с.т.”, “с/т” или еще что-то.
“СТ” он несет значение категории, для которой нету тега. Это может быть и садовое товарищество, и садовой кооператив, и садово-огородническое товарищество, и дачный поселок. Префиксом “СТ” в данном случае обозначается только первое.
Ну тогда уж скорее есть смысл вводить выше указанный тэг official_place, чем писать все эти СТ, с.т. и прочую самодеятельность в имя. В общем, я за такой же подход к наименованию всех объектов, что и у населенных пунктов.
p.s. кстати, а в РБ есть такие вещи как “садовые кооперативы” и прочее? А то гугл по запросу “садовый кооператив Беларусь”, “Беларусь садово-огородническое товарищество” выдает только “садоводческое товарищество”…
На это можно возразить: нет проблем — пусть берёт общепринятые сокращения (оз. воз.) и делает с ними (в конвертере), что ему угодно: переставляет, удаляет, разворачивает в полное слово, заменяет своим словом и т. д.
Возразить то можно, но переход “lake”->“возера”->“взр.” требует лишь словаря и никакого знания общепринятых сокращений, а значит реализуется проще, чем “prefix” → расшифровка → перевод → новый префикс. А в ОСМ, оказывается, есть “общепринятые сокращения”? Во многих картах сокращения есть, но там они явно прописываются в легенде, а значит не являются такими уж “общепринятыми”.
И потом, почему нет такого же запроса на prefix для населенных пунктов, а только для рек\озер?