Обсуждение Beta версий (тестирование, баги, замечания)

[User_tester]

0x1 - это ПОИ. СТАВЬ ХОТЬ В ПОЛЕ ЧИСТОМ.... ЗАПОЛНИ АДРЕС (ЛЮБОЙ), СТАВЬ ТОЧКУ ПОДЪЕЗДА - ХОТЬ К ДОРОГЕ, ХОТЬ КУДА...

ОК, спасибо, протестирую работу в навигаторе. По результатам отпишусь.

ПОТОМУ ЧТО НАДО ЩЕЛКНУТЬ ПРАВОЙ КНОПКОЙ НА ТОЧКЕ ПОДЪЕЗДА И ВЫБРАТЬ ПУНКТ "ИЗМЕНИТЬ". Блин.... Что за вопросы...

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

Это ведь поможет связать точку подъезда с дорогой! А это очень необходимо! И если смещаем дорогу с привязанными точками подъезда, то линии связи будут растягиваться и адресные точки останутся на месте! А точки подъезда - сместятся с дорогой.

P.S. Я намеренно говорю и подразумеваю везде по тексту сообщения о паре адресная точка-точка подъезда, но никак не о парах лес-точка прибытия, город-точка прибытия и т.п., так как последнее - глупость полная!

И еще, по поводу их наличия - у других объектов. Если на данном этапе их запретить, то пропадет целая куча работы в карте. Поэтому, сейчас можно сделать "Создать адресные точки в строениях" - они расставятся с точками подъездов, ранее сделанными пользователями. Далее, например через месяц, их для других объектов, можно будет запретить, когда теоретически все их совместят.

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

Ну так вывесите, пожалуйста, сообщение на форуме с предложением ко всем в течение месяца-двух поправить и совместить точки подъезда. Так как они затем в программе будут прибраны как неактуальные.

Далее такой момент.

Поясните, пожалуйста, логику постановки в вашей программе SIDE_OF_RD=L в случае нахождения точки подъезда на дороге?

По поводу остальных случаев (не рекомендованных Гармин к использованю!!!):

1. точки подъезда находится по одну сторону дороги с точкой адреса

2. по разные стороны дороги от точки адреса

я проверю в приборе и по результатам отпишусь.

Есть большие сомнения в том, что расчёт стороны должен вестись относительно ARRV_PNT. Конечная точка - адресная! И навигатор сообщает, слева или справа находится она относительно точки прибытия, которую рекомендовано ставить в дороге, но никак не вне её. И тем более, сторону рассчитывать по ней. Вообще нельзя указать сторону по точке подъезда, если она стоит как рекомендовано - в дороге! У вас же пишется SIDE_OF_RD=L почему-то...

Прилагаю скриншот, как должно быть правильно. Правильный вариант, согласно рекомендации Гармин, верхний пример Ленина, Д.5.

На скриншоте дуговой стрелкой показан плохой манёвр в одном из нерекомендованных случаев нахождения точки подъезда по разные стороны дороги с точкой адреса.

[Fencer_Silver]

Это ведь поможет связать точку подъезда с дорогой! А это очень необходимо! И если смещаем дорогу с привязанными точками подъезда, то линии связи будут растягиваться и адресные точки останутся на месте! А точки подъезда - сместятся с дорогой.

Мне вообще не ПОНЯТНО зачем делать точки подъезда ПЕРЕПЕНДИКУЛЯРНО К ДОРОГЕ??? Об этом писал Hider1966! Если нет необходимости ОСОБОЙ, то навигатор и так доведет до ПЕРПЕНДИКУЛЯРА (ТРАВЕРСА) дома и сообщит о прибытии, без всякой точки подъезда! Monstria писал о том, что это РЕКОМЕНДОВАНО Гармин. Имхо - считаю, что точка подъезда должна использоваться только в случаях, когда это НЕ ТРАВЕРС дома (объекта) - иначе это "пустая" работа и загромождение карты.

1.png (9.93 КБ) 12063 просмотра

Поясните, пожалуйста, логику постановки в вашей программе SIDE_OF_RD=L в случае нахождения точки подъезда на дороге?

