Хотелки, пожелания, предложения для TypeSet=Garmin

[DarkDiver]

Полилиния 0x0 не воспринимается cGPSMapper-ом, данный тип отсутствует в МПЦ, данный тип не является роутинговым в Garmin, и назван дорогой этот тип был очень давно по какой-то ошибке, вероятно из-за слабой изученности формата. Пора эту ошибку иправить - предлагаю назвать его Unknown, как и нулевые типы точек и полигонов.

[DarkDiver]

Еще ошибки:
0x2c08 ARENA
0x2c09 HALL
У Вас наоборот.
И еще:
0x1f00 COUNTY

[Alex]

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

Да изучил, внимательней некуда.

И обратите внимание, что в МПЦ один и тот же шестнадцатиричный идентификатор иногда соответствует нескольким строковым константам.

Так в этом то и есть проблема. В наборе типов (классификаторе) нельзя иметь два и более одинаковых HEX идентификатора. Тоесть полигон с типом 0x48 (к примеру) должен быть только один. Соответственно типу 0x48 должен быть сопоставлен только один идентификатор MPC. То есть при экспорте в шейп, вместо типа 0x48, мы запишем в таблицу RIVER_100FT.

Можно объединять полигоны в один тип:
К примеру в cGpsMapper мы имеем 3 типа 0x29, 0x3b, 0x45 --- Blue-Unknown, в таблице соответствий мы можем прописать, что это всё, к примеру LAKE (для MPC). Тогда при экспорте в SHP - 3 типа объединятся в один - LAKE.

Но то что вы предлагаете в вашей таблице (GarminTypesTableFull-v05.xls), а именно:
полигон 0x48 = RIVER_100FT
полигон 0x48 = SMALL_RIVER
такого быть не может. Так как в карте мы создали полигон и назначили ему тип 0x48, больше в этом объекте никаких классификаторов не записывается. При перегоне карты в SHP, я должен этому типу сопоставить MPC тип, а это может быть или RIVER_100FT, или SMALL_RIVER.

Поэтому полигону SMALL_RIVER я и сопоставил свободный тип 0x55. Для того чтобы юзер, который создает карты под MPC имел возможность создать и SMALL_RIVER и RIVER_100FT.

Данные в этой таблице я придумал не сам, в ней отображено реальное соответствие типов получаемое при компиляции карты в МПЦ (т.е. все данные получены мной экспериментально).

Вот я про этого и говорю. Что вы экспериментировали с какой-то сторонней программой и были заложником того, как это придумал програмист. Тоесть вы высказываетесь, что у вас получалось, при компиляции чемто. То есть то, как это сделала какая то программа. Отбросим эти программы в сторону.
Теперь у вас есть шанс - сделать всё правильно и самому назначить соответствия. Делаем как должно быть.

Для точек ADDR_PNT, ARRV_PNT, необходимо выяснить какие именно идентификаторы назначаются при компиляции на самом деле, а не назначать их произвольно.

И что тут выяснять? Нет таких HEX идентификаторов. HEX идентификаторы мы берем из cGpsMapper. А в cGpsMapper таких типов нет. Соответственно и нет идентификатора.

Для cGpsMapper - идентификатором является некое HEX значение
Для MPC - идентификатором является например LARGE_CITY, SMALL_CITY, GOLF_COURSE и т.д.

А посему, мы при спокойно можем сопоставить ADDR_PNT, ARRV_PNT любое свободное значение HEX. При скармливании карты в cGpsMapper - он данные типы не поймет, так как он их не поддерживает.
А при переводе в SHP значения HEX заменятся на ADDR_PNT, ARRV_PNT. Так что не вижу здесь проблем.

Полилиния 0x0 не воспринимается cGPSMapper-ом, данный тип отсутствует в МПЦ, данный тип не является роутинговым в Garmin, и назван дорогой этот тип был очень давно по какой-то ошибке, вероятно из-за слабой изученности формата. Пора эту ошибку иправить - предлагаю назвать его Unknown, как и нулевые типы точек и полигонов.

Назвать можно. Принимается. Выбрасывать не будем. Как я уже писал, чтобы не потерять совместимость ну и еще по одной причине. Ну раз 0x0 не воспринимается cGpsMapper, то тожно эту полилинию соотнести с DRIVEWAY в MPC. Посуди сам. Типа 0x0 в cGpsMapper - нет. Стало быть для cGpsMapper - значение 0x0 - свободно. Также в cGpsMapper - нет типа DRIVEWAY. Вот и пусть 0x0 будет DRIVEWAY.
Получится, что данный тип, только для MPC пользователей. Как такой вариант?

