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

[Fencer_Silver]

To Vovan_Alm
Спасибо, скачал, и сделал все, как ты просил. Буду смотреть.

[User_tester]

Fencer_Silver,
в МГЕ есть ошибка в экспорте в шейпфайлы! Смысл такой: если в перекрёстке мы прописываем полосность и джанк, то в полученных шейпах выпадает требуемый параметр RSTR для джанка. Только для полосности он есть.

То есть, отсутствует RSTR с записью:
Junction View; Link Id: 46125;

Из-за этого я никак не мог понять, почему у меня джанки не собираются на перекрёстках с полосностью.

[Fencer_Silver]

Fencer_Silver,
в МГЕ есть ошибка в экспорте в шейпфайлы! Смысл такой: если в перекрёстке мы прописываем полосность и джанк, то в полученных шейпах выпадает требуемый параметр RSTR для джанка. Только для полосности он есть.

То есть, отсутствует RSTR с записью:
Junction View; Link Id: 46125;

Из-за этого я никак не мог понять, почему у меня джанки не собираются на перекрёстках с полосностью.

НЕПРАВДА!!!!!

1.png (9.85 КБ) 9358 просмотров

[User_tester]

Правда. В шейпах для LINK_ID=78 имеем:

 

RSTR1 ---> Link ID: 24; Lane Connection: 4>1

RSTR2 ---> Link ID: 32; Lane Connection: 1>1, 2>2, 3>3
SPATH2 ---> C:\JCV\JCV1\1.svg
SLYR2_1 ---> Type: Background; ID: 0; Required: Yes;
SLYR2_2 ---> Type: Arrow; ID: 1; Required: Yes;
SLYR2_3 ---> Type: Sign; ID: 1; Required: No;

RSTR4 ---> Junction View; Link Id: 32;
SPATH4 ---> C:\JCV\JCV1\1.svg
SLYR4_1 ---> Type: Background; ID: 0; Required: Yes;
SLYR4_2 ---> Type: Arrow; ID: 0; Required: Yes;
SLYR4_3 ---> Type: Sign; ID: 0; Required: No;

А должно быть:

 

RSTR1 ---> Link ID: 24; Lane Connection: 4>1

RSTR2 ---> Link ID: 32; Lane Connection: 1>1, 2>2, 3>3

RSTR3 ---> Junction View; Link Id: 24;
SPATH3 ---> C:\JCV\JCV1\1.svg
SLYR3_1 ---> Type: Background; ID: 0; Required: Yes;
SLYR3_2 ---> Type: Arrow; ID: 1; Required: Yes;
SLYR3_3 ---> Type: Sign; ID: 1; Required: No;

RSTR4 ---> Junction View; Link Id: 32;
SPATH4 ---> C:\JCV\JCV1\1.svg
SLYR4_1 ---> Type: Background; ID: 0; Required: Yes;
SLYR4_2 ---> Type: Arrow; ID: 0; Required: Yes;
SLYR4_3 ---> Type: Sign; ID: 0; Required: No;

Выделенная жирным строка отсутствует в шейпах.

[User_tester]

Проанализировал ошибку на более простом примере:

 Первый случай

Имеем:

Код: Выделить всё

RSTR1 ---> Link ID: 46125; Lane Connection: 1>1 (для LINK_ID=47056)
RSTR2 ---> Junction View; Link Id: 46125; (для LINK_ID=47056)
SPATH2 ---> C:\JCV\JCV1\1.svg (для LINK_ID=47056)
...

Всё правильно. Два разных рестрикшена для одной дороги разнесены.

 Второй случай

Имеем:

Код: Выделить всё

RSTR1 ---> Link ID: 46127; Lane Connection: 2>1 (для LINK_ID=47056)
SPATH1 ---> C:\JCV\JCV1\1.svg
...

Ошибка! Рестрикшены, действующие в разных манёврах, не разнесены и один из них пропал. Специально попробовал собрать компилятором - собрал, но без джанка! Потому что для него отдельно не прописан RSTR атрибут.