Вряд ли ты НАСТОЛЬКО ТОЧНО поставишь точку прибытия НА ДОРОГЕ. Она, по математическим расчетам - будет слева или справа. Хоть миллиметр, но будет. Математика - весч точная Далее в Гармине сторона дороги Левая или Правая. Я в МПС хелпе не нашел - "ТОЧНО НА ДОРОГЕ".

Добавлено спустя 17 минут 41 секунду:
P.S. Тестировать - не спеши. Через пару часов будет обновление - там и потестишь.
Пока краткий анонс:
- Исправлено: вычитка из файла нового типа 0х1
- Исправлено: новый инструмент "Создать адресные точки в стрениях" - будет создавать
а) для тайпсета "Гармин" адресные точки только для типов:
GENERIC_MANMADE
HOSPITAL
COLLEGE
SHOPPING_AREA
б) для тайпсета "ТОРО"
во всех строениях из категории "BUILDING"
- Исправлено: адресные точки при работе инструмента "Создать адресные точки в строениях" - будут созданы только в тех объектах, где имеется полный адрес.
- Переделано: при работе инструмента "Создать точки в строениях" - будет осуществляться проверка на существования адресной точки (для предотвращения повторного создания);
- Исправлен экспорт в МПС шейпфайлы для версии WIN64.

[User_tester]

Имхо - считаю, что точка подъезда должна использоваться только в случаях, когда это НЕ ТРАВЕРС дома (объекта) - иначе это "пустая" работа и загромождение карты.

В неоднозначных и особых случаях (например, когда есть альтернативные неудобные пути подъезда) могут применяться. Но это никакого отношения к привязке точек к дороге не имеет!

Поясню, зачем нужна и полезна привязка ARRV_PNT к дороге, реализацию которой так сильно у вас просим. Когда выполняем правку геометрии дороги, в частности, после ремонта / расширения / сужения, то точки ARRV_PNT сейчас остаются на старом месте, где была прежде дорога. Это не рекомендуется гармин и криво само по себе, согласитесь... Навигатор ведёт по новой дороге, потом прыгает в точку подъезда на зелёную зону, в детскую площадку и.т.п., где проходила старая дорога, а потом уже ведёт в финальный пункт назначения ADDR_PNT.

Приходится перепривязывать каждую точку подъезда. Это крайне неудобно (читайте ниже). Поэтому необходимо автоматически перетягивать точки подъезда вслед за дорогой.

Вряд ли ты НАСТОЛЬКО ТОЧНО поставишь точку прибытия НА ДОРОГЕ. Она, по математическим расчетам - будет слева или справа. Хоть миллиметр, но будет. Математика - весч точная Далее в Гармине сторона дороги Левая или Правая. Я в МПС хелпе не нашел - "ТОЧНО НА ДОРОГЕ".

Сейчас если тянуть точку подъезда ARRV_PNT тупо на дорогу, то она, к сожалению, абсолютно не притягивается к узлам на ней! Это очень неудобно... Тогда, конечно, сложно попасть в дорогу. Тут вы правы.

Приходиться изворачиваться: сразу тяну в нужное место ARRV_PNT, а потом к ней притягиваю узел дороги. Тогда нормальное притяжение есть. Альтернативно могу просто скопировать координаты узла и вставить в точку подъезда, хоть в редакторе, хоть в Notepad++. И в итоге должны иметь 2 точки с одинаковыми координатами: точку прибытия и узел в дороге. Математика тут нипричём, когда координаты заведомо одинаковые по всем цифрам. А при экспорте в шейпы получаем SIDE_OF_RD=L - нонсенс! Почему тогда не SIDE_OF_RD=R??? Тоже ведь достойный вариант! Чем плохо?

А суть здесь, полагаю, не такая должна быть! Расчёт стороны должен вестись относительно местоположения ADDR_PNT. И это логично! Вы прибыли в точку подъезда на дороге, а потом вам навигатор говорит, слева или справа от вас находится ADDR_PNT. Сейчас же расчитываете сторону дороги по местоположению точки прибытия, а для рекомендованного случая нахождения точки на дороге - просто ставите SIDE_OF_RD=L как вариант. Справедливость такого расчёта я хотел бы проверить.

Пусть меня уважаемые гарминщики поправят, в случае чего.

- Переделано: при работе инструмента "Создать точки в строениях" - будет осуществляться проверка на существования адресной точки (для предотвращения повторного создания);

