add name:ru to all objects in Russia dump that have 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
устраивают, боюсь, ты в меньшинстве.

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

Мы вообще-то про то, следует ли писать name:ru. А механизм — он.
Если писать в name:ru название по-русски (или на другом официальном), то в name можно ввести русское, местноязычное, двуязычное название, и всё это будет работать. Если name:ru не писать, это обяжет писать name только на русском языке, то есть альтернатив нет.

+100500

Без разбору копировать name в name:ru - абсолютно бесцельно.

И это правильно.
Причин несколько:

  1. Русский - единственный государственный язык, действующий на всей территории РФ.
  2. Русский - один из 6 мировых языков.
  3. Русский - 4-й по распространенности язык мира.
  4. Просто из любых соображений - единые правила наполнения тегов гораздо лучше, чем отсутствие всяких правил.
    В любом случае один из name и name:ru на территории РФ явно лишний. Если употреблять name:ru, тег name оказывается совершенно ненужным.
    Кстати, существующая практика употребленя name:?? на территории РФ как раз с этим согласуется (если не считать отдельных названий, набранных латиницей). Например, вот что можно обнаружить : (список далеко не исчерпывающий)
  18      2    22744588 "alt_name:vi"
  20      2   311999396 "name:chm"
  21      3    39300272 "name:cs"
  22     18      421012 "name:de"
  23      1    27503927 "name:el"
  24   1381      421012 "name:en"
  25      3   311999397 "name:eo"
  26      2    39300272 "name:es"
  27      2   658312593 "name:eu"
  28      1    27503927 "name:fa"
  29      2       60189 "name:fi"
  30      4      184217 "name:fr"
  31      1    27503927 "name:he"
  32      2   191892583 "name:hr"
  33      2    39300272 "name:hu"
  34      1    27503927 "name:is"
  35      1    27503927 "name:it"
  36      1    27503927 "name:lv"
  37      1    27503927 "name:nl"
  38      1    27503927 "name:no"
  39      5    53888268 "name:pl"
  40      4       60189 "name:sk"
  41      4       60189 "name:sl"
  42      2       60189 "name:sv"
  43      1    27503927 "name:udm"
  44      5       60189 "name:vi"