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

Например,
http://www.openstreetmap.org/browse/way/25314189/
сейчас уже вернул из истории, но по рендерингу видно, что линия была обрезана

Вижу. Это баг osmosis или tagtransform. Не получается его воспроизвести на маленьких файлах, где только затронутые объекты. Попробую воспроизвести на всём дампе России.

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

Ну например рекомендуемый конфиг к 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 решать задачу надо было с другой стороны.