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

Полноценный картографический редактор, предназначенный для создания векторных карт и картографических планов местности в открытом картографическом формате (*.PFM - Map Polish Format) с последующей компиляцией в различные (обменные, закрытые) картографические форматы, для использования в различных навигационных программах и приложениях.

Модераторы: Fencer_Silver, Admin, Alex

Cnfhbr
Бета тестер
Бета тестер
Сообщения: 197
Зарегистрирован: 12 фев 2012, 11:42
Откуда: Казахстан

Re: Beta тестирование (обсуждение функционала beta версий)

Сообщение Cnfhbr »

DarkDiver писал(а):Структура исходника правильная, но как оказалось, формат тип-файла принятый в TypViewer не совсем совместим с форматом принятым в cGPSMapper в части касаемой описания точек. А именно, для трех байтных типов, cGPSMapper правильно понимает только такой способ записи: Type=0x01040d

А TypViewer понимает только такой способ записи:
Type=0x104
SubType=0x0d

В противном случае начинаются проблемы.
Кроме того, если, к примеру, скомпилировать маппером твой текстовый файл из Default-MPC-typ, то косяки будут не только для точек, но и для полигонов с полилиниями, и не только для расширенных 3-х байтных типов...
При этом, TYPViewer компилирует в TYP формат точно так же, как это делает MPC (ну и Garmin в целом), в том числе и в отношении точек...
Таким образом, текущий cGPSmapper уже отстал от жизни, и нельзя компилировать им непосредственно обсуждаемый I0000002.txt :!:
Cnfhbr писал(а):
Alex писал(а):Ждем ответа Cnfhbr, по предложенному идентификаторы языка "StringХ=0x64".
На всякий случай написал автору TYPViewer'а, вдруг у него уже виды на этот код, под какой-нибудь камызякский.
Как ответит, маякну...
Если коротко, то Мишель не видит подводных камней в применении кода 0x64 при его использовании для внутренних нужд MGE...
DarkDiver
Бета тестер
Бета тестер
Сообщения: 363
Зарегистрирован: 06 мар 2012, 04:31
Контактная информация:
Россия

Re: Beta тестирование (обсуждение функционала beta версий)

Сообщение DarkDiver »

Cnfhbr писал(а): Кроме того, если, к примеру, скомпилировать маппером твой текстовый файл из Default-MPC-typ, то косяки будут не только для точек, но и для полигонов с полилиниями, и не только для расширенных 3-х байтных типов...
При этом, TYPViewer компилирует в TYP формат точно так же, как это делает MPC (ну и Garmin в целом), в том числе и в отношении точек...
Таким образом, текущий cGPSmapper уже отстал от жизни, и нельзя компилировать им непосредственно обсуждаемый I0000002.txt :!:
Боюсь дело не в cGPSMapper. Тот текстовый файл, про который ты говоришь был получен путем декомпиляции при помощи TypViewer тип-файла, который был получен при помощи MPC. Разумеется полученный при помощи TypViewer исходник прекрасно компилируется назад при помощи него же самого. Формат исходника тип-файла придуман Стэном - автором cGPSMapper, а автор TypViewr-а позволяет себе в этом формате вольности, которые не совместимы с cGPSMapper, при чем в тех местах где эти вольности совсем не нужны - в идентификаторах типов (Про всякие там Etended Labels я ни чего не говорю - эти строки cGPSMapper просто игнорирует и ни каких проблем не возникает). Так что данная проблема как раз таки именно в TypViewer-е. Хотя в целом, по функционалу, cGPSMapper конечно же отстает от TypViewer - спору нет.
http://john.bdk.com.ru
Cnfhbr
Бета тестер
Бета тестер
Сообщения: 197
Зарегистрирован: 12 фев 2012, 11:42
Откуда: Казахстан

Re: Beta тестирование (обсуждение функционала beta версий)

Сообщение Cnfhbr »

DarkDiver писал(а):Формат исходника тип-файла придуман Стэном - автором cGPSMapper, а автор TypViewr-а позволяет себе в этом формате вольности, которые не совместимы с cGPSMapper, при чем в тех местах где эти вольности совсем не нужны - в идентификаторах типов (Про всякие там Etended Labels я ни чего не говорю - эти строки cGPSMapper просто игнорирует и ни каких проблем не возникает). Так что данная проблема как раз таки именно в TypViewer-е.
Дык, автор TYPViewer'а поддерживал cGPSmapper до последнего, пока Garmin не стал активно использовать "расширенные" типы объектов и др.
Вот, как описывает сложившуюся ситуацию в этом плане сам автор TYPViewer'а:
Not exactly.
As input, TYPViewer supports both types :"Type=0x01040d" and "Type=0x104 SubType=0x0d"

