Поскольку смотреть на это дело будет иностранец, то и видеть ему будет удобнее передачу средствами именно его языка.
Но вы увели в сторону. Вопрос был не что хранить в name:en, а нахрена там хранить,
Есть еще МИДовская транслитерация
Существует два подхода к тому, чтобы доказать, что в name:en не надо класть что попало:
- определить четко, что там должно быть и сделать утверждение, что всё остальное, не подпадающее под это определение, там быть не должно;
- определить четко, что тот или иной коллега хочет туда положить, а потом установить факт, что это не является названием на английском языке.
Я пошел по второму пути, потому что у меня есть ощущения, что доказательство во втором случае окажется короче, так как желающие положить что-то в name:en будут просто не в состоянии справиться с тем, чтобы грамотно объяснить, что же они хотят туда положить (раз путаются в терминах), а значит, тут и разговаривать вообще не о чем - “непонятно что” в тегах хранить в любом случае нельзя.
Есть дохрена способов транслитерации. Но поскольку она делается всегда однозначно (когда способ выбран) хранить ее в базе не нужно.
это при условии, что есть движок в свободном доступе, который транслитерирует на латиницу все языки мира. И это хорошо, когда есть алфавит, а как быть с иероглифами?
Для них, вероятно, возможна только транскрипция. Кстати, а что по-хорошему должно быть в int_name?
Для большинства алфавитов (не иероглифических) задача сводится к применению одной единственной функции с таблицей замены (regex) или аналогичной процедуры SQL, которую может написать любой начинающий программист, пользуясь правилом “более длинные комбинации заменяются первыми”. Никакой особый “движок” для этого не нужен. Нужно некоторое время, чтобы написать по одному шаблону энное число таких функций для нужных исходных языков.
Однако, вы почему-то ограничиваетесь только романизацией https://en.wikipedia.org/wiki/Romanization , как частным случаем транслитерации. А как насчет тех, чей родной язык не использует латинский алфавит (китайцев, например)?
Кроме того, даже если предположить, что транслитерировать на стороне конвертера - действительно сложно (а пример того же стиля openstreetmap.de доказывает обратное), остаются вопросы:
- почему мы должны потакать сложностям с конвертацией в этом вопросе, когда не делаем этого в других (например, данные для Garmin должны быть порезаны, чтоб все не тормозило, но мы же их не режем)?
- какова практическая польза (use case) для транслитерации (даже в пределах одной только романизации)?
Сорвать в int-name транскрипцию ещё тот бред.
Изначально там должно быть название объекта, более известное в мире, чем в стране местонахождения.
Джомолунгма, Эверест
Церковь Покрова, St Basil Cathedral
Или что-то типа
Кампучия, Камбоджа
Suomi, Finland
Это такой специфический alt-name.
Там должно быть “международное название, не обязательно на английском языке”, что бы это ни значило.
Однако taginfo показывает забавную статистику: http://taginfo.openstreetmap.org/keys/int_name#values очевидно, что этот тег, главным образом, использовался разнообразными деятельными дураками из стран бывшего СССР, у которых чесалось “сделать хорошо для иностранцев”.
Очень туманно с этим делом. Русское название деревни «Красный Октябрь», каково будет международное?) Каков алгоритм их получения?
Алгоритм очень простой: деревня Красный Октябрь не имеет международной известности и сложившегося во всем мире (или в его большей части) способа называть его, так что у нее просто нет международного названия.
Проще говоря, если у вас возник вопрос о том, какое у чего-либо международное название (а вы не дремучий тип, живущий на хуторе без интернета, телевизора и книг), то его, скорее всего, нет.
Давайте пойдем от противного:
Běijīng - Пекин
Nha Trang - Ня Чанг
Xiānggǎng - Гонконг
Do Brasil (м.р.) - Бразилия (ж.р.)
Или тот же Кыргызстан - Киргизия
Представьте, если бы эти названия на русский переводили местные жители.
Мы все привыкли, что Красная площадь - это Red square, но при этом Большой театр не фига не Big theatre. А New York он и в Африке Нью-Йорк.
В общем, в виду непоняток, предлагаю отложить вопрос до лучших времен )))))
j-wills, вы привели образцовый набор name:ru перечисленных (в начале) объектов, хорошо иллюстрирующий, чем по отношению к названиям на территории России должны быть name:en.
Наткнулся на интересную картину. Если у кого-то возникает желание подсмотреть недостающие данные на чужих картах, вспомните вот это:
По-моему это классический двойной адрес.
10й Парковый пр., д. 21 = _ская улица, д. 6
Неа, цифра 6 и некоторые рядом вообще по логике ни к какой улице принадлежать не могут (конкретно для _ской - чётные с другой стороны), поставлены будто наобум.
Сколько раз я говорил, что карты для Яндекса рисуют наемные студенты-фрилансеры, а контроля качества там нет? Для Гугла (в России) это также справедливо.
У Гугла в этом месте стоИт “10 Парковый проспекты, 21”, что примерно совпадает с табличкой. А Яндекс, я так понимаю, поставил другой номер, чтобы никто не смог сказать, что он украл данные у Гугла.
Я бы поставил лайк здесь 
Я такое уже замечал за Я.картами в частном секторе (малоэтажной застройке). Там номера от балды взяты. Нет в России нормального сервиса с номерами частных домов и у ОСМ с этим пока лишь чуть лучше чем у коммерческих сервисов, увы.