Я сейчас пишу по памяти, так как программы нет под рукой. Гляньте до выкладывания бетки, имеются ли у автоматически расставленных адресных точек в панели свойств заполненные поля "страна", "район", "город", "улица", "номер дома", как у соответствующих полигонов, на которых они стоят?

[Alex]

MicroGISEditor обновление v1.0.12.588b

 История изменений:

Версия 1.0.12.588 21.05.2013
- Исправлено: вычитка из файла нового типа 0х1
- Исправлено: новый инструмент "Создать адресные точки в строениях" - будет создавать
а) для тайпсета "Гармин" адресные точки только для типов:
GENERIC_MANMADE
HOSPITAL
COLLEGE
SHOPPING_AREA
б) для тайпсета "ТОРО"
во всех строениях из категории "BUILDING"
- Исправлено: адресные точки при работе инструмента "Создать адресные точки в строениях" - будут созданы только в тех объектах, где имеется полный адрес.
- Переделано: при работе инструмента "Создать точки в строениях" - будет осуществляться проверка на существования адресной точки (для предотвращения повторного создания);
- Исправлен экспорт в МПС шейп файлы для версии WIN64.

[Fencer_Silver]

Поясню, зачем нужна и полезна привязка ARRV_PNT к дороге, реализацию которой так сильно у вас просим. Когда выполняем правку геометрии дороги, в частности, после ремонта / расширения / сужения, то точки ARRV_PNT сейчас остаются на старом месте, где была прежде дорога. Это не рекомендуется гармин и криво само по себе, согласитесь... Навигатор ведёт по новой дороге, потом прыгает в точку подъезда на зелёную зону, в детскую площадку и.т.п., где проходила старая дорога, а потом уже ведёт в финальный пункт назначения ADDR_PNT.

Скажу больше - пока не планируется. И даже не вижу необходимости. С учетом того, что реально нужных точек будет очень немного (см скрин выше).

А при экспорте в шейпы получаем SIDE_OF_RD=L - нонсенс! Почему тогда не SIDE_OF_RD=R??? Тоже ведь достойный вариант!

Могу предложить другой вариант - Я СДЕЛАЮ ПОЛЕ "СТОРОНА ДОРОГИ" - И ЗАПОЛНЯЙ ЕЕ РУЧКАМИ, КАК В АРКГИСЕ ИЛИ МАП ИНФО. НИЧЕГО СЧИТАТСЯ НЕ БУДЕТ. Так сделано для морских объектов - "сторона полигона". Далее - а что нужно писать в шейп в таком случае "НЕТ СТОРОНЫ"?????

[User_tester]

Скажу больше - пока не планируется. И даже не вижу необходимости. С учетом того, что реально нужных точек будет очень немного (см скрин выше)

Очень жаль, что не видите необходимости и не планируете! И, кстати, на вашем скрине надо всем домам сделать привязку к соседней улице, а не только для одного, как нарисовали. Редко бывает, когда в современных городских планировках надо только один дом привязывать к соседней улице... Часто целые пачки домов.

Далее. Поскольку я работаю в вашем редакторе и вижу явную необходимость и полезность в описанной привязке точек прибытия, то хотелка по-прежнему остаётся актуальна. Не верится мне, что мощными возможностями языка С++ нельзя этого сделать. И не верю, что вы не знаете, как. Тем более, когда уже столько много трудного в моём понимании сделано вами при мне.

Надеюсь, что другие гарминщики поддержат её, не отмалчиваясь лениво. Сейчас же я единственный из пользователей вашей программы активно продвигаю доработку точечной адрески...

P.S. А пока просьба сделать притяжение ARRV_PNT к узлам дороги при сближении. Они вообще ни к чему не притягиваются сейчас в программе. Заодно и про притяжение обычных точек вспомните - это давняя просьба многих.

Могу предложить другой вариант - Я СДЕЛАЮ ПОЛЕ "СТОРОНА ДОРОГИ" - И ЗАПОЛНЯЙ ЕЕ РУЧКАМИ, КАК В АРКГИСЕ ИЛИ МАП ИНФО. НИЧЕГО СЧИТАТСЯ НЕ БУДЕТ. Так сделано для морских объектов - "сторона полигона". Далее - а что нужно писать в шейп в таком случае "НЕТ СТОРОНЫ"?????