Еще ошибки:
0x2c08 ARENA
0x2c09 HALL

Согласен. Исправил.

И еще:
0x1f00 COUNTY

0x1f00 в cGpsMapper является не задействованным. Можно его обозначить для MPC как COUNTRY. Сделано.
Тогда вопрос, какому типу, сопоставить MPC тип - PROVINCE?

0x14 NATIONAL_PARK_MAJOR
0x16 NATIONAL_PARK_OTHER
0x1e STATE_PARK_MAJOR
0x20 STATE_PARK_OTHER

Почему так, а не наоборот? Ведь в cGpsMapper сказано, что 0x14, 0x15, 0x16 - National park. А 0x1e, 0x1f - State park.
Я поменяю, нет проблем, но хотелось бы знать....

Прошу не воспринимать, высказанное выше как упрек или еще както. Это нормальный, рабочий процесс. Прежде чем это всё реализовывать, должно выполнится как минимум ряд условий:
- Мы должны убедиться, что это на 100% правильно и будет работать.
- Всё что мы делаем, должно опираться на документацию.
- После расширения классификатора, пользователь может без труда воспользоваться любым компилятором, буть то cGpsMapper или MPC. Правда для MPC компилятора, еще нужен экспорт в SHP. Но это уже другой вопрос. Сначала нужно разобраться с классификатором и атрибутикой объектов.
- Это нужно и будет востребовано, не только определенным кругом пользователей, но и для любого пользователя.

Продолжаем обсуждение. Где я не прав?

[Cnfhbr]

И обратите внимание, что в МПЦ один и тот же шестнадцатиричный идентификатор иногда соответствует нескольким строковым константам.

Так в этом то и есть проблема. В наборе типов (классификаторе) нельзя иметь два и более одинаковых HEX идентификатора. Тоесть полигон с типом 0x48 (к примеру) должен быть только один. Соответственно типу 0x48 должен быть сопоставлен только один идентификатор MPC. То есть при экспорте в шейп, вместо типа 0x48, мы запишем в таблицу RIVER_100FT.

Можно объединять полигоны в один тип:
К примеру в cGpsMapper мы имеем 3 типа 0x29, 0x3b, 0x45 --- Blue-Unknown, в таблице соответствий мы можем прописать, что это всё, к примеру LAKE (для MPC). Тогда при экспорте в SHP - 3 типа объединятся в один - LAKE.

Но то что вы предлагаете в вашей таблице (GarminTypesTableFull-v05.xls), а именно:
полигон 0x48 = RIVER_100FT
полигон 0x48 = SMALL_RIVER
такого быть не может. Так как в карте мы создали полигон и назначили ему тип 0x48, больше в этом объекте никаких классификаторов не записывается. При перегоне карты в SHP, я должен этому типу сопоставить MPC тип, а это может быть или RIVER_100FT, или SMALL_RIVER.

Поэтому полигону SMALL_RIVER я и сопоставил свободный тип 0x55. Для того чтобы юзер, который создает карты под MPC имел возможность создать и SMALL_RIVER и RIVER_100FT.

Дублирование некоторых hex-кодов в таблице от DarkDiver произошло не случайно, дело в том, что если, к примеру, на вход МРС подать шейп с именем полигона LAKE или LAKE_5MI, то результат на выходе МРС после компиляции будет один и тот же, а именно LAKE_5MI, что будет соответствовать коду - 0x3f.
Такие двоякие типы в МРС прописаны в диалоговом окне 'Edit Feature Display Properties' следующим образом:
Garmin Areas:
LAKE / LAKE_5MI -> LAKE_5MI (0x3f)
LAKE_30MI / LARGE_LAKE -> LARGE_LAKE (0x3d)
LAKE_GT_1000MI / MAJOR_LAKE -> MAJOR_LAKE (0x42)
LAKE_LT_1MI / SMALL_LAKE -> SMALL_LAKE (0x41)
RIVER_100FT / SMALL_RIVER -> SMALL_RIVER (0x48)
Garmin Roads:
ALLEY / DRIVEWAY -> DRIVEWAY (0x07)
HIGH_SPEED_RAMP / RAMP -> RAMP (0x09)
INTERSTATE / MAJOR_HWY -> MAJOR_HWY (0x01)
Garmin Points:
CITY_50K / MEDIUM_CITY -> MEDIUM_CITY (0x0800)
CITY_5M / LARGE_CITY -> LARGE_CITY (0x0200)
CITY_LT5K / SMALL_CITY -> SMALL_CITY (0x0c00)
GARDEN / PARK -> PARK (0x2c06)
PROVINCE / STATE -> STATE (0x1e00)