As output, TYPViewer uses this type "Type=0x01040d" for polygons and polylines and this type "Type=0x104 SubType=0x0d" for POI .

Why this strange behaviour? For compatibility with cGPSmapper.
At the beginning, extended types (for example 0x10d ) didn't exist and polygons and polylines didn't have subtypes.
So the syntax created by cgpsmapper was:
-Type=0x4b for polygons and polylines

- Type=0x66
SubType=0x1a for POIs

Then extended types and also subtypes for polygons/polylines appeared in official Garmin typ-files .
cGPSmapper in a first time didn't support this and later it supports subtypes for polygons and polylines but with the syntax Type=0x10d1a !!! (while the syntax for POIs remain the same, that is to say Type=0x66 and SubType=1a )
This is the reason why I use this syntax in TYPViewer...

But cGPSmapper has never evolve to support the new objects discovered in official Garmin typ-files ( polygons without bitmaps, lines without border, the 5 others types of POI - cGPSmapper only supports POI with palette and colormode 16, POI without bitmap, extended labels , etc...)
So I have decided to keep on developing TYPViewer without looking at cGPSmapper.

Now, I don't know exactly what is supported by cGPSmapper and what is exactly its syntax.

I compile all my txt with TYPViewer and I try to make TYPViewer updated, so that it supports all existing objects of official Garmin.
Кроме того, автор другого известного редактора типов (TypWiz) в своём описании TYP формата (Garmin’s TYP & TYP NT format) постоянно напоминает о трудностях cGPSmappera в отношении парсинга "расширенных" типов, вот выдержки:
‘Extended’ Polygons with types &h100+
Several TYP files include type values of &h100+. They could perhaps be used to create overlays or to ensure visibility at any/most zoom level(s) – see polylines with types &h100+
Cgpsmapper has difficulty parsing polygons with subtypes – if you are compiling text rewrite any occurrences of ‘subtype=’ into ‘type=’.
* * *
Polylines with extended types &h100+
Several TYP files include type values of &h100+. They are used to create overlays or to ensure visibility at any/most zoom level(s) .
Cgpsmapper has difficulty parsing polygons with subtypes – if you are compiling text rewrite any occurrences of ‘subtype=’ into ‘type=’. Unfortunately , draworders get ignored completely if type= 0x10000 – 0x1001F.
* * *

и т.д.
И наконец, в этом описании (стр.23) автор TypWiz'а вводит специальные предостережения для пользователей cGPSmapper'а:
Cgpsmapper parsing TYP files
For those using cpgsmapper to compile text into a typ file, a few words of caution.
Though generally excellent, at times, this program produces some very quirky results:
• When parsing polygons , in certain circumstances , unexpected night versions are added.
• Transparency in polylines is replaced with &FFFFFF if a night version doesn’t contain transparency.
• Cgpsmapper does not allow polylines of types 0 and 6 to have bmps. And yet, I have seen both 0 and 6 types contain bitmaps with 1 solid colour and transparency. Type 6 becomes 7, and type 0 is changed into 3.
• Borderwidth of certain polylines are reset to zero.
• The 'types' of some POIs are wrongly parsed and set to its own default, ie bus stops. This may be a good thing as its ‘better’ to stick to Garmins original typ list, but it reflects personal preference.
• If [draworder] is ‘empty’ , it creates its own list! Also, polygons with type 0x10000 to 0x1001f lose their draworder altogether!
Некоторые из этих предостережений я специально проверил на практике - подтверждаю, есть у маппера такие косяки... :!:


Добавлено спустя 25 минут 9 секунд:
DarkDiver писал(а):А вот тут Вы все поняли абсолютно не правильно.
Вы все или Вы всё? :|
KartaBY
Активный пользователь
Активный пользователь
Сообщения: 128
Зарегистрирован: 05 апр 2012, 10:55
Контактная информация:
Беларусь

Re: Beta тестирование (обсуждение функционала beta версий)