Должно быть:

Код: Выделить всё

RSTR1 ---> Link ID: 46127; Lane Connection: 2>1 (для LINK_ID=47056)
RSTR2 ---> Junction View; Link Id: 46125; (для LINK_ID=47056)
SPATH2 ---> C:\JCV\JCV1\1.svg
...

 Третий случай

Имеем:

Код: Выделить всё

RSTR1 ---> Link ID: 46125; Lane Connection: 2>2 (для LINK_ID=46127)
RSTR1 ---> Junction View; Link Id: 46125; (для LINK_ID=47056)
SPATH1 ---> C:\JCV\JCV1\1.svg (для LINK_ID=47056)
...

Всё правильно. Разные рестрикшены для разных дорог разнесены.

Сергей, теперь убедил тебя в своей правоте насчёт ошибки?

[DarkDiver]

- Добавлено: игнорирования регистра спец символов ~[0x1c], ~[0x1e],~[0x1f] - для конвертирования, экспорта и отрисовки;

К сожалению не работает конвертирование и отрисовка, для вариантов записи: "~[0X1f]" и "~[0X1F]" (см. скрин и тестовую карту во вложении).
Экспорт работает корректно.

- Добавлено: для
1) Полилинии:
0x20 MINOR_CONTOUR
0x21 INT_CONTOUR
0x22 MAJOR_CONTOUR
0x23 MINOR_BATHY_CONTOUR
0x24 INT_BATHY_CONTOUR
0x25 MAJOR_BATHY_CONTOUR
2) Точки:
0x6300 SPOT_ELEVATION
0x6200 SPOT_SOUNDING
при экспорте в MPC шейпы и установки в шапке карты единиц измерения "метры" - автоматический пересчет в футы;

Эти два пунтка работают корректно. Но они бесполезны без третьего о котором я тоже писал:
"3) Кроме того, как высота интерпретируются числовые надписи после суффикса "~[0x1f]" у точечных объектов, например: "м.Астафьева~[0x1f]156.7"
Эти высоты тоже необходимо конвертировать в футы при экспорте, в противном случае после экспорта получим часть значений высот в футах, часть в метрах, и как следствие - ошибочные высоты после суффиксов в итоговой карте. Прошу допилить

- Добавлено: разрешен признак "показывать направление" не только для дорог, а для любых полилиний.

Большое спасибо, очень полезная доработка, удобнее стало прогнозировать и контролировать как будет выглядеть рисунок у морских линий с атрибутом "Polygon Side", и у линий с не симметричным рисунком - например линии обрыв/обрывистый берег.

Добавлено спустя 7 минут 50 секунд:
Нашел две ошибки:

1) Попробуйте в любой карте в окне "Map Properties", на вкладке cGPSMapper снять галку "Enable Automatic Routing" (кроме этого ни чего больше не менять). Кнопка Save остается не активной. Если сделать "Save As", то данное изменение не сохраняется.

2) Смещены названия категорий у морских линий - см. скрин во вложении.

[Fencer_Silver]

To Vovan_Alm:
Ну ты и задачу подкинул.... В общем ее решил - глубокой переработкой GPX загрузчика. Сейчас грузиться быстро - 24 секунды.

Двигаемся дальше!

Теперь To DarkDiver

К сожалению не работает конвертирование и отрисовка, для вариантов записи: "~[0X1f]" и "~[0X1F]" (см. скрин и тестовую карту во вложении).
Экспорт работает корректно.

Отрисовка - работает только для POI от 0x6400 до 0x6600;
Конвертирование для от 0x6400 до 0x6600 + (НО ОНИ НЕ ДОЛЖНЫ СОДЕРЖАТЬ СИМВОЛА) 0x6200, 0x6300+ полилинии от 0x20 до 0x25

ИСПРАВЛЕНО

