А чего не в full_name:*?
official_name- оф. название, тогда full_name - пусть будет название со всякими квалифицирующими словами типа памятник и т.п.
+100500. OSM это общедоступная база геопространственных данных и теги должны выбраться в соответствии со спецификой объекта а не программы которая их обрабатывает. Грубо говоря код улицы в соответствии с каким-то утверждённым официальным реестром названий улиц - ОК, а вот код улицы для какого-то специфичного приложения - должен храниться в инфраструктуре этого приложения.
Продуманный верифицируемый тег для общего использование - работает. Что-то специфичное для какого-то приложения - нет, ибо может быть легко снесено по ошибке или же как невалидируемые данные.
Так что обсуждаемая проблема невелика. Нужно просто сесть и придти к консенсусу. В итоге в выигрыше будут все.
P.S. Языка с ISO кодом mcm не существует и такие теги должны автоматически выпиливаться.
а если речь идёт про надпись на табличке, которая на этот объект указывает? (указатель, скажем)
А что делать если табличка на здании и указатель это разные надписи?
Официальное название на табличке на здании, на указатели так, как удобно людям чтобы ориентироваться (в том числе так, как удобно пользователям считывать эту информацию на карте).
Для первого official_name, для второго — name. Есть проблема, что удобство того или иного варианта субъективно. Поэтому в OSM есть договорённости по некоторым типам объектов.
собственно, об том ТС и предлагает договориться по некоторым типам объектов
Во-первых, ТС вообще ни о чём договариваться не пытается, а просто молча делает по-своему.
Во-вторых, по названиям улиц и школ договорённости уже есть и менять их причин не вижу. К счастью для ТС, договорились именно до тех вариантов, которые им и нужны. По непонятной причине, ТС проигнорировал этот факт и просто продублировал названия в свои теги.
В-третьих, как выше уже было объяснено, автоматические переводы на английский мы не храним в базе. В базе хранятся только устоявшиеся названия на других языках. Это нужно для того, чтобы при создании автоматических переводов, объекты с устоявшимися названиями не потеряли эти самые устоявшиеся названия.
Свою правку с удалением всех тегов я откатил. Даже если ни к чему не придём, удалить всегда успеем.
Думаю, для начала нужно избавится от дублирования, т. е. удалить теги alt_name:mcm* везде, где они совпадают по значению со стандартными тегами. После этого будет проще оценить масштабы и нюансы.
масштабы-то оценить просто, с помощью Оверпасса. Напрягает другое - что обратной связи никакой нет. Может, Дептрансу эти теги уже и не нужны, и они останутся лежать бесполезным грузом?
Здравствуйте. Извините, что я только сейчас прочитал эту фразу. Где можно прочитать про договорённость о названиях школ?
посмотрите на даты внесения тегов. три недели назад
По школам, наверное, в вики нету, но договорённость на форуме была. Пока нет единого мнения нужен ли пробел после символа «№». Думаю, надо искать в теме https://forum.openstreetmap.org/viewtopic.php?id=8645
по правилам русской типографики - нужен:
https://ru.wikipedia.org/wiki/%D0%97%D0%BD%D0%B0%D0%BA_%D0%BD%D0%BE%D0%BC%D0%B5%D1%80%D0%B0
http://esmira.net/uroki/tretij-urok.html
также А. Мильчин, Л. Чельцова. Справочник издателя и автора. п. 6.4.2 (правда, там говорится об отбое знака номера от числа на полукегельную, но, вроде бы, “В традиционных шрифтах “полукегельная” – в точности то же, что ширина обычного пробела, если строка не сжата и не растянута.”
Ещё и с точки зрения логики - символ № заменяет слово “номер”, которое пишется, разумеется, через пробел от самого номера. “номер 2” vs “№ 2”.
Плюс ко всему в случае длинного номера сливание в один затрудняет чтение - первым делом кажется, что знак № сам является частью идентификатора.
Вообще туда нужен неразрывный пробел, но проще его заменить отсутствием пробела.
Имена собственные нужно писать с заглавной буквы, но проще писать с маленькой
Мои 5 копеек: внутри базы планеты (ПБФ) все строковые литералы хранятся в отдельном пуле и референсятся из него при помощи айдишника. Можно создать сколько угодно дублей, но реально в базу будет добавлено всего 2 референса, ни то по 2 байта, ни то по 4, а потом это будет еще и дефлейтом пожато. Так что с точки зрения “чистоты базы”, снос дублей или переименование не несет роли.
Как насчет тегов вида alt_name:ru:government_approved?
Как насчет тегов вида alt_name:ru:vasya_pupkin_community_data?
В обоих случаях данные могут быть верифицируемы. В обоих случаях данные могут иметь значения, используемые во многих случаях и не зависеть от конкретного приложения.
kms:parish_name - достаточно популярный тег
Как и naptan:ShortCommonName