+100500. OSM это общедоступная база геопространственных данных и теги должны выбраться в соответствии со спецификой объекта а не программы которая их обрабатывает. Грубо говоря код улицы в соответствии с каким-то утверждённым официальным реестром названий улиц - ОК, а вот код улицы для какого-то специфичного приложения - должен храниться в инфраструктуре этого приложения.
Продуманный верифицируемый тег для общего использование - работает. Что-то специфичное для какого-то приложения - нет, ибо может быть легко снесено по ошибке или же как невалидируемые данные.
Так что обсуждаемая проблема невелика. Нужно просто сесть и придти к консенсусу. В итоге в выигрыше будут все.
P.S. Языка с ISO кодом mcm не существует и такие теги должны автоматически выпиливаться.
А что делать если табличка на здании и указатель это разные надписи?
Официальное название на табличке на здании, на указатели так, как удобно людям чтобы ориентироваться (в том числе так, как удобно пользователям считывать эту информацию на карте).
Для первого official_name, для второго — name. Есть проблема, что удобство того или иного варианта субъективно. Поэтому в OSM есть договорённости по некоторым типам объектов.
Во-первых, ТС вообще ни о чём договариваться не пытается, а просто молча делает по-своему.
Во-вторых, по названиям улиц и школ договорённости уже есть и менять их причин не вижу. К счастью для ТС, договорились именно до тех вариантов, которые им и нужны. По непонятной причине, ТС проигнорировал этот факт и просто продублировал названия в свои теги.
В-третьих, как выше уже было объяснено, автоматические переводы на английский мы не храним в базе. В базе хранятся только устоявшиеся названия на других языках. Это нужно для того, чтобы при создании автоматических переводов, объекты с устоявшимися названиями не потеряли эти самые устоявшиеся названия.
Свою правку с удалением всех тегов я откатил. Даже если ни к чему не придём, удалить всегда успеем.
Думаю, для начала нужно избавится от дублирования, т. е. удалить теги alt_name:mcm* везде, где они совпадают по значению со стандартными тегами. После этого будет проще оценить масштабы и нюансы.
масштабы-то оценить просто, с помощью Оверпасса. Напрягает другое - что обратной связи никакой нет. Может, Дептрансу эти теги уже и не нужны, и они останутся лежать бесполезным грузом?
также А. Мильчин, Л. Чельцова. Справочник издателя и автора. п. 6.4.2 (правда, там говорится об отбое знака номера от числа на полукегельную, но, вроде бы, “В традиционных шрифтах “полукегельная” – в точности то же, что ширина обычного пробела, если строка не сжата и не растянута.”
Мои 5 копеек: внутри базы планеты (ПБФ) все строковые литералы хранятся в отдельном пуле и референсятся из него при помощи айдишника. Можно создать сколько угодно дублей, но реально в базу будет добавлено всего 2 референса, ни то по 2 байта, ни то по 4, а потом это будет еще и дефлейтом пожато. Так что с точки зрения “чистоты базы”, снос дублей или переименование не несет роли.
Как насчет тегов вида alt_name:ru:government_approved?
Как насчет тегов вида alt_name:ru:vasya_pupkin_community_data?
В обоих случаях данные могут быть верифицируемы. В обоих случаях данные могут иметь значения, используемые во многих случаях и не зависеть от конкретного приложения.