add name:ru to all objects in Russia dump that have name:en

А может не надо его воспроизводить и достаточно починить испорченное?

Ну например рекомендуемый конфиг к mkgmap говорит, что в гармин попадает название в порядке приоритетности: name:ru, name:en, name. Очень полезно если делается карта сразу нескольких стран. Считается что пользователю родной язык русский, английский язык он знает, а остальные не знает. Если опустить из списка name:ru, то куча русских городов станут иметь английские названия. Если опустить из списка name:en, то карты неанглоязычных стран станут менее удобны.

А может не надо его воспроизводить и достаточно починить испорченное?

Не хочется в следующий раз давать тебе повод поязвить.

Чего-то я видимо не понимаю, но как это связано с выборкой русских наименований понять я не могу. Непонятно чем name:en такой особенный. Тогда уж name:* надо делать было.

Да и правка по дампу само по себе занятие очень стрёмное. Помимо драных релейшнов, есть вероятность принести в базу все косяки из дампа - а они там бывают, причем довольно незаметные.

Плюс дамп как оказалось не только России. Тоже смысла расставлять автоматом name:ru не вижу, для конвертирования в навигационные программы теги можно выставлять локально - у себя на компе

Согласен.

Может быть и в этом дело. Разбираюсь.

Ну вот и надо править конфиги mkgmap для приоритетности name:ru, name, name:en, а не генерировать стотыщпицот дублирующихся имен…
Либо, если через конфиги приоритеты не меняются - сделать препроцессор.

Да, проблема оказалась в дампе. Буду общаться с sim как избежать подобного в будущем.

ikz,

Ну вот и надо править конфиги mkgmap для приоритетности name:ru, name, name:en

Если так поправить конфиг, то будет совсем не то, что нужно.

Ну совсем обойтись может и не удастся, но свести его масштаб до единичных случаев вполне реально:

  1. Проверяем наличие в именах нерусских символов (все кроме пробела, кириллицы цифр и знаков пунктуации). Если есть, то объект не трогаем (можно заодно и произвести запись в отдельный лог).
  2. Проверяем попадание объекта на границу (и за границу), поступаем аналогично.
  3. Берем в качестве области не всю Россию, а только те ее части, в которых нет официальных языков, отличных от русского.

Увы, этот пример ничего не поясняет, а лишь иллюстрирует тот очевидный факт, что одна и та же вещь может иметь массу различных наименований.
При этом остаются открытыми два вопроса:

  1. Зачем всю эту массу наименований переносить на карту?
  2. Если уж 1 так необходимо, по каким именно критериям следует заполнять различные теги?

Да, пример прояснял не эти вопросы, а только вопрос “Для чего нужны разные теги?” :slight_smile:

  1. Разные теги надо заполнять по критериям смысла этих тегов.
  2. Рендереры и конвертеры могут выбирать теги по приоритетам, не обязательно тащить всю массу.

Это серьезное возражение.
Очень серьезное.
И, пожалуй, ЕДИНСТВЕННОЕ серьезное.
Вот только в НАШЕМ случае официальный язык как раз один. Так что, учитывая местные особенности, возражение неактуальное.

Строго говоря, ЛЮБОЙ механизм будет надежно работать лишь в случае, если он поддерживается ВСЕМИ БЕЗ ИСКЛЮЧЕНИЯ.
То есть приведена совершенно очевидная банальность, которая для тега nabe выполняется ровно с тем же успехом, что и name:ru или name:en или для любого другого.
Не аргумент это в данном случае ни разу.

Вот именно результат такого “простого” решения мы и наблюдаем.

Ну да, результат работы “стопроцентно программного алгоритма выбора” мы и имели счастье наблюдать непосредственно в работе.
И здесь совершенно очевидно, что:

  • либо такой безошибочный алгоритм существует. И пи этом никто не мешал реализовать его в программе, которая буде ОБРАБАТЫВАТЬ локальный OSM-файл, а не корежить данные в базе.
  • либо такого алгоритма нет и принципиально не может существовать, тогда просто НЕ СЛЕДОВАЛО пытаться корежить базу АЛГОРИТМОМ, а только и исключительно ручками.
    Т.о. на какой бы точке зрения мы не стояли, подобная АВТОМАТИЧЕСКАЯ правка абсолютно бессмысленна.

А проверить на локальной копии было не судьба?
Косяк из-за подхода. Из-за того, что кто-то попытался возложить на алгоритм работу, которую ПРИНЦИПИАЛЬНО на алгоритм возлагать бессмысленно.
Т.е. ошибка не тактическая, а стратегическая.

Неправда ваша.
Без него молжно обходиться ВСЕГДА, если работать исключительно со своей локальной копией.

Так може, его и надо было выставлять ручками, а не автоматом?

Вот именно это и называется тупым алгоритмом.
Прежде чем решать, который из name, name:ru или name:en выбрать, следует выяснить, а на каких, собственно, языках они приведены. Хотя бы для name, хотя для name:ru и name:en - тоже не помешало бы. В каком состоянии сейчас находится name:ru, мы видим и нет никаких гарантий, что подобное не будет повторяться регулярно по самым различным причинам.
Слава Богу, все названия приведены в UTF-8, в которой латинский, кириллический, иероглифический алфавиты, арабская вязь и т.п. занимают различные диапазоны кодов.
Поэтому простенький (но не тупой!) алгоритм выставления приоритетов должен выглядеть примерно так:

  1. Если name:ru на кириллице - выбираем его.
  2. Если name на кириллице - выбираем его.
  3. Если name:en на кириллице - выбираем его.
  4. Если name:en на латинице и не содержит “неосновных” символов - выбираем его.
  5. Если name на латинице - выбираем его.
  6. Если name:ru на латинице - выбираем его.

Кто бы сомневался!
Вопрос в другом: каков именно смысл каждого конкретного тега.
И вообще, есть ли он. В частности, для name:ru на территории России.

Ну наконец-то хоть кто-то кроме меня поставил под сомнение name:ru на территории РФ…
Смысл то в том, что в 99,9% случаев (0,1% на те самые пограничные, а не приграничные объекты) теги name и name:ru будут идентичны. А значит содержат заведомо избыточную информацию.

Ну да, уже на протяжении 8 постов в этой теме.

Есть механизмы многоальтернативные — они будут работать, если каждым поддерживается одна из альтернатив. Обсуждаемый — нет.

Меня результат вполне устраивает. Меня не беспокоят два совпадающих значения тега среди десятка.

Vovanium, зихер-то в том, что эта операция не одноразовая. Ее сейчас придется проделывать регулярно - поддерживать новые и измененные объекты. А на регулярной операции проблем вылезет куда больше. KekcuHa с кладром вручную валидировал каждую правку и то возникали проблемы.
Так стоило ли городить огород? IMHO решать задачу надо было с другой стороны.

Увы, я эту мысль не понял. “Каждый” - из какого множества? “Обсуждаемый” - что? Обсуждаем правку, а она - женского рода.

Ну если результаты правки:
http://www.openstreetmap.org/browse/way/60827637
http://www.openstreetmap.org/browse/relation/538607
устраивают, боюсь, ты в меньшинстве.

Вот именно!
Править ТАКИМ ОБРАЗОМ и С ТАКОЙ ЦЕЛЬЮ в самой базе - абсолютно нелогично.
Хочешь править в базе, в ДАННОМ СЛУЧАЕ - правь ручками.
Хочешь АВТОМАТИЗИРОВАННУЮ правку - правь у себя в локальной копии.