Написание типа объекта в name

LLlypuk82 не любит мои отсылки к англоязычной Вики, но тут даже русскоязычная Вики со мной солидарна:

“Как правило, сущность обозначаемого объекта достаточно хорошо можно передать тегами. Однако, если уточняющих тегов недостаточно, все равно не следует помещать уточняющее описание в name=. Так, не существует подробной классификации видов бань, и баня обозначается тегом amenity=sauna, но чтобы обозначить именно русскую баню, можно написать “русская баня” в значение тега description=. В name=* может попасть только название, например name=Шайка и лейка. Помните, что устройства и программы навигации сортируют объекты по типам на основании присвоенных тегов, а по содержимому name=* они осуществляют текстовый поиск и показ именованных объектов в списках. Засорение тегов имени ведет к засорению списков и поиска.” (https://wiki.openstreetmap.org/wiki/RU:Key:name).

Вот, что такое сущность объекта, и что такое название объекта?
Имеет ли право в названии быть слово, похожее на описание сущности, но обозначающее что-то другое?

сущность lake — водоем природного происхождения.
слово в названии “озеро” — обиходная привычка (традиция) разные по сути водоемы называть этим словом.

Не люблю талмудизм и упрямое буквоедство (выискивание каки-то «удобных фраз и формулировок» с целью кого-то уесть и что-то доказать, ничуть не заботясь о результате и цели этой деятельности). Слова «озеро, водохранилище» — часть названия (причём, имеется даже специальный термин — «статусная часть», «родовое слово»). Они логически и практически неотделимы от названия, как такового, состоящего из имени собственного и статусной части. То же самое касается улиц, проспектов, бульваров и т. д.
Ещё раз (в который уже?): какая реальная практическая цель такого «улучшательства» базы данных, выражающаяся в кастрации этих самых данных? (по действительному результату, отражаещемуся в конкретных приложениях, а не теоретическому «желаемо (кому-то) красивому и сферически упорядоченному»)

Цитата из русскоязычной Вики как раз о том, что независимо от характеристик объекта (природный, рукотворный или природный и впоследствии преобразованный человеком) – в name предполагается вносить только имена собственные, т.е. то, что в русском языке пишется с заглавной буквы, для всего остального или есть отдельные тэги, или – если их нет – информация отправляется в description (как с “русской баней” в примере выше). По рукотворным водоемам – pond/reservoir, даже если принято называть “озеро”. Именно по Лепельскому озеру я за water=reservoir, т.к. тот объект, что мы наблюдаем сейчас на местности и на спутниковом снимке был создан искусственно, что там было до того – это в прошлом, и характеристики этого объекта в прошлом на данный момент подтвердить на местности нельзя)

То же самое можно сказать про реки, НП, ЖД станции – “статусная часть неотделима от имени собственного”. Сейчас с реками, НП и станциями есть единообразный подход, когда name содержит только имя собственное. Хочется таких же четких правил/подходов к заполнению тэгов для озер и СТ – эти объекты ничем не особенные, чтобы для них придумывать иные правила, чем к рекам и НП. А все правила что мне удалось пока найти на Вики (поверьте, ищу не для того чтобы кого-то “уесть”, а чтобы выяснить, как задумывался тэг name), предлагают такой подход: в name – только имя собственное (rule of thumb для русскоязычных названий: в name – то, что пишется с заглавной буквы).

Согласен, без консенсуса участников менять все тэги в один момент только ради упорядочения данных это неправильно (что я непредусмотрительно сделал для СТ и что вы впоследствии успешно откатили).

Консенсус простой: не только хранение, но и передача информации (её использование).

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