Сообщение KartaBY »

Послушал все вышесказанное :?

Может тогда проще при перегонке в шейпы формировать XML как это описывается в мануле к МПС?
И иметь возможность подключения к микрогис и XML МПС и ТУП для корректного отображения.
Kartaby.by
DarkDiver
Бета тестер
Бета тестер
Сообщения: 363
Зарегистрирован: 06 мар 2012, 04:31
Контактная информация:
Россия

Re: Beta тестирование (обсуждение функционала beta версий)

Сообщение DarkDiver »

Vovan_Alm писал(а): Можно повторить и выложить самый новый J-typ файл? А если он еще будет оптимизирован под МГЕ, то я буду просто счастлив... ;)
Выложил обещанные тип-файлы. Чтобы не справоцировать путаницу, объясню. Данный тип-файл начинал создаваться, когда еще не было ни чего известно ни о трех-байтных типах (они не поддерживались ни в cGPSMapper, ни в GME), ни о рекомендуемых значениях для кастомных типов. Поэтому в данном тип-файле для многих кастомных полигонов используются свободные однобайтные типы. Такой подход вполне работоспособен, но не корректен с точки зрения классификатора типов Garmin. Поэтому в будущем я планирую его полностью переработать, чтобы все кастомные типы имели идентификаторы из рекомендуемых диапазонов, а не как сейчас..

Добавлено спустя 1 минуту 30 секунд:
Cnfhbr писал(а):
DarkDiver писал(а):А вот тут Вы все поняли абсолютно не правильно.
Вы все или Вы всё? :|
"Вы всЁ" :)

Добавлено спустя 41 минуту 22 секунды:
KartaBY писал(а):Послушал все вышесказанное :?
Может тогда проще при перегонке в шейпы формировать XML как это описывается в мануле к МПС?
И иметь возможность подключения к микрогис и XML МПС и ТУП для корректного отображения.
Да, я давно предлагал это сделать.
Вложения
J-Typ-v78.rar
(45.67 КБ) 562 скачивания
http://john.bdk.com.ru
DarkDiver
Бета тестер
Бета тестер
Сообщения: 363
Зарегистрирован: 06 мар 2012, 04:31
Контактная информация:
Россия

Re: Beta тестирование (обсуждение функционала beta версий)

Сообщение DarkDiver »

Cnfhbr писал(а):Кроме того, если, к примеру, скомпилировать маппером твой текстовый файл из Default-MPC-typ, то косяки будут не только для точек, но и для полигонов с полилиниями, и не только для расширенных 3-х байтных типов...
Можно по подробнее что за косяки, я скомпилил и ни каких косяков кроме упомянутого - с трехбайтными идентификаторами точек, я не увидел...

Добавлено спустя 33 минуты 4 секунды:
Cnfhbr писал(а): Вот, как описывает сложившуюся ситуацию в этом плане сам автор TYPViewer'а:
Not exactly.
As input, TYPViewer supports both types :"Type=0x01040d" and "Type=0x104 SubType=0x0d"

Не правда. Type=0x01040d - превращается в
Type=0x40d
SubType=0x00
Что не правильно.


Cnfhbr писал(а):
As output, TYPViewer uses this type "Type=0x01040d" for polygons and polylines and this type "Type=0x104 SubType=0x0d" for POI .

Why this strange behaviour? For compatibility with cGPSmapper.
At the beginning, extended types (for example 0x10d ) didn't exist and polygons and polylines didn't have subtypes.
So the syntax created by cgpsmapper was:
-Type=0x4b for polygons and polylines

- Type=0x66
SubType=0x1a for POIs

Не правильно. Для полигонов, полилинийй и трехбайтных типов точек можно использовать только такой формат записи: Type=0x01040d
А вот для двухбайтных точек можно указывать двумя спопобами: Type=0x6511 или
Type=0x065
SubType=0x11
ОДнако Мишель почему то решил, что так же можно поступать и с трех-байтными типами. Вообще не понятно зачем хранить идентификаторы для точек иначе чем для полигонов и линий. Сделал бы одинаково для всех видов объектов в одну строчку - без сабтипов - и ни каких проблем бы не было.

