Дык, кто ж спорит, что Garmin жёстко кодирует свои типы, причём в обычном и NT формате зачастую по-разному? Я лишь говорил о жёстком соответствии с кодировкой в "польском"!DarkDiver писал(а):MPC Конвертирует каждый конкретный GRMN_TYPE в однозначный и конкретный HEX ID. Поэтому это соответствие очень даже жесткое.Cnfhbr писал(а):ИМХО: Позвольте не согласиться. В данном контексте, нет такого "стандарта" жёсткого соответствия между HEX ID типов в "польском" и GRMN_TYPE в MPC. Этот "стандарт" придумал разработчик польского формата для компиляции в открытый формат Garmin, так что сам Garmin тут ни при чём. Подробности в личке...DarkDiver писал(а):Опять вы за староеСколько раз говорил - нельзя делать произвольные соответствия между HEX ID и GRMN_TYPE.
...
Соответствие между HEX ID и GRMN_TYPE - это разработанный Garmin стандарт, и он должен при экспорте жестко соблюдаться.
Разработчик польского ни чего не придумывал - придумал Garmin, а Стэн просто эти соответствия выяснил. Если бы он придумал все сам, маловероятно что назначение типов полностью совпало бы с MPC.
Открой потроха исполняемого файла MPC и MapCreate.dll (благо они не запротекчены) или прошивку любого девайса - какое там вообще соответствие с "польскими" hex-кодами? Кстати, кодировка ряда типов в прошивках различных приборов тоже может отличаться, поэтому разные модели могут отображать эти объекты по-разному...
Просто мы идентифицируем GRMN_TYPE где - в GME, ну и в TYPViewer'е, которые разработаны людьми, не имеющими отношения к Garmin и даже друг к другу, поэтому и показания в мапедите и в тип-вьювере могут отличаться, особенно для морских, кастомных и свежих типов.
Я вовсе не против строгого соответствия, которого мы пытаемся добиться в классификаторе Garmin! Я лишь предлагал, как устранить варнинги в логе MPC и игнорирование при компиляции несвойственных типов объектов: либо вообще не посылать на вход MPC не сопоставленные с GRMN_TYPE "польские" типы, либо предварительно сопоставить их с близкими по смыслу стандартными GRMN_TYPE, либо ассоциировать с CUSTOMIZABLE типами. Чего их солить то эти кастомные? Речь ведь о паре-тройке неопознанных в логе объектов каждой категории, заметьте, не требующих роутинга, поиска, глубины, цвета маяка и прочей хрени (всё основное у нас, слава богу, приведено в порядок). Так, если картописатель по каким-то личным мотивам захотел оставить "левый" тип в своём "полише", почему бы ему не воспользоваться кастомным от Garmin, даже если их мнимые(ИМХО) hex id не совпадают? Может ему нужно, чтобы этот объект просто присутствовал на карте без всяких там прибамбасов...
Ничего подобного, наоборот, являюсь ярым противником того, чтобы лезть в стандартные GRMN_TYPE (думаю, что мои коллеги по казахскому форуму это подтвердят). А в переписке с разрабом TYPViewer я всего лишь спрашивал, по какой системе он строит ассоциации своих hex-кодов с текстовыми GRMN_TYPE, поскольку я не могу изменить что-либо в стандартных типах MPC так, чтобы они вылетели в TYP файл, где можно было бы увидеть недостающие в классификаторе к MGE коды...DarkDiver писал(а):То о чем написал в личке - это использование стандартных типов для нестандартных целей, путем переопределения описания и иконки в тип-файле, так делать можно, хотя такой подход и крив, но ни какого отношения к реально существующему жесткому соотвествию между GRMN_TYPE и HEX ID это не имеет.
Ну, не так уж утрировано. Возможно, я привёл не характерные для однозначного понимания фрагменты переписки, там была длительная и нудная баталия, сорри...DarkDiver писал(а):Мишель тебе написал (как я понял), что использовать например тип RESTAURANT_AMERICAN 0x2a01 для обозначения ресторанов с американской кухней - это всего лишь рекомендация и можно использовать этот тип для чего угодно, переопределив в тип-файле, с этим я согласен, хотя и считаю что так делать не стоит. А вот соответствие между RESTAURANT_AMERICAN и 0x2a01 - жесткое, оно жестко зашито в компилятор и для изменения со стороны пользователя не доступно - и это, я считаю, разработанный Гармином стандарт.