Alex писал(а):
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.
Поэтому полигону 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)
Таким образом, в классификаторе можно указать любое из парных аналоговых названий таких типов МРС - результат на выходе будет всё равно однозначный, соответствующий второму названию (которое после косого разделителя).
Alex писал(а):
DarkDiver писал(а):
Данные в этой таблице я придумал не сам, в ней отображено реальное соответствие типов получаемое при компиляции карты в МПЦ (т.е. все данные получены мной экспериментально).
Вот я про этого и говорю. Что вы экспериментировали с какой-то сторонней программой и были заложником того, как это придумал програмист. Тоесть вы высказываетесь, что у вас получалось, при компиляции чемто. То есть то, как это сделала какая то программа. Отбросим эти программы в сторону.
Теперь у вас есть шанс - сделать всё правильно и самому назначить соответствия. Делаем как должно быть.
Насколько я понимаю,
DarkDiver компилировал не чем-то, а именно МРС, классификатор для которого мы нынче обсуждаем, и далее идентифицировал его аналоговые типы, просматривая их в GPSMapEdit, что соответствует идентификации в cGPSmapper. Поэтому, как отбрасывать эти программы в сторону? Полагаю, надо искать компромиссы...
Alex писал(а):
DarkDiver писал(а):
Для точек 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 здесь:
Vovan_Alm писал(а):
Теперь о хранении данных в польском формате. В связи с тем, что мы выпускаем карту по 3-4 платформы, мы храним данные в полигонах домов. Понятно, что Гармин их не использует, потому скрипт Василия делает из них адресные точки и точки подьезда (если такие имеются, притом понимаются точки подъезда Навитела). Но если на карте ткнуть в полигон дома, то будет показано максимум что есть в Лейбле этого полигона. Потому иметь бы утилиту или механизм перенести в лейб дома 5-Я ЯКОВЛЕВСКАЯ УЛ., Д.1А было бы замечательно. Если кто то хранит в лейбле полигона адресные данные, значит он делает карты только для Гармина, и если у редактора будет механизм сделать из этого адресную точку - было бы тоже замечательно, но естественно адресные точки обязаны так же брать адресные данные из адресных данных полигона.
Alex писал(а):
DarkDiver писал(а):
Полилиния 0x0 не воспринимается cGPSMapper-ом, данный тип отсутствует в МПЦ, данный тип не является роутинговым в Garmin, и назван дорогой этот тип был очень давно по какой-то ошибке, вероятно из-за слабой изученности формата. Пора эту ошибку иправить - предлагаю назвать его Unknown, как и нулевые типы точек и полигонов.
Назвать можно. Принимается. Выбрасывать не будем. Как я уже писал, чтобы не потерять совместимость ну и еще по одной причине. Ну раз 0x0 не воспринимается cGpsMapper, то тожно эту полилинию соотнести с DRIVEWAY в MPC. Посуди сам. Типа 0x0 в cGpsMapper - нет. Стало быть для cGpsMapper - значение 0x0 - свободно. Также в cGpsMapper - нет типа DRIVEWAY. Вот и пусть 0x0 будет DRIVEWAY.
Получится, что данный тип, только для MPC пользователей. Как такой вариант?
В отношении типа DRIVEWAY см. выше парные типы МРС.
Alex писал(а):
DarkDiver писал(а):
И еще:
0x1f00 COUNTY
0x1f00 в cGpsMapper является не задействованным. Можно его обозначить для MPC как COUNTRY. Сделано.
Тогда вопрос, какому типу, сопоставить MPC тип - PROVINCE?
В отношении типа PROVINCE см. выше парные типы МРС.
Alex писал(а):
DarkDiver писал(а):
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 не заморачивался с их подробным описанием...
Alex писал(а):
- Полигоны 0x004e и 0x004f оставил как есть. Сверил с cGpsMapper - все сходится.
Когда я поднимал этот вопрос, я имел в виду Ваш классификатор для cGPSmapper, вот его фрагмент:
Вложение:
cGPSmapper_Alex_v2.jpg [ 15.69 КБ | Просмотров: 18394 ]
А вот как в доке к cGPSmapper:
Вложение:
cGPSmapper_help.jpg [ 22.6 КБ | Просмотров: 18394 ]
Alex писал(а):
- Гольфовские типы - тоже добавил.
Всё же настаиваю, что у этих типов не морские атрибуты, а "эпроач":
See atributes ->
Approach Attributes (см. раздел 'Approach Overview' в хелпе к МРС)
Вход
Регистрация
FAQ
Поиск