Cnfhbr писал(а):
Then extended types and also subtypes for polygons/polylines appeared in official Garmin typ-files .
cGPSmapper in a first time didn't support this and later it supports subtypes for polygons and polylines but with the syntax Type=0x10d1a !!! (while the syntax for POIs remain the same, that is to say Type=0x66 and SubType=1a )
This is the reason why I use this syntax in TYPViewer...

But cGPSmapper has never evolve to support the new objects discovered in official Garmin typ-files ( polygons without bitmaps, lines without border, the 5 others types of POI - cGPSmapper only supports POI with palette and colormode 16, POI without bitmap, extended labels , etc...)
So I have decided to keep on developing TYPViewer without looking at cGPSmapper.

Тоже не со всеми утверждениями согласен. Полигоны без битмапов поддерживаются, линии без бордеров поддерживаются.

Cnfhbr писал(а): Кроме того, автор другого известного редактора типов (TypWiz) в своём описании TYP формата (Garmin’s TYP & TYP NT format) постоянно напоминает о трудностях cGPSmappera в отношении парсинга "расширенных" типов, вот выдержки:
Cgpsmapper has difficulty parsing polygons with subtypes – if you are compiling text rewrite any occurrences of ‘subtype=’ into ‘type=’.

Правильно потому, что у полигонов и полилиний сабтипов быть не должно, что мешает записывать тип правильно - в одну строчку, зачем вообще сабтипы использовать...

Cnfhbr писал(а):
Unfortunately , draworders get ignored completely if type= 0x10000 – 0x1001F.

А нефиг использовать не рекомендуемые идентификаторы к которым отнсится весь диапазон type= 0x10000 – 0x1001F, я не мало разных граблей находил при использовании произвольных идентификаторов. С рекомендуемыми диапазонами все нормально.

Cnfhbr писал(а): И наконец, в этом описании (стр.23) автор TypWiz'а вводит специальные предостережения для пользователей cGPSmapper'а:
Cgpsmapper parsing TYP files
For those using cpgsmapper to compile text into a typ file, a few words of caution.
Though generally excellent, at times, this program produces some very quirky results:
• When parsing polygons , in certain circumstances , unexpected night versions are added.

С этим не сталкивался.

Cnfhbr писал(а):
• Transparency in polylines is replaced with &FFFFFF if a night version doesn’t contain transparency.

Не правильно, это старые версии софта и некоторых прошивок иногда интерпретируют прозрачный цвет не правильно, например как черный.
Но в тип-файле - все ок.

Cnfhbr писал(а):
• Cgpsmapper does not allow polylines of types 0 and 6 to have bmps. And yet, I have seen both 0 and 6 types contain bitmaps with 1 solid colour and transparency. Type 6 becomes 7, and type 0 is changed into 3.

0 - вообще не нужно использовать, остальные проблемы у меня не воспроизводятся.

Cnfhbr писал(а):
• Borderwidth of certain polylines are reset to zero.

Не правильно, такая проблема есть только на некторых прошивках некоторых моделей навигаторов, когда для некоторых типов BorderWidth=1 интерепретируется как BorderWidth=0. Но в самом тип-файле - все ок.

Cnfhbr писал(а):
• The 'types' of some POIs are wrongly parsed and set to its own default, ie bus stops. This may be a good thing as its ‘better’ to stick to Garmins original typ list, but it reflects personal preference.
• If [draworder] is ‘empty’ , it creates its own list! Also, polygons with type 0x10000 to 0x1001f lose their draworder altogether!

Некоторые из этих предостережений я специально проверил на практике - подтверждаю, есть у маппера такие косяки... :!:

[/quote]
Про типы 0x10000 to 0x1001f уже написал, с остальным не сталкивался.

Добавлено спустя 30 минут 27 секунд:
Fencer_Silver писал(а):
Vovan_Alm писал(а):Тогда надо разделить 2 тайпсета Гармин Маппер и Гармин МПС... если нельзя поддержать оба компилятора.

Насколько я знаю - здесь один пользователь cGPSMappera - DarkDiver. Зачем ты решаешь за него?


Оба компилятора поддержать можно и они уже поддержаны, просто нужно понимать что некоторые вещи будут работать только при использовании одного компилятора, а некоторые только при использовании другого компилятора - тут все на совести картографа. Но в общем случае одну и ту же карту можно скомпилить при помощи любого компилятора, вот только функционал карты в итоговом формате может отличаться, а может и не отличаться, в зависимости от исходника.

