MicroGIS™ DevCon

Если в групповой изменить тип (через ...) на тип, которого нет в карте, то колонка тип становится пустой.

MicroGIS Editor обновление v1.0.10.518b

Баг в MicroGIS Editor 1.0.10.518b

Alex писал(а): - Добавлено: атрибут Высота/Глубина - для:
POI: категории "Points with Height", "Points with Depth", "Isolated Dangers"
Полилинии: типы 0x10105, 0x10106, 0x10301, 0x10302, 0x10303, 0x10304, 0x10305, 0x10306, 0x10107
Полигоны: типы 0x10105, 0x10302, 0x10303, 0x10304 , 0x10305 , 0x10306
В файл MP записывается с ключом "Depth = ##.#"

Нарисовал для примера полигон 0x10105 (мост), выставил высоту 5 метров. Сохранил изменения в карте.

Затем поменял тип этого полигона на 0x000A (территория университета). Сохранил изменения в карте.

А в свойствах нового объекта сохранился старый параметр Depth=5.0. И он никуда не пропадает при перемене типов с последующей записью изменений в файл!

Не подтверждается. Проверил. Если ты о записи ключей в исходник - это одно. Если об отображении и редактировании - другое. Что ты называешь багом?


To: DarkDiver - все помним, все сделаем, по всем морским... Пока Garmin не доделаем - никуда....

Cnfhbr писал(а):Ну, и какое там противоречие? В существующем описании "польского" формата имеется ряд типов, несопоставимых для МРС, и назначение отдельных типов определено не совсем так, как в МРС - поэтому соответствие НЕ ЖЁСТКОЕ (через hex-коды, разумеется), а ЖЁСТКОЕ - только в самОм МРС.

Ну так мы же обсуждаем экспорт для MPC, а в нем все однозначно, поэтому я и спорю.

Cnfhbr писал(а):
Ну как не имеет? Я говорю, что даже в Гармине всё, что за пределами МРС, может иметь не жёсткое соответствие, такое как в МРС, например, отдельные прошивки. Ты же утверждаешь, что соответствие и там жёсткое, только лишь отображение может отличаться:

Пусть не только отображение, но еще и интерпретация назначения и попадание в другие категории для POI например. Но все это не имеет абсолютно ни какого значения для обсуждаемого соответствия между GRMN_TYPE и HEX ID. Эта совершенно отдельная тема для разговора. То, как отображают и интерпретируют некоторые типы объектов некие отдельные модели приборов ни как не влияет на значения HEX ID в картах и таблицу перехода в МПЦ и потому вообще к теме разговора не относится.

Cnfhbr писал(а):
Вот! А я не столь категоричен в данной ситуации, поскольку не считаю соответствие типов "польский" - МРС жёстким. На мой взгляд, в условиях использования единого классификатора для маппера и МРС, у пользователя должна быть возможность перед экспортом в шейпы присвоить, например, характерному только для маппера типу, если ничего не мешает, кастомный тип МРС.

Ну и я про то и говорю что такие изменения нужно делать перед экспортом.

Cnfhbr писал(а):
Даже в мыслях не было делать это на этапе экспорта, да ещё и не придерживаясь классификатора:
.....
Всё сказанное касалось именно пользователя, а не алгоритма работы софта...

А я понял что ты говоришь про алгоритм. Разумеется пользователю можно и нужно делать такие сопоставления перед экспортом, чтобы не терять инфу из карты. Так что похоже мы друг друга не правильно поняли. Но теперь, я думаю, наш спор можно считать исчерпанным

Добавлено спустя 5 минут 5 секунд:

Fencer_Silver писал(а):To: DarkDiver - все помним, все сделаем, по всем морским... Пока Garmin не доделаем - никуда....

Спасибо! буду ждать с нетерпением

Fencer_Silver писал(а):Если ты о записи ключей в исходник - это одно.

Я об этом говорю. О том, что исходник замусоривается записями, которые неактуальны для новых объектов, полученных при смене типа. И эти записи, к сожалению, никуда не пропадают. Можно ли сделать так, чтобы сохранение изменений в файл убивало все параметры, которые неактуальны для нового объекта и достались ему в наследство от предшественника?

Как и обещал, мои результаты проверок.

I. Проверил работу разных видов адресного поиска. Закономерности на приборах Гармин выявлены следующие:

а) Если для здания сделаны совместно точечный адресный поиск с точкой прибытия, то приезжаем в точку прибытия (при условии, что прибор поддерживает точечный адресный поиск) или адрес не находит (если точечная адресация не поддерживается).

б) Если для здания сделан только точечный адресный поиск, то приезжаем в точку на здании (при условии, что прибор поддерживает точечный адресный поиск) или адрес не находит (если точечная адресация не поддерживается).

в) Если для здания сделан классический адресный поиск с привязкой номера к дороге совместно с точкой прибытия, то приезжаем в точку прибытия.

г) Если для здания сделан классический адресный поиск с привязкой номера к дороге совместно с точечной адресацией, то приезжаем в точку на здании (при условии, что прибор поддерживает точечный адресный поиск) или в точку на отрезке дороги, куда привязывали здание (если прибор не поддерживает точечный адресный поиск).

Выводы:

1. адресация в Гармин с помощью МГЕ создаётся правильно!

2. для приборов без поддержки точечной адресации необходимо прописывать адреса в дорогах, но это и техническая возня, и ограниченность только простыми числовыми адресами, без дробей и букв. Но зато будет поиск в старых приборах и в пользовательских программах MapSource и BaseCamp.

3. Точка прибытия имеет приоритет как над точечным адресным поиском, так и над привязкой к дороге, а точечный адресный поиск имеет приоритет над привязкой к дороге.

II. Проверил этажность.

Наблюдения следующие:

1. Одноэтажные домики получаются недостаточно объёмными и больше похожи на лепёшки. Сейчас сделано HGT_DP=Floors*10, правильно? Хотелось бы поправить формулу пересчёта и попробовать хотя бы как HGT_DP=Floors*10+10 (или +15 метров добавить).



А так всё работает хорошо:

hider1964 писал(а):

Fencer_Silver писал(а):

А атрибут RD_SIGNS ??? Наверное забыли.

Про него и говорили. Он должен жить в ноде. Пока в МГЕ (да и в Мапэдите - не видел)?

rd_signs и exit services разные вещи,если спрашиваетет то уточняйте про что.

Расскажи про создание exit services!! В хелпе про это ни слова.

User_tester писал(а): 1. Одноэтажные домики получаются недостаточно объёмными и больше похожи на лепёшки. Сейчас сделано HGT_DP=Floors*10, правильно? Хотелось бы поправить формулу пересчёта и попробовать хотя бы как HGT_DP=Floors*10+10 (или +15 метров добавить).

Вот не надо... или дайте пользователю задавать коэффициент поправки... Я бы вообще вынес эту функцию в экран настроек шейпов, поле - поправочный коэффициент этажности... Каждый пропишет что ему нужно хоть +10 хоть +100...

Alex писал(а):... планируется поддержать съезды, записывающиеся в узел. Если у когото есть доп. информация по ним - высказывайтесь.

Если речь о road signs / RD_SIGNS, то какая именно доп. инфа нужна?

User_tester писал(а):Кто-нибудь может мне сказать, для чего полигонам мостов BRIDGE (0х10105 в микрогисе) Гармин присваивает высоту HGT_DP? Уж не для того ли, чтобы можно было ограничивать по высоте габариты проезжаемых транспортных средств, что несомненно отразится на роутинге для этих ТС?

Видимо, для того, чтобы при планировании маршрута ткнуть на полигон моста и убедится, что проскочишь под ним со своими габаритами.
Что касается роутинга, то полигон, как может на нём отразиться? Есть ещё полилиния BRIDGE (очертаний моста) с таким же атрибутом HGT_DP, но она не роутовая и "морская"...

KartaBY писал(а): Расскажи про создание exit services!! В хелпе про это ни слова.

Ну в хелпе о многом что можно сделать не пишут. по exits
Exit Services is a feature that allows you to view important Points of Interest (POIs) that are located at exits along an active route that is on a major highway/interstate.
Для этого в первую очередь у вас должны быть автобаны.ну а дальше читаем CNTRL_ACC
и ломаем голову как это все заставить работать
Видимо в связи с тем что МПС утекает в сеть,сейчас гармин выкладывает дистрибутив а потом регионалам досылает необходимые поправки.
по 8ке уже 2 таких поправки получили.

hider1964 писал(а): Exit Services is a feature that allows you to view important Points of Interest (POIs) that are located at exits along an active route that is on a major highway/interstate.
Для этого в первую очередь у вас должны быть автобаны.ну а дальше читаем CNTRL_ACC и ломаем голову как это все заставить работать .