Кроме того, как высота интерпретируются числовые надписи после суффикса "~[0x1f]" у точечных объектов, например: "м.Астафьева~[0x1f]156.7"
Эти высоты тоже необходимо конвертировать в футы при экспорте, в противном случае после экспорта получим часть значений высот в футах, часть в метрах, и как следствие - ошибочные высоты после суффиксов в итоговой карте. Прошу допилить

Я написал выше спец. символ могут иметь POI от 0x6400 до 0x6600. Считаю логической ошибкой расставлять (и учитывать его наличие), например у магазинов. Или заправок!

Смещены названия категорий у морских линий - см. скрин во вложении.

Что именно смещено??? У 0x21 - Лабель "100" - не посредине? Это?

Все остальное принимается.

To User_Tester
Сейчас буду смотреть твои замечания

[Baikal]

После работы с большой картой объем 30-50м.
при закрытии приложения
приложение по долгу висит мин 7 бывало
потом закрывается
или только завершением задачи если по быстрому

[MaxBel]

У меня тоже самое. Не кипишую

[Fencer_Silver]

После работы с большой картой объем 30-50м.
при закрытии приложения
приложение по долгу висит мин 7 бывало

Этот вопрос давний. К сожалению, решение пока не найдено. Есть подозрение, что виноваты сторонние компоненты.

[warpig]

После работы с большой картой объем 30-50м.
при закрытии приложения
приложение по долгу висит мин 7 бывало
потом закрывается
или только завершением задачи если по быстрому

Понять, простить и ... подождать!
@Бородач А.Р.

[Alex]

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

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

Версия 1.0.11.549 29.01.2013
- Глубоко переработан алгоритм GPX загрузчика (для путевых точек, треков и маршрутов), что существенно повысило скорость загрузки;
- Исправлено отображение и конвертация спец, сивола ~[0x1f];
- Исправлено экспорт в шейпы дорог, имеющих множественные ограничения (запреты, джанки, полосность);
- Добавлено: в окно редактирование координат - статус-бар в котором указывется позиция курсора по строке;

[DarkDiver]

Кроме того, как высота интерпретируются числовые надписи после суффикса "~[0x1f]" у точечных объектов, например: "м.Астафьева~[0x1f]156.7"
Эти высоты тоже необходимо конвертировать в футы при экспорте, в противном случае после экспорта получим часть значений высот в футах, часть в метрах, и как следствие - ошибочные высоты после суффиксов в итоговой карте. Прошу допилить

Я написал выше спец. символ могут иметь POI от 0x6400 до 0x6600. Считаю логической ошибкой расставлять (и учитывать его наличие), например у магазинов. Или заправок!

В моем примере ни каких запрвок с магазинами не было, только точки из данного диапазона!
Кроме того любые POI могут содержать спецсимвол, вот только числовое значение после него должно интерпретироваться как высота только у точек из упомянутого диапазона

MicroGISEditor обновление v1.0.11.549b
Версия 1.0.11.549 29.01.2013
- Исправлено отображение и конвертация спец, сивола ~[0x1f];

Да, теперь все работает корректно, БОЛЬШОЕ спасибо!

Смещены названия категорий у морских линий - см. скрин во вложении.

Что именно смещено??? У 0x21 - Лабель "100" - не посредине? Это?

Обратите внимание на окно Object Properties на моем скриншоте. Морские линии из диапазона 0x101** имеют категорию Approach Points. Все остальные морские линии тоже имеют не правильную категорию.

[Fencer_Silver]

Обратите внимание на окно Object Properties на моем скриншоте. Морские линии из диапазона 0x101** имеют категорию Approach Points. Все остальные морские линии тоже имеют не правильную категорию.

Ага! Теперь понятно! Поправим!

[DarkDiver]

Опять рано обрадовался... сразу не увидел... значения высот POI после суффикс "~[0x1f]" по прежнему не конвертируются в футы при экспорте в шейпы!

Добавлено спустя 36 минут 7 секунд:
По прежнему не корректно экспортируется тип 0x2b01. Должен экспортироваться как "HOTEL"!
Сейчас вместо него уходит тип 0x2b00, что не правильно.