Добавлено спустя 13 секунд:
User_tester писал(а): Достаточно, ИМХО, одной шаблонной таблицы. Можно коды кастомов заранее вбить в неё. А пользователи пусть назначают им, какие захотят, произвольные соответствия типа "OCHEN' JELEZNAJA DOROGA" и проч. И потом подсоединяют свою таблицу в окно экспорта в шейпы. Жмут "Экспорт" - и получают из кастомов, что хотели, согласно своей таблице, плюс стандартные объекты В НЕИЗМЕННОМ ВИДЕ.


Опять за старое. Ну причем тут окно экспорта в шейпы и таблицы перехода между типами. Начните наконец разбивать задачу на подзадачи и мыслить модульно. Будут более универсальные решения в голову приходить. А именно:

1) Переход из одного тайпсета в другой с заменой типов в соответствии с некоторой таблицей - это отдельная функция - ни как не связанная с экспортом в шейпы, и использовать ее иногда можно и нужно будет отдельно, в том числе совсем не для экспорта в шейпы.

2) Экспорт в шейпы - отдельная функция - как сделано сейчас - выполняется в строгом соотвествии с классификатором.

3) Назначение произвольных текстовых идентификаторов GTMN_TYPE для кастомных типов - это отдельный функционал, реализованный через тип-файл, и никак не связанный с п.1 (переход между тайпсетами по таблице)

Не надо все это смешивать в одну мутную кашу, а потом долго спорить, что со всем этим делать.

Добавлено спустя 4 минуты 58 секунд:
Vovan_Alm писал(а):У меня вопрос, наверное всем известно что в Гармине на мелких масштабах не отображается Железная Дорога. Собственно потому и вводят пользователи ZHELEZNAYA_DOROGA - кастомную полилинию. У меня вопрос, как правильно поступить, если у вас не допускается переопределять стандартные типы?

Нельзя переопределять стандартные типы - это значит, что нельзя использовать, например, стандартный тип 0x14 - железная дорога, для обозначения оврагов. Но использовать для обозначения ЖД помимо стандартного типа еще и кастомный - вполне можно - почему нет.

Добавлено спустя 2 минуты 33 секунды:
User_tester писал(а):P.S. Насчёт неотображения RAILROAD я у себя проверю в приборе. Интересно, как такое бывает и бывает ли?

Это общеизвестная проблема - стандартный тип ЖД отображается в навигаторах до 500 м вне зависимости от того как разнесено по слоям в карте.
Кроме того подобная проблема наблюдается и с некоторыми другими типами. Например полилиния "река" отображается только до 12 км, и т.п. Но случай с ЖД наиболее критичный.

Добавлено спустя 1 минуту 20 секунд:
User_tester писал(а):А из ТОПО экспорт в MPC шейпы вообще лучше убрать, и не будет ошибок и проблем.

Абсолютно согласен.

Добавлено спустя 2 минуты 40 секунд:
User_tester писал(а): говорил, что нельзя иметь 1 суперский исходник и по мановению волшебной палочки переводить его в любые карты для любых систем.


Очень даже можно при соблюдении некоторых правил, ну и с некоторыми оговорками конечно же..
Просто такой универсальный исходник придется обрабатывать тем или иным образом перед конвертацией в каждый из итоговых форматов. Но это можно автоматизировать при желании.

Добавлено спустя 10 минут 5 секунд:
warpig писал(а):
Vovan_Alm писал(а):Кстати... можно ввести в набор ТОПО эти типы с файла J-typ там реально топографический набор... Хоть карты станут похожими на карты...


Не надо это совать в лишнего в Топо!

Лишнее - это понятие субъективное, Вам лишнее, а мне например - нет.
В конце концов, если Вам не нужны некоторые типы - не используйте их.
А еще лучше если в Ситигид будут реализованы кастомные типы по примеру Гармина :)

warpig писал(а): Топо, это моё мнение, должно быть автомобильный навигационный тайп... ! Ну не нужно в автомобильной навигации - сады, огороды, лес смешанный или редкий!
Для этого есть ози с генштабом, если у тебя не выверен дорожный граф - нахер мне картинка с "лес редкий"! Я понимаю что для Казахстана это актуально - но для местности где есть/нужны дороги это лишнее!!!