Сломал уже голову.
То бишь, если поставить на съезде CNTRL_ACC как "Y", то все соответствующие ПОИ на расстоянии 400 метров будут соотносится с данным съездом.
Один вопрос меня только мучает. Отношение ПОИ к съезду определяет прибор, или это предопределяется при компиляции карты.
Вот то, что я в свое время нашел по этому поводу, но не знал как это использовать.

Добавлено спустя 5 минут 11 секунд:
Да простят меня админы этого форума.
A Highway exit is a point of exit along a motorway, preceding an exit ramp. Highway-exit POIs (CAT_ID = 9592) are a new type of POI (CAT_ID = 9592) placed along controlledaccess links at exit points that associate a set of services (gas stations, restaurants, hotels, etc.) that are within a given travel distance from the exit. The association of POIs to a Highway-exit POI is through Parent-Child coding, in RDF_POI_CHILDREN. Only one highway-exit POI is placed in a given direction of travel at an exit point. Highway-exits are placed before clover-leaf type intersections leading to a street (i.e., as opposed to highway-to-highway junctions) and before rest area exit points.
The CAT_ID column in the RDF_POI table contains a facility type of HIGHWAY EXIT (9592) which is used for Highway-exit POIs. Only the POI сategories listed in Table 53:POI Categories can be associated to Highway-exit POIs.
A Highway-exit POI is named but does not have the usual attributes of a POI. For example, a Highway-exit POI has no address, no phone number, no special attributes, etc. It is also different in the sense that it is not a route destination; rather an intermediate point used to help select a route destination. POI categories applicable to Highway-exit POIs are listed in Table 53:POI Categories.
The typical use case is a driver who is looking for a particular type of service, at some distance ahead on the current route. The service POIs do not lie directly on the route, but the Highway-exit POIs do. A driver is able to see a list of service POIs associated to the highway
exit and can search for a significant service POI which is “on the route.”.
To be able to search for POI categories associated with a specific Highway-exit POI, the positioning of the Highway-exit POI is on (or just preceding) the last highway link prior to the actual exit, in the direction of travel.
In Figure 9-9, the northbound Highway-exit POI will be placed just south of the northbound ramp marked 25A. The south bound Highway-exit POI will be placed just north of the southbound ramp marked 25B. The service POIs within a specified distance from the Highway-exit POI will be associated to the Highway-exit POI. A list of service POIs which are associated to the highway exit is made available and a search can be conducted for a
particular service POI of significance.

Inclusion
• All exits of the North American road network are included.
• Highway-exit POIs are associated to all POIs within a 1/4 mile (approximately 400
meters) driving distance from the interchange for the categories listed in Table 53:POI
Categories.
Facility Type

• ATM
• Auto Service & Maintenance
• Bank
• Business Facility
• Grocery Store
• Hotel
• Petrol/Gasoline Station
• Rest Area
• Restaurant
• Shopping

Note: Additional POIs beyond 1/4 mile driving distance may be included when deemed
significant to that exit.
Naming
• Each Highway Exit POI is uniquely named.
• Exits which have an assigned Exit Number are named as EXIT Number/Ramp destination/
Direction as shown in the following example:
Example:
EXIT 61/Center St/N
• If no Exit Number exists, the POI is named as Ramp Destination/Direction as shown in
the following example:
Example:
Center St/N
Phone Number
Not included.

А рисунок есть? Или потерян?

User_tester писал(а): 2. для приборов без поддержки точечной адресации необходимо прописывать адреса в дорогах, но это и техническая возня, и ограниченность только простыми числовыми адресами, без дробей и букв. Но зато будет поиск в старых приборах и в пользовательских программах MapSource и BaseCamp.

Для старых приборов без дополнительной возни адресный поиск можно строить вот таким образом, с использованием адресных данных из полигонов:
http://john.bdk.com.ru/gpsmaps/addrmp/index.htm

Ага... только одно НО... адресную карту невозможно сделать в NT формате, (ибо надо снять роутинг), приходится делать или в открытом или в квази NT так что это подарок тем кому нужна адресная база города... Мы в свое время дней 10 потратили на эксперименты, как бы адресную карту по приморской методике сделать в NT формате... не получилось... Или дома ищет но маршрут не прокладывает, или не в NT формате...