Таким образом, в классификаторе можно указать любое из парных аналоговых названий таких типов МРС - результат на выходе будет всё равно однозначный, соответствующий второму названию (которое после косого разделителя).

Данные в этой таблице я придумал не сам, в ней отображено реальное соответствие типов получаемое при компиляции карты в МПЦ (т.е. все данные получены мной экспериментально).

Вот я про этого и говорю. Что вы экспериментировали с какой-то сторонней программой и были заложником того, как это придумал програмист. Тоесть вы высказываетесь, что у вас получалось, при компиляции чемто. То есть то, как это сделала какая то программа. Отбросим эти программы в сторону.
Теперь у вас есть шанс - сделать всё правильно и самому назначить соответствия. Делаем как должно быть.

Насколько я понимаю, DarkDiver компилировал не чем-то, а именно МРС, классификатор для которого мы нынче обсуждаем, и далее идентифицировал его аналоговые типы, просматривая их в GPSMapEdit, что соответствует идентификации в cGPSmapper. Поэтому, как отбрасывать эти программы в сторону? Полагаю, надо искать компромиссы...

Для точек ADDR_PNT, ARRV_PNT, необходимо выяснить какие именно идентификаторы назначаются при компиляции на самом деле, а не назначать их произвольно.

И что тут выяснять? Нет таких HEX идентификаторов. HEX идентификаторы мы берем из cGpsMapper. А в cGpsMapper таких типов нет. Соответственно и нет идентификатора.

Для cGpsMapper - идентификатором является некое HEX значение
Для MPC - идентификатором является например LARGE_CITY, SMALL_CITY, GOLF_COURSE и т.д.

А посему, мы при спокойно можем сопоставить ADDR_PNT, ARRV_PNT любое свободное значение HEX. При скармливании карты в cGpsMapper - он данные типы не поймет, так как он их не поддерживает.
А при переводе в SHP значения HEX заменятся на ADDR_PNT, ARRV_PNT. Так что не вижу здесь проблем.

Эти точки адресного поиска действительно нечем проидентифицировать. Может, не заморачиваться с ними, а получать их в процессе экспорта в шейпы, например, как предлагает Vovan_Alm здесь:

Теперь о хранении данных в польском формате. В связи с тем, что мы выпускаем карту по 3-4 платформы, мы храним данные в полигонах домов. Понятно, что Гармин их не использует, потому скрипт Василия делает из них адресные точки и точки подьезда (если такие имеются, притом понимаются точки подъезда Навитела). Но если на карте ткнуть в полигон дома, то будет показано максимум что есть в Лейбле этого полигона. Потому иметь бы утилиту или механизм перенести в лейб дома 5-Я ЯКОВЛЕВСКАЯ УЛ., Д.1А было бы замечательно. Если кто то хранит в лейбле полигона адресные данные, значит он делает карты только для Гармина, и если у редактора будет механизм сделать из этого адресную точку - было бы тоже замечательно, но естественно адресные точки обязаны так же брать адресные данные из адресных данных полигона.

Полилиния 0x0 не воспринимается cGPSMapper-ом, данный тип отсутствует в МПЦ, данный тип не является роутинговым в Garmin, и назван дорогой этот тип был очень давно по какой-то ошибке, вероятно из-за слабой изученности формата. Пора эту ошибку иправить - предлагаю назвать его Unknown, как и нулевые типы точек и полигонов.

Назвать можно. Принимается. Выбрасывать не будем. Как я уже писал, чтобы не потерять совместимость ну и еще по одной причине. Ну раз 0x0 не воспринимается cGpsMapper, то тожно эту полилинию соотнести с DRIVEWAY в MPC. Посуди сам. Типа 0x0 в cGpsMapper - нет. Стало быть для cGpsMapper - значение 0x0 - свободно. Также в cGpsMapper - нет типа DRIVEWAY. Вот и пусть 0x0 будет DRIVEWAY.
Получится, что данный тип, только для MPC пользователей. Как такой вариант?