А я вот возможно считаю, что навигатор гораздо больше нужен в лесу/в горах, а не на дороге. И соответственно детальная топонагрузка гораздо важнее чем всякая там полосность и 3Д-модели. А кто-то считает иначе, и тоже по своему прав, так что не надо быть таким категоричным.

Добавлено спустя 5 минут 24 секунды:
Alex писал(а):Желание понятно, мы пошли на встречу и предложили заменить структуры на:

Код: Выделить всё

String1=0x04,Custom area 11
String2=0x19,Пользовательская область 11
String3=0x64,CUSTOMIZABLE_AREA_11
На мой взгляд, такой способ - это удачное решение.
http://john.bdk.com.ru
User_tester
Бета тестер
Бета тестер
Сообщения: 1149
Зарегистрирован: 23 апр 2012, 11:23
Беларусь

Re: Beta тестирование (обсуждение функционала beta версий)

Сообщение User_tester »

DarkDiver писал(а):Опять за старое. Ну причем тут окно экспорта в шейпы и таблицы перехода между типами. Начните наконец разбивать задачу на подзадачи и мыслить модульно. Будут более универсальные решения в голову приходить. А именно:1) Переход из одного тайпсета в другой с заменой типов в соответствии с некоторой таблицей - это отдельная функция - ни как не связанная с экспортом в шейпы, и использовать ее иногда можно и нужно будет отдельно, в том числе совсем не для экспорта в шейпы.2) Экспорт в шейпы - отдельная функция - как сделано сейчас - выполняется в строгом соотвествии с классификатором.3) Назначение произвольных текстовых идентификаторов GTMN_TYPE для кастомных типов - это отдельный функционал, реализованный через тип-файл, и никак не связанный с п.1 (переход между тайпсетами по таблице)Не надо все это смешивать в одну мутную кашу, а потом долго спорить, что со всем этим делать.
DarkDiver неправильно понял. :| Речь совсем не шла о переходе между тайпсетами ТОПО и Гармин! Я согласен с написанным тобой. И тогда я говорил о переводе кастомов из тайпсета Гармин с помощью внешней таблицы в любые пользовательские типы. Это может являться альтернативой (на усмотрение разработчиков) имеющемуся прописыванию в скин, поскольку последнее вызвало определенные неудобства у картографов.
Последний раз редактировалось User_tester 29 ноя 2012, 06:05, всего редактировалось 1 раз.
Vovan_Alm
Бета тестер
Бета тестер
Сообщения: 482
Зарегистрирован: 05 апр 2012, 13:09
Откуда: Алма-Ата

Re: Beta тестирование (обсуждение функционала beta версий)

Сообщение Vovan_Alm »

Нельзя переопределять стандартные типы - это значит, что нельзя использовать, например, стандартный тип 0x14 - железная дорога, для обозначения оврагов. Но использовать для обозначения ЖД помимо стандартного типа еще и кастомный - вполне можно - почему нет.
Ну как бы логично было бы (по крайней мере для меня) переопределить 0х14= CUSTOMIZABLE_LINE_1, а еще лучше 0х14=ZHELEZNAYA_DOROGA (CUSTOMIZABLE_LINE_1) тогда никаких проблем, делаешь карту для 7Дорог 0х14 полилиния становится железной дорогой, т.к проблем нет с отображением ЖД в 7 Дорог... Делаю карту Гармина - 0х14 тип становится кастомом, и отображается во всех Гарминах правильно... Но Вы же все опять меня скушать попытаетесь, опираясь на ранее утвержденный (кем-то) классификатор...

Да ладно хрен с ним с классификатором... Я уже устал отстаивать свое удобство работы... Сделайте хоть какой то механизм перекодировки типов, модульный, не модульный... в отдельном пункте меню, или в меню конвертации в шейпы... НО СДЕЛАЙТЕ ХОТЬ ЧТО-НИБУДЬ... что бы я не использовал кучу танцев с бубном и МП Утилитами...
Garmin - Forever!!!
DarkDiver
Бета тестер
Бета тестер
Сообщения: 363
Зарегистрирован: 06 мар 2012, 04:31
Контактная информация:
Россия

Re: Beta тестирование (обсуждение функционала beta версий)

Сообщение DarkDiver »