Автоматический расчёт всегда удобнее ручной простановки. Полагаю, что и в аркгисе, кто в нём работает, тоже автоматика рассчитывает. Но, естественно, речь идёт о корректном расчёте!

Поэтому давайте не будем спешить и горячиться. Я проверю на практике варианты SIDE_OF_RD и сообщу вам результаты. Корректно ли делать расчёт SIDE_OF_RD по ARRV_PNT или надо делать расчёт по ADDR_PNT?

И никаких вариантов "НЕТ СТОРОНЫ" быть не может в принципе - не выдумывайте. Либо лево, либо право.

По меньшей мере, в сегодняшней беседе с большим знатоком гармина Monstria подтверждена правильность расчёта относительно положения ADDR_PNT.

[User_tester]

Результаты проверок точечной адресации.

Сделал пробный исходник - 2 улицы, 4 дома. Без адресов собирает нормально. Создал точечную адресацию. Экспортировал в шейпфайлы и в ходе компиляции постоянно получаю:

 Building log MPC

Building Product <Address>...

Building Address...
Importing address.shp...
Imported 0 areas, 0 lines, and 8 points.
Importing areas.shp...
Imported 4 areas, 0 lines, and 0 points.
Importing base.shp...
Imported 0 areas, 0 lines, and 0 points.
Importing buildings.shp...
Imported 0 areas, 0 lines, and 0 points.
Importing lines.shp...
Imported 0 areas, 0 lines, and 0 points.
Importing poi.shp...
WARNING: HOUSE_NUM on ADDR_PNT at (53.8663,27.6729) is empty.
WARNING: HOUSE_NUM on ADDR_PNT at (53.8659,27.6721) is empty.
WARNING: HOUSE_NUM on ADDR_PNT at (53.8662,27.6709) is empty.
WARNING: HOUSE_NUM on ADDR_PNT at (53.8665,27.6704) is empty.
Imported 0 areas, 0 lines, and 5 points.
Importing roads.shp...
Imported 0 areas, 3 lines, and 0 points.
ERROR: arrival point id=0 does not exist, referenced by address point at lat=53.8663, lon=27.6729
ERROR: arrival point id=0 does not exist, referenced by address point at lat=53.8658, lon=27.6721
ERROR: arrival point id=0 does not exist, referenced by address point at lat=53.8662, lon=27.6709
ERROR: arrival point id=0 does not exist, referenced by address point at lat=53.8665, lon=27.6704
ERROR: Error creating map image.
Found one or more bad arrival points for point addresses.
C:\projects\map-create\MPC_MapCreator.cxx - 157

Проблема в создаваемых шейпах. Точки прибытия создаются в горизонтальный ряд за 6000 км от адресных точек (видно в Global Mapper). Попробовал вручную выставить точки прибытия у адресных точек у дороги - то же самое выдал. Ситуация интересная, надо разбираться. У меня пока идей нету.

Исходники и шейпфайлы прилагаю.

[User_tester]

Эта же ошибка воспроизводится на других компьютерах и на других (уже не модельных) картах! Ничего скомпилировать не удаётся после расстановки точечной адресации.

[User_tester]

Нашёл причину! Адресные точки экспортируются как в файл address.shp, так и в файл poi.shp, причём в последний - без точек прибытия. Из последнего файла надо их совсем убрать. Ранее их, кстати, и не было там.

[Alex]

Исправим. Спасибо за помощь.

[User_tester]

Поправьте ещё, пожалуйста, линии связи ADDR_PNT и ARRV_PNT. Открываешь карту, а они обрезаны до половины:



Линии связи у новых нарисованных точек прибытия нормальные, а после переоткрытия карты становятся обрезанными, как и все предыдущие.

[Alex]

Подтверждаю. Исправим.

[User_tester]

По поводу журнала сообщений.

Читаю замечания при загрузке:

 