В отношении типа DRIVEWAY см. выше парные типы МРС.

И еще:
0x1f00 COUNTY

0x1f00 в cGpsMapper является не задействованным. Можно его обозначить для MPC как COUNTRY. Сделано.
Тогда вопрос, какому типу, сопоставить MPC тип - PROVINCE?

В отношении типа PROVINCE см. выше парные типы МРС.

0x14 NATIONAL_PARK_MAJOR
0x16 NATIONAL_PARK_OTHER
0x1e STATE_PARK_MAJOR
0x20 STATE_PARK_OTHER

Почему так, а не наоборот? Ведь в cGpsMapper сказано, что 0x14, 0x15, 0x16 - National park. А 0x1e, 0x1f - State park.
Я поменяю, нет проблем, но хотелось бы знать...

Именно так (как у DarkDiver) эти типы после компиляции в МРС идентифицируются с hex-кодами в GPSMapEdit, просто Стан в доке к cGPSmapper не заморачивался с их подробным описанием...

- Полигоны 0x004e и 0x004f оставил как есть. Сверил с cGpsMapper - все сходится.

Когда я поднимал этот вопрос, я имел в виду Ваш классификатор для cGPSmapper, вот его фрагмент:

А вот как в доке к cGPSmapper:

- Гольфовские типы - тоже добавил.

Всё же настаиваю, что у этих типов не морские атрибуты, а "эпроач":
See atributes -> Approach Attributes (см. раздел 'Approach Overview' в хелпе к МРС)

[DarkDiver]

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

Да изучил, внимательней некуда.

И обратите внимание, что в МПЦ один и тот же шестнадцатиричный идентификатор иногда соответствует нескольким строковым константам.

Так в этом то и есть проблема. В наборе типов (классификаторе) нельзя иметь два и более одинаковых HEX идентификатора. Тоесть полигон с типом 0x48 (к примеру) должен быть только один. Соответственно типу 0x48 должен быть сопоставлен только один идентификатор MPC. То есть при экспорте в шейп, вместо типа 0x48, мы запишем в таблицу RIVER_100FT.

Можно объединять полигоны в один тип:
К примеру в cGpsMapper мы имеем 3 типа 0x29, 0x3b, 0x45 --- Blue-Unknown, в таблице соответствий мы можем прописать, что это всё, к примеру LAKE (для MPC). Тогда при экспорте в SHP - 3 типа объединятся в один - LAKE.

Но то что вы предлагаете в вашей таблице (GarminTypesTableFull-v05.xls), а именно:
полигон 0x48 = RIVER_100FT
полигон 0x48 = SMALL_RIVER

такого быть не может. Так как в карте мы создали полигон и назначили ему тип 0x48, больше в этом объекте никаких классификаторов не записывается. При перегоне карты в SHP, я должен этому типу сопоставить MPC тип, а это может быть или RIVER_100FT, или SMALL_RIVER.

Дело в том что при компиляции в МПЦ и RIVER_100FT и SMALL_RIVER превратятся в полигон 0x48, поэтому при конвертации польского в шейп мы просто используем одно из этих текстовых названий, а второе не используем в принципе - вот и все.

Поэтому полигону SMALL_RIVER я и сопоставил свободный тип 0x55. Для того чтобы юзер, который создает карты под MPC имел возможность создать и SMALL_RIVER и RIVER_100FT.

Юзеру нет смысла использовать эти оба типа, потому как на самом деле это разные названия одного и того же типа, при конвертации в формат Garmin тип SMALL_RIVER превратится в 0x48, а не 0x55. Поэтому не надо создавать путаницу.

Для точек ADDR_PNT, ARRV_PNT, необходимо выяснить какие именно идентификаторы назначаются при компиляции на самом деле, а не назначать их произвольно.

И что тут выяснять? Нет таких HEX идентификаторов. HEX идентификаторы мы берем из cGpsMapper. А в cGpsMapper таких типов нет. Соответственно и нет идентификатора.