Vovan_Alm писал(а):
Нельзя переопределять стандартные типы - это значит, что нельзя использовать, например, стандартный тип 0x14 - железная дорога, для обозначения оврагов. Но использовать для обозначения ЖД помимо стандартного типа еще и кастомный - вполне можно - почему нет.
Ну как бы логично было бы (по крайней мере для меня) переопределить 0х14= CUSTOMIZABLE_LINE_1, а еще лучше 0х14=ZHELEZNAYA_DOROGA (CUSTOMIZABLE_LINE_1) тогда никаких проблем, делаешь карту для 7Дорог 0х14 полилиния становится железной дорогой, т.к проблем нет с отображением ЖД в 7 Дорог... Делаю карту Гармина - 0х14 тип становится кастомом, и отображается во всех Гарминах правильно... Но Вы же все опять меня скушать попытаетесь, опираясь на ранее утвержденный (кем-то) классификатор...
Классификатор придуман не кем-то, а компанией Garmin, мы лишь его изучили и стараемся ему следовать. Но Вы так и не хотите понимать, что 0х14 НЕ равно CUSTOMIZABLE_LINE_1, потому что CUSTOMIZABLE_LINE_1 = 0x10e00 и никак иначе.

Поэтому преобразование надо проводить вот так 0x14 -> 0x10e00 - тоже ни каких проблем, а текстовые идентификаторы вообще нафиг выбросить из головы раз и навсегда, чтоб не мешали восприятию :)
http://john.bdk.com.ru
Vovan_Alm
Бета тестер
Бета тестер
Сообщения: 482
Зарегистрирован: 05 апр 2012, 13:09
Откуда: Алма-Ата

Re: Beta тестирование (обсуждение функционала beta версий)

Сообщение Vovan_Alm »

DarkDiver вот можно вопрос? Почему ты считаешь, что скрипт Василия делает так 0х14 = CUSTOMIZABLE_LINE_1... По моему мнению он делает вот так: 0х14 ----> CUSTOMIZABLE_LINE_1 =0x10e00 Ибо вот это CUSTOMIZABLE_LINE_1= 0x10e00 чистая прерогатива МПС, и какое бы мы решение тут не приняли ГАРМИН жестко зашил свои идентификаторы в МПС, и они не доступны для изменения... ;) В скрипте просто проводятся 2 действия... 1-е преобразование типов 2-е производство шейпов... Все вышеописанное никак не конфликтует ни с идентификаторами, ни с видением правил картографии некоторых товарищей... :)
Garmin - Forever!!!
DarkDiver
Бета тестер
Бета тестер
Сообщения: 363
Зарегистрирован: 06 мар 2012, 04:31
Контактная информация:
Россия

Re: Beta тестирование (обсуждение функционала beta версий)

Сообщение DarkDiver »

Vovan_Alm, я уже несколько раз объяснял, что я считаю и почему. Не вижу смысла повторяться.
http://john.bdk.com.ru
Vovan_Alm
Бета тестер
Бета тестер
Сообщения: 482
Зарегистрирован: 05 апр 2012, 13:09
Откуда: Алма-Ата

Re: Beta тестирование (обсуждение функционала beta версий)

Сообщение Vovan_Alm »

Угу... я так тоже говорю, когда мне не хватает убедительных аргументов... Больше тоже спорить не намерен... Ибо смысла об стенку биться не вижу... Мы пойдем другим путем (с)
Garmin - Forever!!!
Cnfhbr
Бета тестер
Бета тестер
Сообщения: 197
Зарегистрирован: 12 фев 2012, 11:42
Откуда: Казахстан

Re: Beta тестирование (обсуждение функционала beta версий)

Сообщение Cnfhbr »

