То же самое можно сказать про реки, НП, ЖД станции – “статусная часть неотделима от имени собственного”. Сейчас с реками, НП и станциями есть единообразный подход, когда name содержит только имя собственное. Хочется таких же четких правил/подходов к заполнению тэгов для озер и СТ – эти объекты ничем не особенные, чтобы для них придумывать иные правила, чем к рекам и НП. А все правила что мне удалось пока найти на Вики (поверьте, ищу не для того чтобы кого-то “уесть”, а чтобы выяснить, как задумывался тэг name), предлагают такой подход: в name – только имя собственное (rule of thumb для русскоязычных названий: в name – то, что пишется с заглавной буквы).
Согласен, без консенсуса участников менять все тэги в один момент только ради упорядочения данных это неправильно (что я непредусмотрительно сделал для СТ и что вы впоследствии успешно откатили).
Консенсус простой: не только хранение, но и передача информации (её использование).
Так это хорошо, что информация по данным объектам неполная в итоге? Почему не опираетесь на пример с улицами? (где информация сохранена и применяется успешно, без всяких изысков и ухищрений). Это сто лет работает и никому не мешает (а наоборот).
Желаете единообразия? Продвигайте статусную часть и для остальных объектов. Поддержу.
Спасибо, но тут, как говорится, “уж лучше вы к нам” Тем более, что мой взгляд на эту проблему совпадает с тем, что отражен на англо- и русскоязычных страницах Вики, что, в свою очередь, отражает конвенцию довольно большого числа участников OSM (хотя, как показывает эта ветка и обсуждение на Телеграмме, не всех) и задает “хороший стиль” (еще одна ссылка на рекоммендацию Don’t use name tag to describe things – https://wiki.openstreetmap.org/wiki/Good_practice)).
Отлично, я за то, чтобы в это же соглашение дописать через запятую “реки, озера”, “населенные пункты, садоводческие товарищества, дачные кооперативы”. Еще раз: чем СТ так отличаются от НП, а озера – от рек, что для СТ и озер нужно отдельное/иное соглашение?
LLlypuk82 задаст резонный вопрос – а почему не применить соглашение для названий улиц к СТ и озерам? Мой ответ – потому, что характеристики СТ ближе к характеристикам НП, а характеристики озер – к рекам, чем к характеристикам улиц/дорог.
Сто лет были лишь бумажные карты, где все, что не отрисовано – потеряно для пользователя, поэтому чтобы карта имела большую информативность, в ней были всевозможные аббривиатуры (оз./р./ст./г.п./х.). У базы данных способ хранения информации иной, так зачем к базе данных применять логику бумажных карт?
Почему в некоторых странах используют при заполнении тега name несколько языков? (дублируя на них названия). Это же «недопустимо»: есть языковые префиксы name:[language]! Нарушена «читоста» базы данных! Да ровно потому, что это на сегодня самый простой работающий вариант решения проблемы стран с населением, говорящим на разных языках.
Как только будет осуществлён работающий широкодоступный вариант с выводом мультиязычных подписей и/или с возможностью их переключения «на лету» — тут можно начать говорить о переходе к такому подходу при обработке исходных данных в других приложениях и постепенному отказу от старого доброго костыля. Постепенному — потому что далеко не все (и даже не многие) приложения могут быть мгновенно переработаны под данную концепцию. Это — не освоить синтаксис запросов overpass turbo и одним махом раскидать полезную информацию «по полочкам» в угоду «чистоте и порядку» в БД (и по факту удалить её из практического использования), а «немножко» посложнее. Поэтому переход на прогрессивные методы хранения, обработки и вывода информации, если и будет осуществляться (в принципе, это происходит в тех же «навигаторах»), то очень постепенно, с максимально долгой поддержкой множества «старых» приложений (некоторые из которых никогда по разным причинам не перейдут на новые рельсы, несмотря на свою полезность и востребованность, разве что когда-то появятся их более продвинутые аналоги).
Всё вышесказанное касается не только проблемы мультиязычности, надеюсь, это было и так понятно. Пример взят для наглядности.
Я не обязан быть в курсе, какие “костыли” в каких рендерах/приложениях работают. Мое дело наполнять базу в соответствии со стандартами, стандарты – см. ссылки выше, включая good practice – я ищу на Вики. Пусть разработчики рендеров и приложений подстраиваются под структуру базы.
Я бы попробовал запилить пропозал под новый тэг исключительно для имени собственного без всяких статусный частей и прочей полезной информации, что-то вроде proper_name, но вот беда, такой тэг уже есть и это – name…
И, да, о чем тут речь про “работает-не работает”, “костыли” и т.д. если самые важные для приложений/рендеров объекты – НП – уже давно подписаны согласно правилу “name=имя собственное”, а статусные части отправлены в name:prefix; то, что осталось – озера и СТ это какие-то мелочи. Не уверен, что кто-то кроме вас, LLlypuk82, вообще заметит приведение их названий к стандарту.
Продолжаете забивать гвоздики в крышечку? Конечно, вам же главное что бы где то что то в базе кошерно было, ничего другого не принимается. А обычным людям, которые еще пытаются использовать обычные карты на основе OSM, которые имеются сейчас, до фени ваша база, теги, пропозалы… Они видят то что видят - и если их не устраивает результат - они сваливают на другие сервисы - вот все чего Вы добьётесь. И назад они не вернутся никогда, ибо в воспоминаниях останется только негативный опыт использования карт OSM… Так что вперёд к светлому будущему - красивой базе, которой никто пользоваться не будет
У меня есть ощущение, что Yury Yatsynovich по какой-то причине сильно обиделся на OSM и теперь всеми силами пытается нагадить, т. е. изговнить так, чтобы он стал как можно менее интересен для реального применения.
В то же время другие (не столь открытые) проекты развиваются и постепенно замещают все ниши применения OSM.
Если не нравится как работают программы с данными, то есть два способы повлиять на разработчиков:
писать им, чтобы они начали работать с данными по новому,
менять данные так, чтобы программы уже не смогли бы работать по старому, тогда разработчики зачешутся.
Первый путь долог, и результата ждать долго, для второго всегда под рукой есть редактор данных.
З.Ы. Есть и третий путь: написать программу самому, показав всем пример правильной программы.
Сказано же: «пример взят для наглядности». Пример — мультиязыные подписи (прямо в name на разных языках, если не понятно) при наличии соответствующих каждому отдельному языку названий (в отдельных тегах).
Они по факту удалены из приложений (максимум ими могут пользоваться редакторы-люди, валидаторы), ни один человек-обычный пользователь конечного продукта не узнает, что вот это — посёлок городского типа, это — деревня, а это — агрогородок. Это и означает «не работает».
Есть и четвёртый: делать прямо сейчас то, что работает, с помощью тех средств, которые уже есть.
Появятся другие (более продвинутые, эффективные) инструменты/алгоритмы/приложения — да кто против? И даже при таком условии важно помнить, что необходима поддержка старых приложений на определённый период (это надо вообще объяснять? это обычная и логичная практика). А пока всего этого нет — о чём тут разговоры водить?
Пока я вижу одного отдельно взятого «энтузиаста», который топит за вырезание информации или представление её в непригодном виде. И он почему-то решил, что всех этим осчастливит.
Такие же энтузиасты принимались переименовывать всё на белорусский язык. И где они? Прыти много, когда «своё ИМХО» пихаешь куда ни попадя, не думая (и тоже куча «документальных» подтверждений, и truth on the ground).
Чтобы не голословно, пример: внедряется широкая поддержка отношений для водных потоков, дорог (возьмём линейные объекты) — замечательно, приступаем к удалению дублей name на тысячах отрезков этих линий, а также других общих тегов типа википедии и т. п.
Пока нет этого — не делаем резких движений (без учёта последствий).
Yury Yatsynovich, прекращаем риторику «смотрите: вот тут и тут порезали и никто же особо не пострадал (вроде бы, пока что), так давайте продолжать, чтобы уж наверняка». Это деструктивная, гнилая риторика.
Александр, ваши “ощущения” о моих мотивах ничего общего с реальностью не имеют. А ваше менение – то, что вы изволили выразить словами “нагадить” и “изговнить” – не является критерием оценки моего вклада в проект. По итогу, при заполнении тэгов я следую руководствам из Вики и описанию того, что является хорошим стилем (см. приведенные мною ссылки выше), а вы – исключительно вашему субъективному мнению (ни одной ссылки вами приведено не было).
Когда Вики для name будет рекоммендовать что-то вроде “в тэге name указывается не только имя собственное, но и неотделимая статусная часть”, я приму эти новые стандарты, пока же предпочту придерживаться существующих – “в тэге name указывается только имя собственное (то, что в русском языке пишется с заглавной буквы)”.
Совершенно верно, поскольку пока ещё подобный «вклад» не осуществлён (точнее, был вовремя пресечён и откачен).
P. S. Мне неинтересны ваши намерения, для меня важны цель и результат неких действий. А поскольку они, порой, носят деструктивный и массовый характер, то будут пресекаться всеми доступными методами (как минимум, с моей стороны).
Ох, Pavelfantik, не поминайте этот чейнджсет к ночи:)
Кстати, где-то на форуме для РФ было, что “садоводческое товарищество/дачный кооператив” это по сути форма юридического лица, которая управляет данным земельным участком, а не тип населенного пункта. Мы же не пишем ОАО “Приорбанк” или ООО “Макдональдс” в name, зато эти сокращения (а еще лучше – их полные расшифровки) вполне уместны в official_name или в operator.