MicroGIS™ DevCon

посмотрел и я. чего хотелось бы:
1. конверта в шэйпы. при конверте в шэйпы необходимо создавать ADDR_PNT и ARRV_PNT. если со вторым понятно - он возьмется из точки подъезда (если не указан точка, то возьмется некий центр массы дома). А вот с первым - не совсем. при очень сложной конфигурации дома точка может уехать далеко за его пределы. возможно для полигона дома имеет смысл добавить аналог точки подъезда. и при сборке в шэйпы, если он указан - то брать из него. если не указан, то как некий центр массы дома.
2. Гарминовский поиск по линиям сделан по аналогу ГМЕ. однако на мой взгляд не совсем удобно вносить данные для каждой точки. возможно имело бы смысл вносить такие данные сразу выделив линию и указав начальные и конечные данные.
3. при указании адресов в линии сначала нужно выбрать первую точку. выбрав линию сразу не видно на каком конце линии точка начальная. имело бы смысл визуально выделять начало линии, даже если формально у линии нет направления.
4. хотелось бы иметь настройки видимости данных на панели свойства объекта. если я не использую вообще поля Наименование1, то зачем мне их видеть? в идеале - даже возможность указания нужного мне порядка вывода полей.
5. вытекает из 4. есть доп атрибуты. мне удобнее, когда редактирую, указывать некоторые доп атрибуты не на отдельной закладке, а на закладке свойства объекта рядом с аналогичными стандартными. Хотелось бы возможность такой настройки. Пример - MPC поддерживает "нестандартные" скорости. типа 160 км/ч. или 50 км/ч. в настоящий момент они выделены в доп атрибут. и при конветрте в шэйпы, если доп атрибут указан, то берется он, если не указан, то берется из стандартных с возможными значениями (на сколько помню (5, 20, 40, 60, 80, 90, 120). и вот редактируя карту, хотелось бы иметь возможность сразу указать нестандартную скорость сразу в том же окне свойств. а вот для этого хотелось бы иметь возможность. чтобы я сам установил настройку отображения окна свойств.
6. добавлены возможности подстветки по адресам, подсветки по этажам. хорошо бы иметь возможность подсветки по доп полям и чтобы пользователь в настройке мог указать, по какому доп полю он хочет подсветить.

Добавлено спустя 10 минут 57 секунд:
по поводу тайпсетов и всего прочего. с позицией что гарминовский тайпсет единственный и неповторимый - не согласен. вполне можно было бы РИСОВАТЬ в любом созданном авторами тайпсете. при конверте в шэйпы придется загонять в универсальный.
пример был приведен. с точки зрения одного софта банкомат и банк выделяется (это могут быть и примеры, где в гармине здания, а в навителе - административные и жилые здания). соответственно в редакторе хотелось бы видеть два типа. использовать кастомный для второго типа можно, но при сборке в шэйп в любом случае придется задавать настраиваемую пользователем таблицу, в которой пользователь указывал бы, что для такого типа в шэйпах будет соответствовать такой. и банк и банкомат пойдут в один тип (именно в банк, и чтобы банкомат не пошел в кастомный банкомат), и жилое и административное здание пойдут в один тип - здание.

далее - этажность. сейчас сделана в целых числах. а я хочу, чтобы сарай был 1 этаж, 2-х этажное здание было 2 этажа, а частный одноэтажный дом - был средним между ними... в MPC высота задается в футах а не этажах.зачем меня намеренно ограничивать? а если кому-то нужно именно целые - можно настройкой это ограничить. Возможно и другое решение: при сборке в шэйпы, должен быть некий пользователем указанный коэффициент. позволяющий произвольно промасштабировать данное значение в высоты. то есть высоту могу указывать любую, скажем в метрах, а при переходе в шэйпы коэффициент примерно 0,3. хочу сразу в футах и коэффициент 1. хочу в этажах и коэффициент 10. а может даже задавать произвольную формулу. типа N*значение_поля_floors+M

Добавлено спустя 15 минут 3 секунды:
хотелось бы чтобы на панели адреса в дереве адресов адреса выводились в алфавитном порядке, или по крайней мере чтобы их можно было отсортировать по требованию. так проще искать дубли и наоборот не указанные объекты.
а то я открываю список и вижу
71а
61а
7а
85
75
63
5
69
Сами улицы в списке тоже идут в перемешку, как и населенные пункты...

Добавлено спустя 4 минуты 40 секунд:
там же в меню адреса хотелось бы иметь возможность надожить фильтр на объекты. любой произвольный. дэ факто сейчас я могу увидеть все объекты по ул. Красноармейской конкретного города. хотелось бы увидеть все объекты по ул. Красноармейской всех городов. или по ул Красноармейской конкретного города, но еще и с конкретным номером дома.
кроме того там на панели есть еще и поиск по координатам. а вот по АйДи точки или АйДи линии - нет.

Добавлено спустя 1 минуту 58 секунд:
аналогично по телефонам. видны все телефоны, но во первых я не могу перейти к объекту. у которого указан данный телефон. во вторых не могу отобрать телефоны с фильтром. например все +375152******

sagit писал(а): аналогично по телефонам. видны все телефоны, но во первых я не могу перейти к объекту. у которого указан данный телефон. во вторых не могу отобрать телефоны с фильтром. например все +375152******

а я могу
открываете все объекты в групповой, строите фильтр по телефонному номеру и все - можно переходить

sagit писал(а): 2. Гарминовский поиск по линиям сделан по аналогу ГМЕ. однако на мой взгляд не совсем удобно вносить данные для каждой точки. возможно имело бы смысл вносить такие данные сразу выделив линию и указав начальные и конечные данные.

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

sagit писал(а): по поводу тайпсетов и всего прочего. с позицией что гарминовский тайпсет единственный и неповторимый - не согласен. вполне можно было бы РИСОВАТЬ в любом созданном авторами тайпсете. при конверте в шэйпы придется загонять в универсальный.
пример был приведен. с точки зрения одного софта банкомат и банк выделяется (это могут быть и примеры, где в гармине здания, а в навителе - административные и жилые здания). соответственно в редакторе хотелось бы видеть два типа. использовать кастомный для второго типа можно, но при сборке в шэйп в любом случае придется задавать настраиваемую пользователем таблицу, в которой пользователь указывал бы, что для такого типа в шэйпах будет соответствовать такой. и банк и банкомат пойдут в один тип (именно в банк, и чтобы банкомат не пошел в кастомный банкомат), и жилое и административное здание пойдут в один тип - здание.

Как я уже писал соответствие текстовых идентификаторов их шестандцатиричным идентификаторам должно приниматься как разработанный Гармином стандарт и жестко соблюдаться. Аргументацию уже не однокартно озвучивал. Если нужно преобразовывать типы или сводить несколько типов в один гарминовский (как в описанных вами примерах со зданиями и банкоматами) - потрудитесь сделать это предварительно в польском исходнике перед конвертацией в шейпы - вот и все, благо все можно делать в автоматическом режиме и весь необходимый для этого программный инструментарий имеется.

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

В МГЕ - есть проверка на непорезанность дорог на перекрестках и инструмент "Разрезать дороги на перекрестках". Соответственно не вижу препятствий для пользования и проверкой и инструментом.

Новые типы POI в MPC v.8.0, по сравнению с MPC v.7.22

Красным жирным курсивом выделены POI, которые перевел и соотнес с идентификаторами из тайпсета ТОПО. Гляньте, и можно перебрасывать в тайпсет Garmin.

Остальные некоторые позиции перевел на русский язык, но пока не соотносил.

А чтоже ты в таблицу внес только POI ???

User_tester писал(а):Новые типы POI в MPC v.8.0, по сравнению с MPC v.7.22
Гляньте, и можно перебрасывать в тайпсет Garmin.

Глядеть рано! Есть у меня все новые типы POIs, причёсанные и переведённые. Вот, когда эти новые типы появятся в Edit Feature Display Properties / Garmin Points настроек конфигурации MPC, тогда и посмотрим...
А перебрасывать в тайпсет, тем более, ни в коем случае - сырьё это глючное!!! Писал уже сегодня в соседней ветке...

Alex писал(а):А чтоже ты в таблицу внес только POI ???

Пока только их успел.

Cnfhbr писал(а):Глядеть рано! Есть у меня все новые типы POIs, причёсанные и переведённые. Вот, когда эти новые типы появятся в Edit Feature Display Properties / Garmin Points настроек конфигурации MPC, тогда и посмотрим...А перебрасывать в тайпсет, тем более, ни в коем случае - сырьё это глючное!!! Писал уже сегодня в соседней ветке...

Согласен. Подождём. В любом случае, перечень уже есть под рукой.

Поддержка заявленных новых типов POI в MPC 8 не доделана, из-за этого нет возможности выяснить их HEX-ID, а без этого их нельзя добавить в тайпсет, поэтому надо ждать исправленную версию MPC v8.

Если возникнет проблема с значением ADDR_FMT который может быть 1 и 0 в адресном шейпе у номеров с дробями, то почти всегда будет 1 и лишь один случай когда 0 - это адрес такого типа Пупкина 1/2 во всех остальных вриантах типа Пупкина 1А, или Пупкина 1кор1 и т.п там везде 1-ца!

Сделайте, пожалуйста, к названиям дорог и улиц в TypeSet=Garmin 7 шаблонных префиксов, которые являются стандартными у Garmin.
Стандартные префиксы компилятор понимает и выдаёт, как и положено, иконками на линиях дорог.

А вот имеющиеся сейчас в программе префиксы:



компилятор, к сожалению, не понимает и выдаёт их в готовой карте "как есть":



Важно! Буквы {M, {P, {O в шаблоне обязательно должны быть записаны в английской раскладке, а НЕ в русской.

User_tester писал(а):Сделайте, пожалуйста, к названиям дорог и улиц в TypeSet=Garmin 7 шаблонных префиксов, которые являются стандартными у Garmin.

 Цитата из мануала к MPC!

Road names may contain special characters to allow for iconization as well as the identification of various portions of the name. The supported special characters for road names are as follows:
"{M" - Major highway icon indicator. Must be first characters in name.
"{P" - Principal icon indicator. Must be first characters in name.
"{O" - Other icon indicator. Must be first characters in name.
"{2" - Non-spacing prefix indicator.
"{3" - Prefix indicator.
"{4" - Non-spacing suffix indicator.
"{5" - Suffix indicator.

The prefix and suffix indicators are used when you wish to make only the main portion, or body, of a name appear until you zoom in on a feature. For example, encoding "E 151ST ST " as "E{3151ST{5ST" causes the road to be labeled as "151ST" until the road is zoomed in on. At some point, the full text of " E 151ST ST " will be picked up. This serves to reduce clutter.

Стандартные префиксы компилятор понимает и выдаёт, как и положено, иконками на линиях дорог.
А вот имеющиеся сейчас в программе префиксы:

компилятор, к сожалению, не понимает и выдаёт их в готовой карте "как есть":

Важно! Буквы {M, {P, {O в шаблоне обязательно должны быть записаны в английской раскладке, а НЕ в русской.

Я думаю, тут правильнее будет сделать, чтобы выполнялось конвертирование префиксов в MGE, на этапе экспорта в шейпы, для совместимости с cGPSMapper, который правильно понимает как раз таки имеющиеся префиксы.

Я бы просто добавил в список эти 7 элементов к уже существующим и не думал над какой-то конвертацией при экспорте. И расположил бы их красиво в списке, разделив чертой: сразу пусть идут в столбик префиксы для официального компилятора MPC, а потом - для неофициального cGPSMapper. И картограф сам выберет, что ему надо! И ему наглядно видно, что он использует, и разработчикам меньше головной боли придумывать излишнюю конвертацию.

User_tester писал(а):Я бы просто добавил в список эти 7 элементов к уже существующим и не думал над какой-то конвертацией при экспорте. И расположил бы их красиво в списке, разделив чертой: сразу пусть идут в столбик префиксы для официального компилятора MPC, а потом - для неофициального cGPSMapper. И картограф сам выберет, что ему надо! И ему наглядно видно, что он использует, и разработчикам меньше головной боли придумывать излишнюю конвертацию.

Да, в принципе, тоже вариант.