Спасибо, но тут, как говорится, “уж лучше вы к нам”:wink: Тем более, что мой взгляд на эту проблему совпадает с тем, что отражен на англо- и русскоязычных страницах Вики, что, в свою очередь, отражает конвенцию довольно большого числа участников OSM (хотя, как показывает эта ветка и обсуждение на Телеграмме, не всех) и задает “хороший стиль” (еще одна ссылка на рекоммендацию Don’t use name tag to describe thingshttps://wiki.openstreetmap.org/wiki/Good_practice)).

Все просто, по ним есть отдельное соглашение.

Отлично, я за то, чтобы в это же соглашение дописать через запятую “реки, озера”, “населенные пункты, садоводческие товарищества, дачные кооперативы”. Еще раз: чем СТ так отличаются от НП, а озера – от рек, что для СТ и озер нужно отдельное/иное соглашение?

LLlypuk82 задаст резонный вопрос – а почему не применить соглашение для названий улиц к СТ и озерам? Мой ответ – потому, что характеристики СТ ближе к характеристикам НП, а характеристики озер – к рекам, чем к характеристикам улиц/дорог.

Сто лет были лишь бумажные карты, где все, что не отрисовано – потеряно для пользователя, поэтому чтобы карта имела большую информативность, в ней были всевозможные аббривиатуры (оз./р./ст./г.п./х.). У базы данных способ хранения информации иной, так зачем к базе данных применять логику бумажных карт?

Почему в некоторых странах используют при заполнении тега name несколько языков? (дублируя на них названия). Это же «недопустимо»: есть языковые префиксы name:[language]! Нарушена «читоста» базы данных! Да ровно потому, что это на сегодня самый простой работающий вариант решения проблемы стран с населением, говорящим на разных языках.
Как только будет осуществлён работающий широкодоступный вариант с выводом мультиязычных подписей и/или с возможностью их переключения «на лету» — тут можно начать говорить о переходе к такому подходу при обработке исходных данных в других приложениях и постепенному отказу от старого доброго костыля. Постепенному — потому что далеко не все (и даже не многие) приложения могут быть мгновенно переработаны под данную концепцию. Это — не освоить синтаксис запросов overpass turbo и одним махом раскидать полезную информацию «по полочкам» в угоду «чистоте и порядку» в БД (и по факту удалить её из практического использования), а «немножко» посложнее. Поэтому переход на прогрессивные методы хранения, обработки и вывода информации, если и будет осуществляться (в принципе, это происходит в тех же «навигаторах»), то очень постепенно, с максимально долгой поддержкой множества «старых» приложений (некоторые из которых никогда по разным причинам не перейдут на новые рельсы, несмотря на свою полезность и востребованность, разве что когда-то появятся их более продвинутые аналоги).
Всё вышесказанное касается не только проблемы мультиязычности, надеюсь, это было и так понятно. Пример взят для наглядности.

Я не обязан быть в курсе, какие “костыли” в каких рендерах/приложениях работают. Мое дело наполнять базу в соответствии со стандартами, стандарты – см. ссылки выше, включая good practice – я ищу на Вики. Пусть разработчики рендеров и приложений подстраиваются под структуру базы.

Я бы попробовал запилить пропозал под новый тэг исключительно для имени собственного без всяких статусный частей и прочей полезной информации, что-то вроде proper_name, но вот беда, такой тэг уже есть и это – name…

И, да, о чем тут речь про “работает-не работает”, “костыли” и т.д. если самые важные для приложений/рендеров объекты – НП – уже давно подписаны согласно правилу “name=имя собственное”, а статусные части отправлены в name:prefix; то, что осталось – озера и СТ это какие-то мелочи. Не уверен, что кто-то кроме вас, LLlypuk82, вообще заметит приведение их названий к стандарту.

Yury Yatsynovich

Продолжаете забивать гвоздики в крышечку? Конечно, вам же главное что бы где то что то в базе кошерно было, ничего другого не принимается. А обычным людям, которые еще пытаются использовать обычные карты на основе OSM, которые имеются сейчас, до фени ваша база, теги, пропозалы… Они видят то что видят - и если их не устраивает результат - они сваливают на другие сервисы - вот все чего Вы добьётесь. И назад они не вернутся никогда, ибо в воспоминаниях останется только негативный опыт использования карт OSM… Так что вперёд к светлому будущему - красивой базе, которой никто пользоваться не будет :slight_smile:

У меня есть ощущение, что Yury Yatsynovich по какой-то причине сильно обиделся на OSM и теперь всеми силами пытается нагадить, т. е. изговнить так, чтобы он стал как можно менее интересен для реального применения.
В то же время другие (не столь открытые) проекты развиваются и постепенно замещают все ниши применения OSM.

Если не нравится как работают программы с данными, то есть два способы повлиять на разработчиков:

  • писать им, чтобы они начали работать с данными по новому,
  • менять данные так, чтобы программы уже не смогли бы работать по старому, тогда разработчики зачешутся.
    Первый путь долог, и результата ждать долго, для второго всегда под рукой есть редактор данных.

З.Ы. Есть и третий путь: написать программу самому, показав всем пример правильной программы.

Сказано же: «пример взят для наглядности». Пример — мультиязыные подписи (прямо в name на разных языках, если не понятно) при наличии соответствующих каждому отдельному языку названий (в отдельных тегах).

Они по факту удалены из приложений (максимум ими могут пользоваться редакторы-люди, валидаторы), ни один человек-обычный пользователь конечного продукта не узнает, что вот это — посёлок городского типа, это — деревня, а это — агрогородок. Это и означает «не работает».

Есть и четвёртый: делать прямо сейчас то, что работает, с помощью тех средств, которые уже есть.
Появятся другие (более продвинутые, эффективные) инструменты/алгоритмы/приложения — да кто против? И даже при таком условии важно помнить, что необходима поддержка старых приложений на определённый период (это надо вообще объяснять? это обычная и логичная практика). А пока всего этого нет — о чём тут разговоры водить?
Пока я вижу одного отдельно взятого «энтузиаста», который топит за вырезание информации или представление её в непригодном виде. И он почему-то решил, что всех этим осчастливит.
Такие же энтузиасты принимались переименовывать всё на белорусский язык. И где они? Прыти много, когда «своё ИМХО» пихаешь куда ни попадя, не думая (и тоже куча «документальных» подтверждений, и truth on the ground).

Чтобы не голословно, пример: внедряется широкая поддержка отношений для водных потоков, дорог (возьмём линейные объекты) — замечательно, приступаем к удалению дублей name на тысячах отрезков этих линий, а также других общих тегов типа википедии и т. п.
Пока нет этого — не делаем резких движений (без учёта последствий).

Yury Yatsynovich, прекращаем риторику «смотрите: вот тут и тут порезали и никто же особо не пострадал (вроде бы, пока что), так давайте продолжать, чтобы уж наверняка». Это деструктивная, гнилая риторика.

Александр, ваши “ощущения” о моих мотивах ничего общего с реальностью не имеют. А ваше менение – то, что вы изволили выразить словами “нагадить” и “изговнить” – не является критерием оценки моего вклада в проект. По итогу, при заполнении тэгов я следую руководствам из Вики и описанию того, что является хорошим стилем (см. приведенные мною ссылки выше), а вы – исключительно вашему субъективному мнению (ни одной ссылки вами приведено не было).

Когда Вики для name будет рекоммендовать что-то вроде “в тэге name указывается не только имя собственное, но и неотделимая статусная часть”, я приму эти новые стандарты, пока же предпочту придерживаться существующих – “в тэге name указывается только имя собственное (то, что в русском языке пишется с заглавной буквы)”.

На сим со своей стороны я закончу дискуссию.

Совершенно верно, поскольку пока ещё подобный «вклад» не осуществлён (точнее, был вовремя пресечён и откачен).
P. S. Мне неинтересны ваши намерения, для меня важны цель и результат неких действий. А поскольку они, порой, носят деструктивный и массовый характер, то будут пресекаться всеми доступными методами (как минимум, с моей стороны).