Не волнуйтесь, читал. Я сомневаюсь в том, что:
- возможно ввести в какой-то части сообщества отдельное правило про конкретный тег, используемый во всем мире.
- в России нет вывесок с названиями улиц не по-русски.
Не волнуйтесь, читал. Я сомневаюсь в том, что:
Повторюсь. Если не будет 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)
glebius, я имел в виду что границу нужно обрабатывать вообще отдельно, а не брать из того же дампа. ПДД-то тоже во всех странах разные.
Что касается name:ru, у меня основные претензии не к содержанию, а к исполнению
Ezhick, у домов нет кладров (а когда вдруг есть, то другие).
А про рестрикшены уже говорили: они ошибочные процентов на 90.
Ладно, давайте попытаемся найти отрицательные последствия наличия name:ru? Только пожалуйста, оставьте аргумент о том, что база стала больше от его добавления :))
А кто будет за ним следить? Вообще следить за тем, что в нем содержится валидная информация?
Тупо сравнивать name и name:ru не прокатит, как не прокатило с копированием name в name:ru.
А кто должен его добавлять?
Для Ситигида она как раз так и решается [таки да, собирается решаться] - обрезаются страны по границе, с небольшим отступом, чтобы не было зазоров между картами, а потом конвертятся каждая со своей последовательностью приоритеов языков, а объединяются для навигации, если маршрут проходит через несколько стран, в самом СГ в “атласе”
Для гарминовских карт я вытаскиваю границу по апи непосредственно перед конвертацией.
задумчиво интересно, а какие были отрицательные последствия добавления кладров домам и рестрикшенов односторонним, кроме увеличения размеров базы?
Ко мне вопрос что ли? Я не против них.
Что касается name:ru, у меня основные претензии не к содержанию, а к исполнению
Я не отрицаю что накосячил. Хотя тот факт, что дамп редактирует ways и relations что в базе весьма неожиданный.
А кто будет за ним следить? Вообще следить за тем, что в нем содержится валидная информация?
Тупо сравнивать name и name:ru не прокатит, как не прокатило с копированием name в name:ru.
А кто должен его добавлять?
Ну и вопросы. А кто следит за name? Кто следит за name:en? Кто вообще следит за OSM? Кому нужно и интересно, тот и следит. Точь в точь как и со всеми остальными тэгами.
А как вы планируете синхронизировать те изменения, которые сделаны только в одном теге?
А как вы планируете синхронизировать те изменения, которые сделаны только в одном теге?
Ну когда кто-то будет править один тег
он вполне может заметить и другой тег?