Замечание (смещение 78D1h): Неизвестный тип 0x11500 (точка).
Замечание (смещение 1E6C0h): Неизвестный тип 0x10e00 (полилиния).
Замечание (смещение 1E758h): Неизвестный тип 0x10e00 (полилиния).
Замечание (смещение 5E53Dh): Неизвестный тип 0xd (полилиния).
Замечание (смещение 5F233h): Неизвестный тип 0x10f04 (полигон).
Замечание (смещение 60F3Bh): Неизвестный тип 0x10f10 (полигон).
Замечание (смещение 61A7Ah): Неизвестный тип 0x10f10 (полигон).
Замечание (смещение 62065h): Неизвестный тип 0x10f10 (полигон).
Замечание (смещение 62489h): Неизвестный тип 0x10f10 (полигон).
Замечание (смещение 6276Dh): Неизвестный тип 0x10f10 (полигон).
Замечание (смещение 62A2Ah): Неизвестный тип 0x10f10 (полигон).
Замечание (смещение 62EB0h): Неизвестный тип 0x10f10 (полигон).
Замечание (смещение 62FCBh): Неизвестный тип 0x10f10 (полигон).
Замечание (смещение 632CAh): Неизвестный тип 0x10f10 (полигон).
Замечание (смещение 63453h): Неизвестный тип 0x10f10 (полигон).
Замечание (смещение 641E4h): Неизвестный тип 0x10f10 (полигон).
Замечание (смещение 6445Fh): Неизвестный тип 0x10f10 (полигон).
Замечание (смещение 647BDh): Неизвестный тип 0x10f10 (полигон).
Замечание (смещение 648C2h): Неизвестный тип 0x10f10 (полигон).
Замечание (смещение 649C7h): Неизвестный тип 0x10f10 (полигон).

Далее после экспорта в шейпы читаю:

 

Начало экспорта в MPC Shape Files....
Экспорт POI
Замечание: объект 0x11500 не является MPC типом
1 замечания(й).

Начало экспорта полигонов
Замечание: объект 0x10F04 не является MPC типом
Замечание: объект 0x10F10 не является MPC типом
Замечание: объект 0x10F10 не является MPC типом
Замечание: объект 0x10F10 не является MPC типом
Замечание: объект 0x10F10 не является MPC типом
Замечание: объект 0x10F10 не является MPC типом
Замечание: объект 0x10F10 не является MPC типом
Замечание: объект 0x10F10 не является MPC типом
Замечание: объект 0x10F10 не является MPC типом
Замечание: объект 0x10F10 не является MPC типом
Замечание: объект 0x10F00 не является MPC типом
Замечание: объект 0x10F10 не является MPC типом
Замечание: объект 0x10F10 не является MPC типом
Замечание: объект 0x10F10 не является MPC типом
Замечание: объект 0x10F10 не является MPC типом
Замечание: объект 0x10F10 не является MPC типом
Замечание: объект 0x10F10 не является MPC типом
Замечание: объект 0x10F10 не является MPC типом
Замечание: объект 0x10F10 не является MPC типом
Замечание: объект 0x10F10 не является MPC типом
66 замечания(й).

Начало экспорта полигонов
0 замечания(й).

Начало экспорта полилиний (не имеющих признака дорог)
Замечание: объект 0x10E00 не является MPC типом
Замечание: объект 0x10E00 не является MPC типом
Замечание: объект 0x10E00 не является MPC типом
3 замечания(й).

Это всё мои пользовательские объекты из скина. Они не плохие. Расширяют стандартный тайпсет Garmin. Уходят в шейпы в виде hex-идентификаторов. В компиляторе MPC их уже ждут свои CUSTOMIZABLE-соответствия...

Возможно ли как-то оптимизировать журнал от подобных записей?

То есть, пользовательские объекты, прописанные в подключенном активном скине (на момент открытия карты и на момент экспорта в шейпы) и расширяющие стандартный набор типов MPC + сам набор типов MPC ---> не включать в замечания.

[Alex]

Ну и что тебя беспокоит?

[DarkDiver]

Доделал один не большой, но полноценный, законченный кусок морской карты, используя редактор MicroGISEditor. Хочу выразить благодарность и сказать ОГРОМНОЕ спасибо разработчикам за поддержку морских фич.

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

Итак по порядку.

1. Некритические мелкие ошибки:

1.1 Название категории для морских полигонов из диапазона 0x105** должно быть «Marine Restricted Areas», а сейчас «Marine Obstruction Areas»
1.2 Название морского типа POI 0x10901 должно быть «Bottom Conditions» («характер дна»), а сейчас это «Label»
1.3. Необходимо исправить перевод на русский язык значений поля LightType для морских огней. Правильный перевод с точки зрения общепринятой в условных обозначения терминологии я уже высылал в виде таблицы, могу продублировать, если надо.

