Текущему mapнику никак не помешает наличие name:ru
Применяя логическое отрицание к данному утверждению получаем интересный вопрос: “Кому поможет наличие name:ru”? Другими словами кто-то вообще им пользуется?
Смотрю в сорцы osm2mp. name - есть, operator - есть, name:ru - нету. А ведь если бы в нем был толк, osm2mp использовал бы его в первых рядах.
Update:
Кто нибудь сможет поставить наконец-то задачу, которая бы решалась только обязательным наличием name:ru на всех объектах?
–namelist label=name:ru,name,…
Ну наверное чуть посложнее.
–namelist = comma-separated list of tags to select names; defaults:
country - addr:country, is_in:country_code, is_in:country
destination - destination, label, name
house - addr:housenumber, addr:housename
label - name, loc_name, operator
place - place_name, name
region - addr:region, is_in:region, addr:state, is_in:state
street - addr:street, name
И то, для это было бы необходимо, чтобы у тебя везде по умолчанию стояло name:en,name,…
Update:
Кста, glebius, как видно из Лешиного списка одного name:ru сильно недостаточно. Куча имен лежат совершенно в других тегах.
Ок. Я, видимо, невнимательно по сторонам смотрю… Только я так и не понял, что это доказывает кроме того, что в РФ многие кладут на закон?
Truth on the ground?
Не волнуйтесь, читал. Я сомневаюсь в том, что:
- возможно ввести в какой-то части сообщества отдельное правило про конкретный тег, используемый во всем мире.
- в России нет вывесок с названиями улиц не по-русски.
Повторюсь. Если не будет name, а будет name:*, что выбирать рендеру/конвертеру для вывода?
Повторюсь: выбор языка для отображения осуществляется в соответствии с установленной на компьютере локалью, если пользователь не выбрал иное.
Строго говоря, это справедливо именно для рендера. Конвертеру положено переносить ВСЕ языковые варианты для того, чтобы рендер имел возможность выбора.
Я сомневаюсь в том, что:
Увы, сомнения бывают двух типов: конструктивные и деструктивные.
Первые способствуют нахождению ПРАВИЛЬНОГО пути решения проблемы, а вторые - отказу от решения под предлогом невозможности.
О да! Отказ от правильных сомнений - это очень правильный способ нахождения правильного решения )
О да! Отказ от правильных сомнений - это очень правильный способ нахождения правильного решения )
Нужно чуть переставить слова:
Правильный отказ от сомнений - это очень правильный способ нахождения правильного решения
andriano, можно еще буквы начать переставлять и сочинять рифмы. Но лучше открыть редактор и нарисовать что-нибудь. Тогда, возможно, когда-нибудь число ваших правок превысит количество постов на форуме. Пока к сожалению на оборот. И да, конструктивными и деструктивными бывают предложения, а сомнения и предположения - верными и не верными, с одной стороны, а с другой имеющими и не имеющими отношение к проблеме. Тупо игнорировать истинные предположения - глупо.
По сути вопроса: я бы наверное предпочел вариант, когда для каждой строки, не только в name=*, в явном виде указывался язык и строка могла бы быть написана сразу на нескольких языках. Если я не ошибаюсь, то так сделано в 1С Предприятии, например. Ну а рендерам/конвертерам в лубом случае придется знать на какой список языков где использовать. Даже в мапнике на уровне postgresql это решить можно.
andriano, можно еще буквы начать переставлять и сочинять рифмы. Но лучше открыть редактор и нарисовать что-нибудь. Тогда, возможно, когда-нибудь число ваших правок превысит количество постов на форуме. Пока к сожалению на оборот.
Переходить на личности всегда считалось mauvais ton.
Что же касается ЛЮБЫХ данных, то всегда можно выделить три этапа:
- Создание.
- Хранение/передача.
- Использование.
Без первой, конечно, вторая и третья невозможны, но и без третьей первая и вторая лишены смысла.
Собственно, поэтому и глупо судить о степени заинтересованности человека лишь по объему его работы на первом этапе.
Есть и другие этапы. Причем, ничуть не менее важные.
По сути вопроса: я бы наверное предпочел вариант, когда для каждой строки, не только в name=*, в явном виде указывался язык и строка могла бы быть написана сразу на нескольких языках. Если я не ошибаюсь, то так сделано в 1С Предприятии, например.
Вполне разумное желание. В рамках текущей темы лишь отмечу, что такой вариант не подразумевает name без следующего за ним двоеточия. Т.е. тезис о бесполезности одновременного присутствия тегов name и name:ru в границах РФ этому пожеланию никак не противоречит.
Ну а рендерам/конвертерам в лубом случае придется знать на какой список языков где использовать. Даже в мапнике на уровне postgresql это решить можно.
Еще раз: у рендера и конвертера совершенно различные задачи в данном случае:
У рендера задача выбрать из существующих данных имена в соответствии с установленной на компьютере локалью (или выбором пользователя) и показать их пользователю.
У конвертера задача довести без искажения до рендера ВСЕ многоязычные ресурсы.
(давно в форум не заходил)
Проблема определить страну есть. Это только кажется, что её нет. Если я еду из Питера в Стокгольм, я скачиваю квадрат куда попадают оба города. Целиком Россия и целиком Финляндия и целиком Швеция в него не попадают. То есть даже если в теории рендереры научатся всасывать boundary relations, и для каждого объекта определять к какой стране они принадлежат, то в случае не полных стран они будут ошибаться. Также они не смогут принять решение для реки, которая пересекает границу.
P.S. liosha показал, что у osm2mp такая же логика выбора имени как и у mkgmap. То есть проблема не специфична для mkgmap. То есть --namelist=name:ru,name:en,name будет приводить к куче англоязычных названий посреди России, если бы не обсуждаемая правка.
что у osm2mp такая же логика выбора имени как и у mkgmap namelist=name:ru,name:en,name
…
будет приводить к куче англоязычных названий посреди России, если бы не обсуждаемая правка
Это логика не у osm2mp, для каждой генерируемой посредством osm2mp карты этот список задается [может задаваться] индивидуально.
Для России очевидно должно быть name:ru,name,name:en или вовсе name:ru,name, так что обсуждаемая правка тут ничему не помогает.
Для России очевидно должно быть name:ru,name,name:en или вовсе name:ru,name, так что обсуждаемая правка тут ничему не помогает. sad
Если отказаться от name:en, то тогда генерируя карту для поездки в сопредельную страну (скандинавские, прибалтийские страны, Беларусь, Украина, Казахстан, Монголия, и наконец Китай), которая захватывает мой путь и по России, я получу местные названия, которых я не знаю или вообще не могу прочесть. А английский знаю более менее.
Проблема-то понятна, но боюсь нормально её решить можно всё равно только обработкой границ. Дублировать name в name:ru - это не выход, тем более что дефолтный язык - это далеко не единственный “территориально-зависимый” параметр.
Обработка границ - очень сложная задача. Могут быть выгрузки в которые попадает несколько несвязанных фрагментов одной страны, могут быть анклавы. Так как морские границы сделаны очень длинными прямыми сегментами, то может получиться так, что в выгрузку не попадёт ни одной точки границы. Короче, предлагаю считать, что на сегодня задача очень сложна и малоприоритетна, чтобы появиться в osm2mp или mkgmap в близком будущем.
Дублировать name в name:ru - это не выход
Ладно, давайте попытаемся найти отрицательные последствия наличия name:ru? Только пожалуйста, оставьте аргумент о том, что база стала больше от его добавления :))
Ладно, давайте попытаемся найти отрицательные последствия наличия name:ru? Только пожалуйста, оставьте аргумент о том, что база стала больше от его добавления :))
задумчиво интересно, а какие были отрицательные последствия добавления кладров домам и рестрикшенов односторонним, кроме увеличения размеров базы?
предлагаю считать, что на сегодня задача очень сложна
Если не пытаться вытянуть полигон границы из самого осм файла, а взять готовый, подобно тому как берется готовый poly-файл для обрезки, то она наоборот проста как колобок.
Для Ситигида она как раз так и решается [таки да, собирается решаться] - обрезаются страны по границе, с небольшим отступом, чтобы не было зазоров между картами, а потом конвертятся каждая со своей последовательностью приоритеов языков, а объединяются для навигации, если маршрут проходит через несколько стран, в самом СГ в “атласе”.
и малоприоритетна
Если малоприоритетна, то вообще не понятно ради чего было огород городить. Типичное рисование под рендерер.
Кроме размера - необходимость поддерживать два названия и неопределенность различия name и name:ru - то ли в name:ru всегда должно быть равно name на территории РФ, толи name:ru должно содержать траслитерацию на кириллицу если на местности вдруг name на латинице (McDonalds)