DarkDiver писал(а):
Cnfhbr писал(а):Кроме того, если, к примеру, скомпилировать маппером твой текстовый файл из Default-MPC-typ, то косяки будут не только для точек, но и для полигонов с полилиниями, и не только для расширенных 3-х байтных типов...
Можно по подробнее что за косяки, я скомпилил и ни каких косяков кроме упомянутого - с трехбайтными идентификаторами точек, я не увидел...
Косяков достаточно, назову главные:
- полигоны без рисунка, с дневной и ночной расцветкой, потеряли ночную расцветку, и наоборот - полигоны без рисунка, без ночной расцветки, т.е. с одной расцветкой днём и ночью, вдруг приобрели нелепую ночную расцветку;
- полилинии без окантовки приобрели огромную окантовку и стали внешне напоминать полигоны;
- ну, а с точками и так понятно...
DarkDiver писал(а):
Cnfhbr писал(а):Вот, как описывает сложившуюся ситуацию в этом плане сам автор TYPViewer'а:
Not exactly.
As input, TYPViewer supports both types :"Type=0x01040d" and "Type=0x104 SubType=0x0d"
Не правда. Type=0x01040d - превращается в
Type=0x40d
SubType=0x00
Что не правильно.
Нет правда! На входе TYPViewer поддерживает оба вида записи, как в одну строчку, так и с подтипами. А то, что для точек поддерживается только с подтипами - дык это на выходе (именно так объясняет Мишель, если не вырывать его фразы из контекста). Далее он поясняет, почему так получилось - для совместимости с маппером. С его слов, в то время, когда он ещё старался поддерживать совместимость с маппером, Станислав использовал для точек именно запись с подтипами. Каков сейчас синтаксис всего этого в маппере, Мишель точно не знает и знать, похоже, не желает, поскольку сосредоточился на поддержке официальных и актуальных тип-файлов от Garmin.

P.S. Ну, что я как толмач, ей богу, Мишель же всё подробно разжевал...
DarkDiver писал(а):Вообще не понятно зачем хранить идентификаторы для точек иначе чем для полигонов и линий. Сделал бы одинаково для всех видов объектов в одну строчку - без сабтипов - и ни каких проблем бы не было.
Если кроме пережитков прошлой совместимости с маппером ничего больше не держит, полагаю, Мишель реализует это пожелание. Н-н-нада? :?:
DarkDiver писал(а):Тоже не со всеми утверждениями согласен. Полигоны без битмапов поддерживаются, линии без бордеров поддерживаются.
Ну, если это можно назвать поддержкой, то явно некорректной (см. выше косяки с полигонами без рисунка и с линиями без окантовки).
От себя замечу, что маппер также обрабатывает неправильно: полигоны и линии с ночной прозрачностью, если дневная расцветка не прозрачна и наоборот; POI без рисунка; POI без палитры (0 цветов, т.е. True Colors) и т.д., о свежих фичах Garmin говорить не буду...
DarkDiver писал(а):
Alex писал(а):Желание понятно, мы пошли на встречу и предложили заменить структуры на:

Код: Выделить всё

String1=0x04,Custom area 11
String2=0x19,Пользовательская область 11
String3=0x64,CUSTOMIZABLE_AREA_11
На мой взгляд, такой способ - это удачное решение.
Тады, если не в лом, попробуй отредактировать предложенный разработчиками I0000002.txt независимым редактором (например, notepad++) так, чтобы cGPSmapper скомпилировал его в TYP без ошибок, при этом, чтоб в шейпы для MPC также записывалось всё, что тут задумали, да и закроем вопрос. ;)
Сам я не пользуюсь маппером в этих целях, поскольку не считаю реализацию TYP формата в интерпретации Станислава безупречной и, тем более, актуальной...
DarkDiver писал(а):
KartaBY писал(а):Может тогда проще при перегонке в шейпы формировать XML как это описывается в мануле к МПС?
И иметь возможность подключения к микрогис и XML МПС и ТУП для корректного отображения.
Да, я давно предлагал это сделать.
Было бы ништяк! :D
Аватара пользователя
Alex
Администратор
Администратор
Сообщения: 1017
Зарегистрирован: 06 фев 2012, 15:57
Откуда: Украина
Настроение:
Контактная информация:
Украина

Re: Beta тестирование (обсуждение функционала beta версий)

Сообщение Alex »

Поддержка XML это совсем другой вопрос. Сначало необходимо разрулить создавшуюся ситуацию вогруг TYP файла. Судя по вашим постам, я так понимаю - возражений нет, по поводу задействования записи вида: StringХ=0x64,GRMN_TYPE Значит на этом и останавливаемся.
💻 Всегда где-то рядом. Если что — найдём решение.
Аватара пользователя
Alex
Администратор
Администратор
Сообщения: 1017
Зарегистрирован: 06 фев 2012, 15:57
Откуда: Украина
Настроение:
Контактная информация:
Украина

Re: Beta тестирование (обсуждение функционала beta версий)

Сообщение Alex »

Обновился файл справки до v1.0.11.532. Скачать можно отсюда
💻 Всегда где-то рядом. Если что — найдём решение.
Ответить