Обсуждение Beta версий (тестирование, баги, замечания)

[User_tester]

Я, думаю, не нужно это. Зачем плодить дубликаты??? Зачем потом переводить это все? Адресная точка - введена только из-за точки подъезда. А для того, что бы в NAME - записать улица+номер дома - достаточно чтого, что полигон имеет полный адрес! Это же не АркГис!

Нет, тут вы не правы. Поясню:

1. дубликата - не будет. Типы HOUSE и ADDR_PNT разные!
2. переводить точки HOUSE - не надо. Они не поддерживают мультиязычность.
3. адресную точку ввели не потому, что уже была введена точка подъезда. Если нет адресной точки, то и точки подъезда быть не может.
4. если мы запишем в NAME зданий улицу+номер дома и скроем лабелы в компиляторе, то без точек HOUSE будет очень трудно пользоваться картой в навигаторе. А если включим отображение лабелов зданий, то будет ужасная мешанина. Проверено!

Так что без HOUSE не обойтись!

Вот так оно смотрится после компиляции:

http://i46.fastpic.ru/big/2013/0624/0e/ ... 34050e.png

А когда наводишь указатель на дом, всплывает его ПОЛНЫЙ адрес. Именно то, о чём писали ранее в хотелках о рекомендациях GARMIN:

http://i48.fastpic.ru/big/2013/0624/3f/ ... 2b833f.png

Добавлено спустя 4 минуты 14 секунд:

А переводишь чем "Транслитератором"?

Пока осваиваю на нем.

[Fencer_Silver]

"переводить точки HOUSE - не надо. Они не поддерживают мультиязычность"

Как это не поддерживают??? "Корп. 3 Д 4" - это что - на всех языках одинаково? Ведь номер дома - в "чистом виде", как цифра - встречается наиболее часто, но не всегда!
Так же "5А" - на русском и "5A" - на аглийском - разные надписи!

[Alex]

MicroGISEditor обновление v1.0.13.594b

 История изменений:

Версия 1.0.13.594b 14.07.2013
- Добавлено: инструмент создания точек "House" в строениях;
- Исправлено: найденные ошибки.

[User_tester]

Как это не поддерживают??? "Корп. 3 Д 4" - это что - на всех языках одинаково? Ведь номер дома - в "чистом виде", как цифра - встречается наиболее часто, но не всегда!Так же "5А" - на русском и "5A" - на аглийском - разные надписи!

Нет, не поддерживают. Потому что они не из категорий "города", "бизнес", "пользовательские точки". Возможно, Garmin поддержит в дальнейшем мультиязычность для всех точек без исключения. Но на сегодняшний день её могут иметь все полигоны, все полилинии и только указанные категории POI.

[Alex]

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

[Fencer_Silver]

Дима, о том как написан МРС манул - думаю, ты уже убедился... Индусы тебе еще и не то напишут. Сделай карту - и проверь. А если они ее не поддерживают.. То я отнесу Гармин к СГ - как это " КОРПУС 3 ДОМ 4 " - не может быть переведен???? Предам анафеме и перстану поддерживать ГАРМИН!!!!!

[User_tester]

- Добавлено: инструмент создания точек "House" в строениях;

Точки создаются, но без лабела. Надо обязательно в лабел копировать значение HouseNumber из здания.

Добавлено спустя 8 минут 51 секунду:
Только что сделал пробную сборку карты из исходника, в котором добавил русский язык, потом английский, транслицировал всё подряд. В карте адреса теперь ищутся так:

707.bmp (112.55 КБ) 16057 просмотров

Странно, что появилась служебная запись в конце. Смотрю шейп. Трудно его изучать, потому что там теперь из-за UTF-8 кракозябры, которые не понимаются DBF вьювером.

Добавлено спустя 9 минут 59 секунд:
Насчёт мультиязычности для точек HOUSE - проверил в карте, не поддерживают. Только базовая русскоязычная запись видна. Согласен, конечно, с вами, что запись номера дома HOUSE "5 КОРПУС 2" логичнее переводить как "5 DEPARTMENT 2" и менять туда-сюда при изменении системного языка навигатора. Но, увы, я не разработчик компилятора Garmin.

Добавлено спустя 33 минуты 2 секунды:
Удивительный момент: в лабелах зданий у меня стоит цифра номера дома, а в карте после сборки вижу на доме надпись вида "Ленина улица, 5". Получается, вы генерируете при экспорте в шейпы сборку "Улица+Номер дома"??? Сам DBF посмотреть не могу - он неразборчив в UTF-8

Добавлено спустя 27 минут 24 секунды:

Странно, что появилась служебная запись в конце. Смотрю шейп. Трудно его изучать, потому что там теперь из-за UTF-8 кракозябры, которые не понимаются DBF вьювером.

Ура! Нашёл ошибку! Глянул мануал и шейпы - для адресных точек при экспорте в поле HOUSE_NUM вместо вертикальной палочки | надо писать собачку @.

Тогда получится вот так:

305.bmp (112.55 КБ) 16052 просмотра

349.bmp (112.55 КБ) 16052 просмотра

[Fencer_Silver]

Ура! Нашёл ошибку! Надо для адресных точек при экспорте в шейпы вместо вертикальной палочки | писать собачку @.

Мля... Гармин начинает напрягать не меньше СГ. Скоро свой нафигатор прийдется писать.... :=( Здеь поподробнее : чего чему не хватает

[User_tester]

По мультиязычности.Делаю по инструкции. Установил базовый язык русский, добавил белорусский. Сохранил изменения. Теперь поправляю реестр адресов. Обновляю языки в карте, как написано в инструкции в пункте 4.И в исходнике в секции [Cities] в ключе LocCity1= для исправленного населенного пункта вижу старую запись. Она же и в шейпы уходит.

Теперь по поводу обновления языков в карте. Поставил новую точку POI, подписал её лабел. Обновил языки в карте. Сохранил изменения в исходник. Новое имя первоначально получилось таким же, как и оригинальное (видно в Notepad++). Зашёл в менеджер и перевёл. Статус стал "переведено". Затем поправляю лабел, снова обновляю языки в карте. Захожу в менеджер - а там статус прежний - "переведен"... А надо бы перевести заново.

Что я хочу этим сказать? Когда поправил атрибуты, имеющие мультиязычность, у ранее переведенных объектов, то в менеджере перевода надо им в обязательном порядке менять статус "переведено" обратно на "не переведено". Иначе ни за что в жизни не уследишь за всеми изменениями в карте, и полезут косяки. Картограф в карте за месяц поправил семантику, скажем, у 200 ранее переведенных объектов и нарисовал 100 новых. Перед релизом открыл менеджер - и пошёл переходить от одного непереведенного ко второму. Всего 300 позиций (200+100). А иначе - записывать на листок пришлось бы все правки старых объектов.

[Fencer_Silver]

Дима, я надеюсь, ты понимаешь, что компьютерные технологии - ограничены.... Я прошу, прежде чем писать, немножко подумать. Для чего введе статус " Переведено, Не переведно, Не переводить"??? И что делать? В общем, да, что-то в этом мире ограничено... Ну это, скорее к Биллу Гейтсу, а не к нам. А вот на мой предыдущий вопрос -я ответа так и не получил

[User_tester]

Мля... Гармин начинает напрягать не меньше СГ. Скоро свой нафигатор прийдется писать.... :=( Здеь поподробнее : чего чему не хватает

Для адресных точек в поле HOUSE_NUM:

12{LRUS@{LENG12
12А{LRUS@{LENG12А
12Б{LRUS@{LENG12B
12В{LRUS@{LENG12V
12Г{LRUS@{LENG12G
12Д{LRUS@{LENG12D

Для остальных объектов, согласно мануалу, в мультиязычной строке - палочка |

Вот некоторые выдержки из мануала МПС по спец. разделителям:

 

Point Addressing Attributes

House number of point’s address. Note: for numeric* point address types, multi language support is supported by separating each house number label with the ‘@’ character, and using the ‘{L’ language specification tag to mark the language of each house number (1200 KORP 2{LENG@1200 KORP 2 Russian{LRUS for example). Language tags MUST be present in multi-language house number labels. It should also be noted that when multiple house number labels are attached to a single point address, the leading numeric portion of the address MUST be the same in all labels. You CANNOT have a single point address with multiple, different house numbers (i.e. 1200 KORP 3 {LENG@1300 KORP 3{LENG is not supported).

L_STATE

If you would like street addresses to display the state abbreviation instead of the country in the second line, then you should provide a state abbreviation here. For instance, to display "Olathe, KS 66062" in the second line of an address, the L_STATE and R_STATE of the street should be "Kansas@KS".

This attribute supports formatting for multiple languages. If you are using abbreviations, you should only specify the language once for each full name/abbreviation pair, as in in the following string:

My German State@GA{LGER|My French State@FA{LFRE

Road Addressing Guidelines

Note: MPC previously used the '@' character instead of the '|' character to delimit alternate road names. The '@' character is still supported for this purpose, but for some other attributes, such as L_CITY and R_CITY described below, it has a different meaning.

The L_CITY and R_CITY can be used to specify the city in which the address range resides. Additionally, these attributes can provide up to 3 alternate administrative search areas on the left or right side of the road segment. These alternate administrative areas provide additional well known areas that can be used to locate an address in addition to the actual containing city. For example, in the city of " New York" an alternate administrative area could be "Queens" which can be used to filter containing address searches in addition to " New York ". The first string in each attribute is assumed to be the city name while up to the next 3 strings separated by the '@' symbol are assigned as alternate search administrative areas. In the case of " New York" and " Queens" the attribute would be specified as "New York@Queens" on the applicable sides.

Multiple Language Support

Alternate Name Marker
The first special marking is the '|' character, which indicates the start of an alternate name. The primary name is always the one listed first, and any alternate names should follow it and be separated by the '|' character. For example, the following shows a string consisting of a primary and two alternate names:

My Primary Name|My First Alternate Name|My Second Alternate Name

If you wish to include an actual '|' character as part of a name, you may escape it using a second '|' character. Thus, the string "This has a ||" will be output as "This has a |".

Добавлено спустя 4 минуты 37 секунд:

Дима, я надеюсь, ты понимаешь, что компьютерные технологии - ограничены.... Я прошу, прежде чем писать, немножко подумать. Для чего введе статус " Переведено, Не переведно, Не переводить"??? И что делать?

Посоветуйте, как быть, если за длительную работу я обновил семантику у множества ранее переведенных объектов. Как мне их отследить и обновить перевод? Или после каждого измененного прежнего объекта сразу же заходить в менеджер перевода?

Добавлено спустя 18 минут 42 секунды:

Поразбирался с проблемой. Насчёт префиксов могу уверенно сказать, что они почему-то перестали экспортироваться в виде {М, {P, {O, как было раньше. От кодировки это не зависит: экспортировал резервную рабочую карту в 1251-ой кодировке, которую последней беткой редактора ещё вообще не правил. Получил некорректные префиксы. Экспортировал копию этой карты в UTF-8 с добавленной мультиязычностью - аналогичная картина. Префиксы не переведены в понятный компилятору вид.

Эта проблема сохраняется. Префиксы вида ~[0x06] не становятся в шейпах {M, {P, {O. На карте вылазят теми же ~[0x06]!

[Fencer_Silver]

Да нах МРС мануал! Я его перечитал вдоль и поперк! Задолбали Индусы! Давай по-порядку:
1
2
3
Только из реальной жизни, а не из мануала! Прошу проверять все а прборе а не "из мануала". Ч проверить не могу - ну нет у мня прибра!

[User_tester]

Прошу проверять все а прборе а не "из мануала". Ч проверить не могу - ну нет у мня прибра!

Да, пожалуйста, я не против. Что конкретно ещё проверить? Некорректные префиксы - проверил, разделитель "палочка" - проверил, отсутствие мультиязычности HOUSE - тоже.

[Fencer_Silver]

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

[User_tester]

если действительно HOUSE не поддерживает мультиязычность ни в каком варианте, то значит мультиязычную надпись надо убирать из HOUSE.

Проверил в навигаторе - мультиязычности у HOUSE нет даже с разделителем-собачкой @.

Я вам больше скажу! Строго говоря, в навигаторе надо проверить весь стандартный набор POI на подддержку мультиязыка и чётко убедиться: где он поддерживается, где - нет. Это можно сделать. А потом обязательно исправить экспорт в шейпы, потому что там сейчас много лишнего! Не только для HOUSE пишется мультиязык, но и вообще для всего остального... Лично я сторонник чистоты формата и строгих правил. С ориентировкой на навигатор. Сделаем?

Далее.

По поводу некорректного экспорта в шейпы префиксов в дорогах - прошу обратить на это внимание!

Далее.

По поводу формирования лабела у зданий из улицы и номера дома при экспорте в шейпы. Обнаружены ошибки:

1. лабел, страна, район, город, улица заполнены, номер дома пустой - экспортирует комбинирование лабела и улицы. Это неправильно!
2. лабел пустой, страна, район, город, улица, номер дома заполнены - не экспортирует комбинирование. Это неправильно!
3. лабел, улица заполнены, страна, район, город, номер дома пустые - экспортирует комбинирование. Это неправильно!
4. без города комбинирует. Тоже неправильно!

В общем, экспортировать комбинированное название улица+номер дома надо только в случае наличия ПОЛНОЙ ПРАВИЛЬНО ЗАПОЛНЕННОЙ АДРЕСАЦИИ в полигоне:

[Countries]
Country1=БЕЛАРУСЬ
[END-Countries]

[Regions]
Region1=ГЛУССКИЙ РАЙОН, МОГИЛЁВСКАЯ ОБЛАСТЬ
CountryIdx1=1
[END-Regions]

[Cities]
City1=ГЛУСК
RegionIdx1=1
[END-Cities]

[POLYGON]
Type=0x13 (единственные варианты - 0x0008, 0x000A, 0x000B)
Label=17А
HouseNumber=17А
StreetDesc=КИРОВА{5УЛИЦА
CityIdx=1
Data0=(52.8977610,28.6866980),(52.8976600,28.6866980),(52.8976600,28.6864660),(52.8975490,28.6864670),(52.8975490,28.6862840),(52.8977600,28.6862830)
Floors=1
[END]

А также:

[POLYGON]
Type=0x13 (единственные варианты - 0x0008, 0x000A, 0x000B)
Label=
HouseNumber=17А
StreetDesc=КИРОВА{5УЛИЦА
CityIdx=1
Data0=(52.8977610,28.6866980),(52.8976600,28.6866980),(52.8976600,28.6864660),(52.8975490,28.6864670),(52.8975490,28.6862840),(52.8977600,28.6862830)
Floors=1
[END]