Причем тут cGPSMapper. Все типы при компиляции карты в МПЦ получают определенные HEX ID. Вот их и надо выяснить, как я сделал для всех остальных типов, чтобы в польском были правильные ID, а не черт знает что, если сейчас cGPSMapper чего-то не поддерживает, это не значит, что не будет изменений в будущем или не появится другой компилятор. Если тип МПЦ при компиляции получает определенный HEX ID, то именно этот HEX ID должен быть в исходнике. Не надо устраивать не понятную кашу из типов в польском, надо делать сразу правильно.

Для cGpsMapper - идентификатором является некое HEX значение
Для MPC - идентификатором является например LARGE_CITY, SMALL_CITY, GOLF_COURSE и т.д.

Но каждая строковая константа идентифицирующая типы в исходных шепах МПЦ при конвертации в формат гармин получает вполне определенный шестнадцатиричный идентификатор. Именно эти идентификаторы используются для всех типов в польском формате, и не надо делать исключений для ADDR_PNT, ARRV_PNT и каикх-либо других типов, потому как в этом случае будет не однозначный и не единообразный подход к обозначению типов.
Вторая проблема - для редактора и для итоговой карты придется использовать разные тип-файлы. Поскольку при Вашем подходе один и тот же тип будет иметь разные шестнадцатиричные идентификаторы в исходнике и в итоговой карте. А это согласитесь тоже криво, и вызовет путаницу.

А посему, мы при спокойно можем сопоставить ADDR_PNT, ARRV_PNT любое свободное значение HEX. При скармливании карты в cGpsMapper - он данные типы не поймет, так как он их не поддерживает.

cGPSMapper эти типы поймет, вот только правильно работать они в карте не будут.

А при переводе в SHP значения HEX заменятся на ADDR_PNT, ARRV_PNT. Так что не вижу здесь проблем.

Да, я не спорю, такой подход работоспособен, но крив.

Полилиния 0x0 не воспринимается cGPSMapper-ом, данный тип отсутствует в МПЦ, данный тип не является роутинговым в Garmin, и назван дорогой этот тип был очень давно по какой-то ошибке, вероятно из-за слабой изученности формата. Пора эту ошибку иправить - предлагаю назвать его Unknown, как и нулевые типы точек и полигонов.

Назвать можно. Принимается. Выбрасывать не будем. Как я уже писал, чтобы не потерять совместимость ну и еще по одной причине. Ну раз 0x0 не воспринимается cGpsMapper, то тожно эту полилинию соотнести с DRIVEWAY в MPC. Посуди сам. Типа 0x0 в cGpsMapper - нет. Стало быть для cGpsMapper - значение 0x0 - свободно. Также в cGpsMapper - нет типа DRIVEWAY. Вот и пусть 0x0 будет DRIVEWAY.
Получится, что данный тип, только для MPC пользователей. Как такой вариант?

Плохой вариант. DRIVEWAY конвертируется в 0x7, так же как и ALLEY. 0x0 - нет такого типа ни в МПЦ ни в cGPSMapper.
Не должны два РАЗНЫХ типа в польском превращаться в ОДИН тип после компиляции.
А произойдет именно так, при преобразовании *.mp -> *.shp -> *.img получим при вашем подходе:
0x0 -> DRIVEWAY -> 0x7
0x7 -> ALLEY -> 0x7

Согласитесь это криво?

А 0x7 при конвертации в шейры мы преобразуем, либо в DRIVEWAY либо в ALLEY.
Т.е. используем одно из названий, а второе не используем вообще.

И еще:
0x1f00 COUNTY

0x1f00 в cGpsMapper является не задействованным. Можно его обозначить для MPC как COUNTRY. Сделано.
Тогда вопрос, какому типу, сопоставить MPC тип - PROVINCE?

PROVINCE - 0x1e00

0x14 NATIONAL_PARK_MAJOR
0x16 NATIONAL_PARK_OTHER
0x1e STATE_PARK_MAJOR
0x20 STATE_PARK_OTHER

Почему так, а не наоборот? Ведь в cGpsMapper сказано, что 0x14, 0x15, 0x16 - National park. А 0x1e, 0x1f - State park.
Я поменяю, нет проблем, но хотелось бы знать....

Потому что при компиляции в формат *.img, эти типы получают именно такие идентификаторы, а не наоборот.

[Vovan_Alm]

