Technology. Security. Development. Future.
https://forum.micro-gis.com:443/
Да изучил, внимательней некуда.DarkDiver писал(а):Все эти данные есть в моей таблице, на которую я уже не раз ссылался, настоятельно рекомендую все-таки изучить ее внимательно.
Так в этом то и есть проблема. В наборе типов (классификаторе) нельзя иметь два и более одинаковых HEX идентификатора. Тоесть полигон с типом 0x48 (к примеру) должен быть только один. Соответственно типу 0x48 должен быть сопоставлен только один идентификатор MPC. То есть при экспорте в шейп, вместо типа 0x48, мы запишем в таблицу RIVER_100FT.DarkDiver писал(а):И обратите внимание, что в МПЦ один и тот же шестнадцатиричный идентификатор иногда соответствует нескольким строковым константам.
Вот я про этого и говорю. Что вы экспериментировали с какой-то сторонней программой и были заложником того, как это придумал програмист. Тоесть вы высказываетесь, что у вас получалось, при компиляции чемто. То есть то, как это сделала какая то программа. Отбросим эти программы в сторону.DarkDiver писал(а):Данные в этой таблице я придумал не сам, в ней отображено реальное соответствие типов получаемое при компиляции карты в МПЦ (т.е. все данные получены мной экспериментально).
И что тут выяснять? Нет таких HEX идентификаторов. HEX идентификаторы мы берем из cGpsMapper. А в cGpsMapper таких типов нет. Соответственно и нет идентификатора.DarkDiver писал(а):Для точек ADDR_PNT, ARRV_PNT, необходимо выяснить какие именно идентификаторы назначаются при компиляции на самом деле, а не назначать их произвольно.
Назвать можно. Принимается. Выбрасывать не будем. Как я уже писал, чтобы не потерять совместимость ну и еще по одной причине. Ну раз 0x0 не воспринимается cGpsMapper, то тожно эту полилинию соотнести с DRIVEWAY в MPC. Посуди сам. Типа 0x0 в cGpsMapper - нет. Стало быть для cGpsMapper - значение 0x0 - свободно. Также в cGpsMapper - нет типа DRIVEWAY. Вот и пусть 0x0 будет DRIVEWAY.DarkDiver писал(а):Полилиния 0x0 не воспринимается cGPSMapper-ом, данный тип отсутствует в МПЦ, данный тип не является роутинговым в Garmin, и назван дорогой этот тип был очень давно по какой-то ошибке, вероятно из-за слабой изученности формата. Пора эту ошибку иправить - предлагаю назвать его Unknown, как и нулевые типы точек и полигонов.
Согласен. Исправил.DarkDiver писал(а):Еще ошибки:
0x2c08 ARENA
0x2c09 HALL
0x1f00 в cGpsMapper является не задействованным. Можно его обозначить для MPC как COUNTRY. Сделано.DarkDiver писал(а):И еще:
0x1f00 COUNTY
Почему так, а не наоборот? Ведь в cGpsMapper сказано, что 0x14, 0x15, 0x16 - National park. А 0x1e, 0x1f - State park.DarkDiver писал(а):0x14 NATIONAL_PARK_MAJOR
0x16 NATIONAL_PARK_OTHER
0x1e STATE_PARK_MAJOR
0x20 STATE_PARK_OTHER
Дублирование некоторых hex-кодов в таблице от DarkDiver произошло не случайно, дело в том, что если, к примеру, на вход МРС подать шейп с именем полигона LAKE или LAKE_5MI, то результат на выходе МРС после компиляции будет один и тот же, а именно LAKE_5MI, что будет соответствовать коду - 0x3f.Alex писал(а):Так в этом то и есть проблема. В наборе типов (классификаторе) нельзя иметь два и более одинаковых HEX идентификатора. Тоесть полигон с типом 0x48 (к примеру) должен быть только один. Соответственно типу 0x48 должен быть сопоставлен только один идентификатор MPC. То есть при экспорте в шейп, вместо типа 0x48, мы запишем в таблицу RIVER_100FT.DarkDiver писал(а):И обратите внимание, что в МПЦ один и тот же шестнадцатиричный идентификатор иногда соответствует нескольким строковым константам.
Можно объединять полигоны в один тип:
К примеру в 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.
Насколько я понимаю, DarkDiver компилировал не чем-то, а именно МРС, классификатор для которого мы нынче обсуждаем, и далее идентифицировал его аналоговые типы, просматривая их в GPSMapEdit, что соответствует идентификации в cGPSmapper. Поэтому, как отбрасывать эти программы в сторону? Полагаю, надо искать компромиссы...Alex писал(а):Вот я про этого и говорю. Что вы экспериментировали с какой-то сторонней программой и были заложником того, как это придумал програмист. Тоесть вы высказываетесь, что у вас получалось, при компиляции чемто. То есть то, как это сделала какая то программа. Отбросим эти программы в сторону.DarkDiver писал(а):Данные в этой таблице я придумал не сам, в ней отображено реальное соответствие типов получаемое при компиляции карты в МПЦ (т.е. все данные получены мной экспериментально).
Теперь у вас есть шанс - сделать всё правильно и самому назначить соответствия. Делаем как должно быть.
Эти точки адресного поиска действительно нечем проидентифицировать. Может, не заморачиваться с ними, а получать их в процессе экспорта в шейпы, например, как предлагает Vovan_Alm здесь:Alex писал(а):И что тут выяснять? Нет таких HEX идентификаторов. HEX идентификаторы мы берем из cGpsMapper. А в cGpsMapper таких типов нет. Соответственно и нет идентификатора.DarkDiver писал(а):Для точек ADDR_PNT, ARRV_PNT, необходимо выяснить какие именно идентификаторы назначаются при компиляции на самом деле, а не назначать их произвольно.
Для 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А было бы замечательно. Если кто то хранит в лейбле полигона адресные данные, значит он делает карты только для Гармина, и если у редактора будет механизм сделать из этого адресную точку - было бы тоже замечательно, но естественно адресные точки обязаны так же брать адресные данные из адресных данных полигона.
В отношении типа DRIVEWAY см. выше парные типы МРС.Alex писал(а):Назвать можно. Принимается. Выбрасывать не будем. Как я уже писал, чтобы не потерять совместимость ну и еще по одной причине. Ну раз 0x0 не воспринимается cGpsMapper, то тожно эту полилинию соотнести с DRIVEWAY в MPC. Посуди сам. Типа 0x0 в cGpsMapper - нет. Стало быть для cGpsMapper - значение 0x0 - свободно. Также в cGpsMapper - нет типа DRIVEWAY. Вот и пусть 0x0 будет DRIVEWAY.DarkDiver писал(а):Полилиния 0x0 не воспринимается cGPSMapper-ом, данный тип отсутствует в МПЦ, данный тип не является роутинговым в Garmin, и назван дорогой этот тип был очень давно по какой-то ошибке, вероятно из-за слабой изученности формата. Пора эту ошибку иправить - предлагаю назвать его Unknown, как и нулевые типы точек и полигонов.
Получится, что данный тип, только для MPC пользователей. Как такой вариант?
В отношении типа PROVINCE см. выше парные типы МРС.Alex писал(а):0x1f00 в cGpsMapper является не задействованным. Можно его обозначить для MPC как COUNTRY. Сделано.DarkDiver писал(а):И еще:
0x1f00 COUNTY
Тогда вопрос, какому типу, сопоставить MPC тип - PROVINCE?
Именно так (как у DarkDiver) эти типы после компиляции в МРС идентифицируются с hex-кодами в GPSMapEdit, просто Стан в доке к cGPSmapper не заморачивался с их подробным описанием...Alex писал(а):Почему так, а не наоборот? Ведь в cGpsMapper сказано, что 0x14, 0x15, 0x16 - National park. А 0x1e, 0x1f - State park.DarkDiver писал(а):0x14 NATIONAL_PARK_MAJOR
0x16 NATIONAL_PARK_OTHER
0x1e STATE_PARK_MAJOR
0x20 STATE_PARK_OTHER
Я поменяю, нет проблем, но хотелось бы знать...
Когда я поднимал этот вопрос, я имел в виду Ваш классификатор для cGPSmapper, вот его фрагмент:Alex писал(а):- Полигоны 0x004e и 0x004f оставил как есть. Сверил с cGpsMapper - все сходится.
Всё же настаиваю, что у этих типов не морские атрибуты, а "эпроач":Alex писал(а):- Гольфовские типы - тоже добавил.
Дело в том что при компиляции в МПЦ и RIVER_100FT и SMALL_RIVER превратятся в полигон 0x48, поэтому при конвертации польского в шейп мы просто используем одно из этих текстовых названий, а второе не используем в принципе - вот и все.Alex писал(а):Да изучил, внимательней некуда.DarkDiver писал(а):Все эти данные есть в моей таблице, на которую я уже не раз ссылался, настоятельно рекомендую все-таки изучить ее внимательно.Так в этом то и есть проблема. В наборе типов (классификаторе) нельзя иметь два и более одинаковых HEX идентификатора. Тоесть полигон с типом 0x48 (к примеру) должен быть только один. Соответственно типу 0x48 должен быть сопоставлен только один идентификатор MPC. То есть при экспорте в шейп, вместо типа 0x48, мы запишем в таблицу RIVER_100FT.DarkDiver писал(а):И обратите внимание, что в МПЦ один и тот же шестнадцатиричный идентификатор иногда соответствует нескольким строковым константам.
Можно объединять полигоны в один тип:
К примеру в 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.
Юзеру нет смысла использовать эти оба типа, потому как на самом деле это разные названия одного и того же типа, при конвертации в формат Garmin тип SMALL_RIVER превратится в 0x48, а не 0x55. Поэтому не надо создавать путаницу.Alex писал(а): Поэтому полигону SMALL_RIVER я и сопоставил свободный тип 0x55. Для того чтобы юзер, который создает карты под MPC имел возможность создать и SMALL_RIVER и RIVER_100FT.
Причем тут cGPSMapper. Все типы при компиляции карты в МПЦ получают определенные HEX ID. Вот их и надо выяснить, как я сделал для всех остальных типов, чтобы в польском были правильные ID, а не черт знает что, если сейчас cGPSMapper чего-то не поддерживает, это не значит, что не будет изменений в будущем или не появится другой компилятор. Если тип МПЦ при компиляции получает определенный HEX ID, то именно этот HEX ID должен быть в исходнике. Не надо устраивать не понятную кашу из типов в польском, надо делать сразу правильно.Alex писал(а):И что тут выяснять? Нет таких HEX идентификаторов. HEX идентификаторы мы берем из cGpsMapper. А в cGpsMapper таких типов нет. Соответственно и нет идентификатора.DarkDiver писал(а):Для точек ADDR_PNT, ARRV_PNT, необходимо выяснить какие именно идентификаторы назначаются при компиляции на самом деле, а не назначать их произвольно.
Но каждая строковая константа идентифицирующая типы в исходных шепах МПЦ при конвертации в формат гармин получает вполне определенный шестнадцатиричный идентификатор. Именно эти идентификаторы используются для всех типов в польском формате, и не надо делать исключений для ADDR_PNT, ARRV_PNT и каикх-либо других типов, потому как в этом случае будет не однозначный и не единообразный подход к обозначению типов.Alex писал(а): Для cGpsMapper - идентификатором является некое HEX значение
Для MPC - идентификатором является например LARGE_CITY, SMALL_CITY, GOLF_COURSE и т.д.
cGPSMapper эти типы поймет, вот только правильно работать они в карте не будут.Alex писал(а): А посему, мы при спокойно можем сопоставить ADDR_PNT, ARRV_PNT любое свободное значение HEX. При скармливании карты в cGpsMapper - он данные типы не поймет, так как он их не поддерживает.
Да, я не спорю, такой подход работоспособен, но крив.Alex писал(а): А при переводе в SHP значения HEX заменятся на ADDR_PNT, ARRV_PNT. Так что не вижу здесь проблем.
Плохой вариант. DRIVEWAY конвертируется в 0x7, так же как и ALLEY. 0x0 - нет такого типа ни в МПЦ ни в cGPSMapper.Alex писал(а):Назвать можно. Принимается. Выбрасывать не будем. Как я уже писал, чтобы не потерять совместимость ну и еще по одной причине. Ну раз 0x0 не воспринимается cGpsMapper, то тожно эту полилинию соотнести с DRIVEWAY в MPC. Посуди сам. Типа 0x0 в cGpsMapper - нет. Стало быть для cGpsMapper - значение 0x0 - свободно. Также в cGpsMapper - нет типа DRIVEWAY. Вот и пусть 0x0 будет DRIVEWAY.DarkDiver писал(а):Полилиния 0x0 не воспринимается cGPSMapper-ом, данный тип отсутствует в МПЦ, данный тип не является роутинговым в Garmin, и назван дорогой этот тип был очень давно по какой-то ошибке, вероятно из-за слабой изученности формата. Пора эту ошибку иправить - предлагаю назвать его Unknown, как и нулевые типы точек и полигонов.
Получится, что данный тип, только для MPC пользователей. Как такой вариант?
PROVINCE - 0x1e00Alex писал(а):0x1f00 в cGpsMapper является не задействованным. Можно его обозначить для MPC как COUNTRY. Сделано.DarkDiver писал(а):И еще:
0x1f00 COUNTY
Тогда вопрос, какому типу, сопоставить MPC тип - PROVINCE?
Потому что при компиляции в формат *.img, эти типы получают именно такие идентификаторы, а не наоборот.Alex писал(а):Почему так, а не наоборот? Ведь в cGpsMapper сказано, что 0x14, 0x15, 0x16 - National park. А 0x1e, 0x1f - State park.DarkDiver писал(а):0x14 NATIONAL_PARK_MAJOR
0x16 NATIONAL_PARK_OTHER
0x1e STATE_PARK_MAJOR
0x20 STATE_PARK_OTHER
Я поменяю, нет проблем, но хотелось бы знать....
Подразумевается, что тип 0x6100 используется для фиксирования адресных точек (если адреска не указана в полигонах домиков). Соответственно обрабатывается конструктором: попадает в адресный поиск при условии, что у объекта указана привязка к улице и соответсвующая улица есть в дорожной сети.
В отношении адресных точек ADDR_PNT и ARRV_PNT предлагаю ещё раз побеспокоить Станислава. Тем более, что Fencer_Silver недавно связывался с ним насчет полосности и, как подтвердилось, Стан не забросил своё детище. Вполне возможно, что он давно уже определился с этими адресными точками, поскольку работает над воплощением актуальных фич от Гармин, а мы тут копья ломаем...Исправил.DarkDiver писал(а):Полилиния 0x0 не воспринимается cGPSMapper-ом, данный тип отсутствует в МПЦ, данный тип не является роутинговым в Garmin, и назван дорогой этот тип был очень давно по какой-то ошибке, вероятно из-за слабой изученности формата. Пора эту ошибку иправить - предлагаю назвать его Unknown, как и нулевые типы точек и полигонов.
Исправил.DarkDiver писал(а):Еще ошибки:
0x2c08 ARENA
0x2c09 HALL
И еще:
0x1f00 COUNTY
Исправил.DarkDiver писал(а):0x14 NATIONAL_PARK_MAJOR
0x16 NATIONAL_PARK_OTHER
0x1e STATE_PARK_MAJOR
0x20 STATE_PARK_OTHER
Исправил.DarkDiver писал(а):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)
Исправил.DarkDiver писал(а):ALLEY / DRIVEWAY -> DRIVEWAY (0x07)
Исправил.DarkDiver писал(а):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"Cnfhbr писал(а):Всё же настаиваю, что у этих типов не морские атрибуты, а "эпроач"
Ну тогда еще чуток замечанийAlex писал(а): MicroGIS_New_TypSet_Garmin_v6 .rar [135.4 КБ]
Я скинул карту с адресными точками Cnfhbr, я надеюсь он разберется в ближайшее время с их идентификаторами. Подождем немного, потом вышлю Вам адресный шейп тоже...DarkDiver писал(а):Vovan_Alm, если Вы работаете с точками ADDR_PNT, ARRV_PNT, может подскажите их идентификаторы?
Или скиньте работоспособный шейп с этими точками (достаточно по одной точке каждого типа) - остальное я сам сделаю. Просто у меня сходу карта с этими точками не скомпилировалась, а разбираться почему это произошло - пока руки не дошли.
Выброшу их в конце.DarkDiver писал(а): Снова появились в таблице однобайтные кастомные полигоны.
Пока так и будет. Дабы не потерять совместимость. Подумаем, как с ней быть.DarkDiver писал(а):Линия 0х0 по-прежнему - дорога.
Исправлено.DarkDiver писал(а): Не прописаны 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.
Ну тогда у меня вроде бы больше нет замечанийAlex писал(а):Выброшу их в конце.DarkDiver писал(а): Снова появились в таблице однобайтные кастомные полигоны.Пока так и будет. Дабы не потерять совместимость. Подумаем, как с ней быть.DarkDiver писал(а):Линия 0х0 по-прежнему - дорога.Исправлено.DarkDiver писал(а): Не прописаны 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.
Никак новый классификатор типов на ногу упал?Alex писал(а):ууууууууууууу
Скрытый текст
Покопался, как смог, честно говоря, я вообще не уверен, что то, во что превращаются эти точки после компиляции, подпадает под разряд Points и имеет какой-то код.Vovan_Alm писал(а):Я скинул карту с адресными точками Cnfhbr, я надеюсь он разберется в ближайшее время с их идентификаторами. Подождем немного...DarkDiver писал(а):Vovan_Alm, если Вы работаете с точками ADDR_PNT, ARRV_PNT, может подскажите их идентификаторы?
Или скиньте работоспособный шейп с этими точками (достаточно по одной точке каждого типа) - остальное я сам сделаю. Просто у меня сходу карта с этими точками не скомпилировалась, а разбираться почему это произошло - пока руки не дошли.