2. Предложения по доработке

2.1 Сделать доступ к окну редактирования маяков «Edit Additional Ligth Type» из групповой таблицы, поскольку абсолютно все маяки приходится редактировать через это окно, т.к. параметр Range, который есть абсолютно у всех маяков, доступен только через это окно – это во-первых. А во-вторых даже одноцветные маяки имеющие определенный дипазон углов видимости, задаются как двух-секторные, при этом один из секторов ставится как несветящийся. В итоге этим окном приходится пользоваться очень часто и хотелось бы иметь к нему доступ из групповой таблицы.

2.2 Сделать доступ к полю Range для маяков из окна Object Properties, поскольку этот параметр имеют абсолютно все маяки. Сейчас его редактирование приходится всегда делать через «Edit Additional Ligth Type». А хотелось бы чтобы в это окно нужно было лазить только при задании секторов. Т.е. нужно поле Range в окне Object Properties, при этом если это поле пустое, то записываем в файл в виде Light=3, если не пустое то в виде Light=(3,30)

2.3 Сделать визуализацию секторов для много секторных маяков, например как на скрине:

Scr000002.bmp (225.05 КБ) 11905 просмотров

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

2.4 Сейчас реализована подсветка линий в зависимости от поля PolygonSyde, с ее введением стало работать намного удобней. Но я предлагаю доработать эту функцию и сделать также отображение цвета и стиля линии:

LineStyles.png (10.96 КБ) 11905 просмотров

2.6. Хотелось бы иметь доработанное окно «Attachments», подробности уже здесь обсуждались.

2.7. Доработать инструменты создания эллипса и круга.
Эллипс в принципе мало используемый инструмент, а с учетом того, что его нельзя даже повернуть делает его вообще почти бесполезным. Построение круга по тому же алгоритму, что и эллипса делать малопригодным для практического использования и этот инструмент. Отсюда 2 предложения:

2.7.1 Строить эллипс в три клика:
- первый клик – указываем один конец первой оси
- второй клик – указываем второй конец первой оси
- мышью растыгиваем вторую полуось и кликаем для завершения.
2.7.2 Сделать отдельный инструмент для рисования кругов и окружностей и строить их в два клика:
- первый клик – указываем один конец диаметра
- втрой клик – указываем второй конец диаметра
в итоге по диаметру строится круг.

Выделение отдельных инструментов "круг" и "окружность" оправдано, т.к. они много более востребованы, чем эллипс.

2.8. При переводе курсора мыши из окна Object Properties на карту, автоматически переводить фокус на карту, при этом автоматически сохраняя все измененные поля, вне зависимости от того нажали на Enter или нет. А то жутко надоели ситуации вида:
- создаем пои
- исправляем поле label
- переносим курсор на поле карты и хотим переключиться на другой инструмент, например на Select Objects, нажав ключевую клавишу, например «S», но если это сделать то буква S пропишется в поле Label, а инструмент не переключится.
- Если для перенесения фокуса на карту нажать левую кнопку мыши, то создастся лишняя POI, которая не нужна
- В итоге приходится тыкать на карту правой кнопкой мыши – появляется контекстное меню
- Затем жмем Escape, чтобы закрыть контекстное меню
- Затем жмем S для переключения инструмента

Как-то все это жутко криво на мой взгляд… Старый вариант, когда надо было делать лишний клик по карте, чтобы переключить фокус, прошу не вспоминать – так тоже было плохо.

Если же открепить окно object Properties, то фокус переносится автоматом, однако данные введенные в поле не сохраняются если забыли или не успели нажать Enter.

Если окно object Properties откреплено, когда используем инструмент Select Objects, выбираем какую-нибудь POI, затем хотим поправить свойства, для переключения фокуса на окно object Properties надо кликнуть по нему два раза. При этом, при выборе линии или полигона, для переключения на окно object Properties достаточно кликнуть по нему только один раз. Иногда при выборе первой POI переключения на object Properties происходит по первому клику, но при выборе следующей POI уже можно переключиться только за два клика.

Все это в совокупности сильно снижает удобство в работе, и на мой взгляд требует доработки.