Опять размышления об адресных точках ADDR_PNT, ARRV_PNT: большинство людей конечно не будут ставить их специально (за исключением "точки прибытия", и то в редких случаях), но это не значит что их не должно быть в редакторе. Может я карту делаю вообще без домов (полигонов домов), по стандартам самого Гармина. А дома буду задавать адресными точками. Такой вариант возможен, а значит его должен поддерживать редактор. Но и само-собой при создании адресного шейпа средствами редактора, должна быть возможность создавать адресную точку и точку прибытия (если не задано иначе, то обе точки совпадают) из адресных данных полигона или специально прописанной строке в лейбле полигона. (типа 5-Я ЯКОВЛЕВСКАЯ УЛ., Д.1А)

Ну и еще вариант... а может ADDR_PNT ассоциировать с Здание (0x6402, точка) или Дом (0x6100, точка)? Т.е Маппер создаст там значок дом, а МПС создаст адресную точку... Как вам идея?

Вроде как в Сити Гиде точка Дом (0x6100, точка) используется именно для фиксации адресной точки, при отсутствии полигона дома с адресными данными.
Информация от СГ

Подразумевается, что тип 0x6100 используется для фиксирования адресных точек (если адреска не указана в полигонах домиков). Соответственно обрабатывается конструктором: попадает в адресный поиск при условии, что у объекта указана привязка к улице и соответсвующая улица есть в дорожной сети.

[Cnfhbr]

В отношении адресных точек ADDR_PNT и ARRV_PNT предлагаю ещё раз побеспокоить Станислава. Тем более, что Fencer_Silver недавно связывался с ним насчет полосности и, как подтвердилось, Стан не забросил своё детище. Вполне возможно, что он давно уже определился с этими адресными точками, поскольку работает над воплощением актуальных фич от Гармин, а мы тут копья ломаем...

[Alex]

Полилиния 0x0 не воспринимается cGPSMapper-ом, данный тип отсутствует в МПЦ, данный тип не является роутинговым в Garmin, и назван дорогой этот тип был очень давно по какой-то ошибке, вероятно из-за слабой изученности формата. Пора эту ошибку иправить - предлагаю назвать его Unknown, как и нулевые типы точек и полигонов.

Исправил.

Еще ошибки:
0x2c08 ARENA
0x2c09 HALL
И еще:
0x1f00 COUNTY

Исправил.

0x14 NATIONAL_PARK_MAJOR
0x16 NATIONAL_PARK_OTHER
0x1e STATE_PARK_MAJOR
0x20 STATE_PARK_OTHER

Исправил.

LAKE / LAKE_5MI -> LAKE_5MI (0x3f)
LAKE_30MI / LARGE_LAKE -> LARGE_LAKE (0x3d)
LAKE_GT_1000MI / MAJOR_LAKE -> MAJOR_LAKE (0x42)
LAKE_LT_1MI / SMALL_LAKE -> SMALL_LAKE (0x41)
RIVER_100FT / SMALL_RIVER -> SMALL_RIVER (0x48)

Исправил.

ALLEY / DRIVEWAY -> DRIVEWAY (0x07)

Исправил.

CITY_50K / MEDIUM_CITY -> MEDIUM_CITY (0x0800)
CITY_5M / LARGE_CITY -> LARGE_CITY (0x0200)
CITY_LT5K / SMALL_CITY -> SMALL_CITY (0x0c00)
GARDEN / PARK -> PARK (0x2c06)
PROVINCE / STATE -> STATE (0x1e00)

Исправил.

Всё же настаиваю, что у этих типов не морские атрибуты, а "эпроач"

Не назначал я им морских атрибутов. Может смущает слово "See supported attributes"? Заменил на: "Approach Attributes"

ADDR_PNT, ARRV_PNT - оставил на месте, до выяснения НЕХ значений.

[DarkDiver]

Vovan_Alm, если Вы работаете с точками ADDR_PNT, ARRV_PNT, может подскажите их идентификаторы?
Или скиньте работоспособный шейп с этими точками (достаточно по одной точке каждого типа) - остальное я сам сделаю. Просто у меня сходу карта с этими точками не скомпилировалась, а разбираться почему это произошло - пока руки не дошли.

[DarkDiver]

MicroGIS_New_TypSet_Garmin_v6 .rar [135.4 КБ]

