Cnfhbr писал(а):Не надо передёргивать и искажать смысл мною сказанного. Если где-то я и применяю упрощённую терминологию, это не повод тут же цепляться и пытаться лечить.
Абсолютно ни чего не искажал ты просто сам себе противоречишь, сначала пишешь:
Cnfhbr писал(а): В данном контексте, нет такого "стандарта" жёсткого соответствия между HEX ID типов в "польском" и GRMN_TYPE в MPC
и
Cnfhbr писал(а):Открой потроха исполняемого файла MPC и MapCreate.dll (благо они не запротекчены) или прошивку любого девайса - какое там вообще соответствие с "польскими" hex-кодами?
а затем наоборот:
Cnfhbr писал(а): ЖЁСТКОЕ соответствие этих кодов текстовым GRMN_TYPE только в самОм MPC!
Что касается прошивок, то в отдельных моделях приборов некоторые POI, например, не только отображаются по-разному, но и трактуются софтом не одинаково, попадая совсем в другие, порой неадекватные, категории (не путать с багами прошивок).
Ну вот и я говорю что соотвествие жесткое, о чем мы тогда спорим?
То что там отдельно взятыми приборами что-то там по разному трактуется, категоризируется и отображается - вообще к сути вопроса отношения не имеет, подобных заморочек у конкретных моделей я встречал не мало.
Важно следующее в MPC есть жесткая таблица преобразования GRMN_TYPE -> HEX ID при конвертации из шейпов в *.img. Дополнительно к этому я утверждаю что при экспоте из польского в шейпы, перобразование HEX ID -> GRMN_TYPE должно выполняться в точно таком же соответствии по этой же таблице! Т.е. один и тот же объект не должен иметь в исходнике один HEX ID, а в итоговой карте - другой.
Cnfhbr писал(а):
Опять же имелись в виду типы не из несопоставимых HEX-диапазонов, а отдельные типы маппера, которые не поддерживает MPC, именно они лезут в варнинги MPC при общем для двух инструментов классификаторе.
Да, я понял, но это и есть несопоставимые типы - те которые не поддерживает MPC. И какой из этих типов какому поддерживаемому в МПЦ сопоставить - задача для картографа на этапе предварительной подготовки исходника, до экспорта в шейпы. Поскольку, как я уже говорил, один и тот же объект не должен иметь в исходнике один HEX ID, а в итоговой карте - другой.
Cnfhbr писал(а):
DarkDiver писал(а):Автор TYPViewer вообще не строит никаких ассоциаций hex-кодов с текстовыми GRMN_TYPE, поскольку GRMN_TYPE - это заморочка MPC и в TYPViewer вообще ни как не фигурирует.
Не стоит так категорично утверждать то, чего пока не знаешь. В инструменте TYPViewer - да, GRMN_TYPE никах не фигурирует,
Я и имел ввиду, что ассоциаций автор не строит в контексте программы TYPViewer. То что он мог эти соответствия выяснять для каких то других целей - это, разумеется, понятно...
Cnfhbr писал(а):P.S. Предлагаю закончить эту бестолковую перепалку и заняться полезным делом, например, вычистить всё тот же классификатор от уже замеченных ошибок и неточностей...
Просто вопрос то принципиальный, зачем мы так долго вычищали классификатор, если на этапе экспорта ты предлагаешь его не придерживаться, да еще и стал утверждать что HEX ID c GRMN_TYPE ни как не связаны, что меня удивило больше всего...
В споре я иногда бываю резок в формулировании своих мыслей, прошу не обижаться... искажать/передергивать твои слова, придираться к формулировкам своей целью абсолютно не ставил...
Добавлено спустя 4 минуты 35 секунд:
Alex писал(а):как ключ не надо. Данные берутся из лейбла. А футы это или метры - берутся из установок карты.
Для морских типов должно храниться в отдельном ключе: Depth=##.# или Height=##.# - без разницы.
А не браться из лейбла. В лейбле при этом, можно другую полезную информацию прописать.
Уж не для того ли, чтобы можно было ограничивать по высоте габариты проезжаемых транспортных средств, что несомненно отразится на роутинге для этих ТС?
Поэтому MapSource и BaserCamp мне не чужды и я ими пользуюсь на компьютере: быстро что-то найти в поиске, проложить маршрут, обменяться с навигатором инфой, посмотреть качество TYP-файла и внешнего оформления.