Ну тогда еще чуток замечаний
Снова появились в таблице однобайтные кастомные полигоны.
Линия 0х0 по-прежнему - дорога.
Не прописаны HEX ID для кастомных типов: CUSTOMIZABLE_AREA_65 по CUSTOMIZABLE_AREA_1024
Не верно прописаны HEX ID для кастомных линий: CUSTOMIZABLE_LINE_65 по CUSTOMIZABLE_LINE_106
Не прописаны HEX ID для кастомных типов: CUSTOMIZABLE_LINE_107 по CUSTOMIZABLE_LINE_1024
Не прописаны HEX ID для кастомных типов: CUSTOMIZABLE_POINT_65 по CUSTOMIZABLE_POINT_1023
Не верно прописан HEX ID для CUSTOMIZABLE_POINT_1024

Правильные значения см. в откорректированном мною ранее варианте.

[Vovan_Alm]

Vovan_Alm, если Вы работаете с точками ADDR_PNT, ARRV_PNT, может подскажите их идентификаторы?
Или скиньте работоспособный шейп с этими точками (достаточно по одной точке каждого типа) - остальное я сам сделаю. Просто у меня сходу карта с этими точками не скомпилировалась, а разбираться почему это произошло - пока руки не дошли.

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

[Alex]

Снова появились в таблице однобайтные кастомные полигоны.

Выброшу их в конце.

Линия 0х0 по-прежнему - дорога.

Пока так и будет. Дабы не потерять совместимость. Подумаем, как с ней быть.

Не прописаны HEX ID для кастомных типов: CUSTOMIZABLE_AREA_65 по CUSTOMIZABLE_AREA_1024
Не верно прописаны HEX ID для кастомных линий: CUSTOMIZABLE_LINE_65 по CUSTOMIZABLE_LINE_106
Не прописаны HEX ID для кастомных типов: CUSTOMIZABLE_LINE_107 по CUSTOMIZABLE_LINE_1024
Не прописаны HEX ID для кастомных типов: CUSTOMIZABLE_POINT_65 по CUSTOMIZABLE_POINT_1023
Не верно прописан HEX ID для CUSTOMIZABLE_POINT_1024.

Исправлено.

[DarkDiver]

Снова появились в таблице однобайтные кастомные полигоны.

Выброшу их в конце.

Линия 0х0 по-прежнему - дорога.

Пока так и будет. Дабы не потерять совместимость. Подумаем, как с ней быть.

Не прописаны HEX ID для кастомных типов: CUSTOMIZABLE_AREA_65 по CUSTOMIZABLE_AREA_1024
Не верно прописаны HEX ID для кастомных линий: CUSTOMIZABLE_LINE_65 по CUSTOMIZABLE_LINE_106
Не прописаны HEX ID для кастомных типов: CUSTOMIZABLE_LINE_107 по CUSTOMIZABLE_LINE_1024
Не прописаны HEX ID для кастомных типов: CUSTOMIZABLE_POINT_65 по CUSTOMIZABLE_POINT_1023
Не верно прописан HEX ID для CUSTOMIZABLE_POINT_1024.

Исправлено.

Ну тогда у меня вроде бы больше нет замечаний

ууууууууууууу
Скрытый текст

Никак новый классификатор типов на ногу упал?

[Cnfhbr]

Vovan_Alm, если Вы работаете с точками ADDR_PNT, ARRV_PNT, может подскажите их идентификаторы?
Или скиньте работоспособный шейп с этими точками (достаточно по одной точке каждого типа) - остальное я сам сделаю. Просто у меня сходу карта с этими точками не скомпилировалась, а разбираться почему это произошло - пока руки не дошли.

Я скинул карту с адресными точками Cnfhbr, я надеюсь он разберется в ближайшее время с их идентификаторами. Подождем немного...

Покопался, как смог, честно говоря, я вообще не уверен, что то, во что превращаются эти точки после компиляции, подпадает под разряд Points и имеет какой-то код.
Подождём резюме от DarkDiver, необходимый для исследования материал у него сейчас имеется...
По ходу, дабы развеять сомнения, я бы всё-таки к Станиславу стукнулся по этим 2-м точкам. Fencer_Silver, Вы ведь недавно общались с ним в отношении полосности, может, спросите у него и про адресные точки до кучи

[Alex]

Да отписали ему, но...... Ответа нет, ни на это письмо, ни на предидущее..... Ждемс.........