На главную... Продукты | Технологии | Классификаторы | Проекты | Скачать | Цены| Форум | Статьи | Обучение | Контакты

[MAPAPI] Ошибки в функциях по привязке/конвертации/оптимизации растров

Поиск  Пользователи  Правила  Войти
Форум » Linux » Средства разработки ГИС-приложений для Linux
Страницы: 1
RSS
[MAPAPI] Ошибки в функциях по привязке/конвертации/оптимизации растров, [MAPAPI] Ошибки в функциях по привязке/конвертации/оптимизации растров
 
Здравствуйте.

У меня тут появились вопросы/замечания по функциям привязки/конвертации/оптимизации растров. Пакет gisdiesigner 12.6.0.
Код
//========================================================================
// Привязка растра с масштабированием и поворотом по двум точкам  
//
// hmap        - карта, содержащая векторные данные;
// handle      - диалог визуального сопровождения процесса обработки.
// rswnamein   - имя исходного файла растра
// rswNameOut  - имя выходного файла растра (размер строки д.б. не менее MAX_PATH_LONG байт)
// pointmet1   - Координаты первой точки  в метрах
// pointmet1   - Координаты первой точки в метрах
// pointmet2   - Координаты второй точки  в метрах
// pointmet2   - Координаты второй точки в метрах
// message     - флаг на выдачу сообщений (0\1)
//
//    Диалогу визуального сопровождения процесса обработки посылаются
//    сообщения:
//    -  (WM_PROGRESSBAR) Извещение об изменении состояния процесса
//       WPARAM - текущее состояние процесса в процентах (0% - 100%)
//       Если функция-отклик возвращает WM_PROGRESSBAR, то процесс завершается.
// При ошибке возвращает ноль
//========================================================================
_PICIMP long int _PICAPI AttachRswWithScalingAndRotationEx(HMAP hmap, HMESSAGE handle,
                                             const char* rswnamein, char* rswnameout,
                                             DOUBLEPOINT *pointmet1, DOUBLEPOINT *pointmetnew1,
                                             DOUBLEPOINT *pointmet2, DOUBLEPOINT *pointmetnew2,
                                             int message);

1) Параметр message  игнорируется. Если Вам действительно хочется не выдавать сообщения, требуется обрамлять вызов AttachRsw... вызовами mapMessageEnable(0); mapMessageEnable(1);
2) Если имя исходного растра равно имени выходного растра - функция отработает, и создаст копию исходного файла в виде резервной копии (*.~rw)
   В комментарии про это ни слова. Ни про резервную копию, ни про то, что можно отдавать одинаковые имена.
3) Если имя исходного растра (к примеру, A.rsw) не равно имени выходного растра (B.rsw), то вызов AttachRsw... выполнит привязку и создаcт файл B.rsw, удалит (!!!) A.rsw, выдаст сообщение
Код
[11:23:31.849 /D]: MsgBoxCall msg: Ошибка записи файла - 
Файл или каталог не существует title: Обработчик ошибок flag: 8208
и вернёт 0 - то есть завершится с ошибкой.  Зачем удаляется исходный файл? Почему про это не сказано в комментарии к функции AttachRsw...? Не понятно, в общем.
4) Второй и третий пункты происходят в случае, когда в качестве HMAP отдаётся векторная карта, на которую в качестве растрового слоя добавлен(в цепочку растров) исходный растр.
  То есть при выполнении второго пункта я наблюдаю следующее поведение - исходный растр закрывается, привязывается (создаётся новый файл по сути), который потом открывается(добавляется в цепочку) с настройками по-умолчанию (под картой, прозрачность 100%) - в комментариях про это ни слова. У меня в интерфейсе (UI) в списке слоёв остаётся висеть слой с свойствами (над картой/прозрачность 100%), хотя по факту он уже под картой.
  При выполнении третьего пункта я не знаю что происходит. Удаляется ли из цепочки растров исходный растр (исходный файл ведь удаляется всё таки).



Код
//==============================================================================
//    Трансформирование растра                               
// (вычисление коэффициентов пересчета координат методом наименьших квадратов)
//
//   handle    - диалог визуального сопровождения процесса обработки;
//   map       - карта,содержащая векторные данные;
//   parm      - параметры прикладной задачи;
//   namein    - имя исходного растра (MAX_PATH_LONG)
//   nameout   - имя выходного растра (размер выделенной памяти д.б. не менее MAX_PATH_LONG символов)
//   fact      - исходные координаты опоры;
//   teor      - желаемые координаты опоры;
//   count     - количество опорных точек (не меньше 4-х).
//
//   Диалогу визуального сопровождения процесса обработки посылаются сообщения:
//   -  (WM_PROGRESSBAR) Извещение об изменении состояния процесса
//      WPARAM - текущее состояние процесса в процентах (0% - 100%)
//      Если функция-отклик возвращает WM_PROGRESSBAR, то процесс завершается.
// При ошибке возвращает ноль,
//==============================================================================
_PICIMP long int _PICAPI RswTransformingBySquareMethod(HMAP map,HMESSAGE handle,
                           TASKPARMEX * parm, const char * namein, char * nameout,
                           long int count,DOUBLEPOINT * fact,DOUBLEPOINT * teor);
1) Откуда брать TASKPARMEX? На данный момент я отдаю туда nullptr.
2) Если имя исходного растра равно имени выходного растра, то исходный растр заменяется на пустой rsw файл (туда что-то записывается, он занимает 11.6 kB), функция возвращает 0 - произошла ошибка. В комментарии про это ни слова.


Код
//========================================================================
//    Оптимизировать файл растровой карты с возможным сжатием изображения
//    handle         - диалог визуального сопровождения процесса обработки.
//    name           - имя файла растровой карты
//    newname        - имя файла оптимизированной растровой карты
//    compressnumber - номер алгоритма сжатия блоков изображения
//                     0 - не использовать сжатие
//                     1 - алгоритм сжатия LZW
//    flagborder     - флаг использования рамки растровой карты
//                     0 - включать в формируемый файл все блоки изображения
//                     1 - не включать в формируемый файл блоки изображения,
//                         не входящие в область, ограниченную рамкой
//    При ошибке возвращает ноль
//
//    Диалогу визуального сопровождения процесса обработки посылаются
//    сообщения:
//    -  (WM_PROGRESSBAR) Извещение об изменении состония процесса
//       WPARAM - текущее состоние процесса в процентах (0% - 100%)
//       Если функция-отклик возвращает WM_PROGRESSBAR, то процесс завершается.
//
//    -  (WM_ERROR) Извещение об ошибке
//       LPARAM - указатель на структуру ERRORINFORMATION
//       Структура ERRORINFORMATION описана в picexprm.h,
//       WM_PROGRESSBAR и WM_ERROR - в maptype.h
//========================================================================
_PICIMP long int _PICAPI LoadRstOptimization(HMESSAGE handle,
                                    const char* name, const char* newname,
                                    long int compressnumber,
                                    long int flagborder);

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

1) Параметр compressnumber может быть равным 2 - тогда будет использоваться алгоритм сжатия JPEG с параметром сжатия 60
2) После оптимизации (не важно, по LZW или Jpeg, не важно, каким из двух предыдущих способов был привязан растр) не важно, используете вы mapShowRstByBorder после открытия или нет - сжатый растр отображается целиком - не только блоки внутри рамки, но и блоки вне рамки, которых физически нет - в секции описатели блоков файла RSW (на бинарном уровне, в соответствии с описанием формата с сайта) просто нет некоторых блоков (их там и не должно быть, их не было в исходном растре) - пары смещение размер забиты нулями. При этом запись "Рамка" корректно заполнена, а флаг отключения рамки выставлен в 0 - то есть рамка не используется, но при этом я делаю вызов mapShowRstByBorder после каждого добавления нового растра в цепочку растров. И всё равно вокруг рамки (снаружи) либо чёрные блоки, либо блоки с артефактами.


Последовательность действий следующая - берётся изображение (jpg), выбирается целевая векторная карта, параметры СК которой будут использоваться как параметры СК растра.
Изображение загружается в rsw с помощью picexLoadRasterToRsw - в процессе работы этой функции сначала изображение загружается в rsw, затем rsw оптимизируется (может быть, сжимается, может быть, нет, не смотрел).
Потом я выставляю этому растру проекцию и привязку в центр целевой карты (mapSetRstProjectionData, mapSetRstLocation).

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

Если пользователь привязывает карту - сначала выполняется привязка по 2 или 4+ точкам (два способа описанные вначале, AttachRsw..., RswTransformingBySquare...),
потом запускается оптимизация (LoadRstOptimization), которая почему-то ломает отрисовку растров - появляются чёрные блоки за рамкой.

Все описанные особенности, кроме чёрных блоков за рамкой, я могу обойти. А вот чёрные блоки за рамкой после оптимизации - не могу.
 
Здравствуйте!

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

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

Спасибо!
 
Здравствуйте.

Я вроде разобрался.

Если вместо LoadRstOptimization использовать LoadRstOptimizationAndCompress и открывать растр, который необходимо оптимизировать, на основной карте до вызова функции оптимизации, то у сжатого растра не будет чёрных блоков за рамкой.
 
На наших устройствах стоит специальная версия gisdesigner, собраная по нашему заказу, и там поведение функции AttachRswWithScalingAndRotationEx уже другое.

Версия 12.5.* насколько я помню.

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

То есть при переходе с 12.5.* на 12.6.* поведение функции AttachRswWithScalingAndRotationEx было изменено. И никак об этом узнать из описания функции нельзя =(


При этом на устройствах все ок, результат без чёрных квадратов.
На своём хосте на Ubuntu16, когда я поставил пакет 12.5.1.201 без поддержки трансформации растров на лету, я получаю в конце растр с чёрными квадратами за рамкой и падение при зуме с таким stacktrace:
Код
1 TRmf::GetRswPointByBorder(int&, int, int, int&, char * *, TPaintControl&, TRmfBlockCache *)                      0x7fffb2d8039e 
2 MoveRmfPoint(TRANSFORMRMFSHOW&, int, int, int, char *)                                                           0x7fffb2de62fa 
3 ShowTransformRmfThread(void *)                                                                                   0x7fffb2ddf328 
4 start_thread                                                                                pthread_create.c 333 0x7ffff561b6ba 
5 clone                                                                                       clone.S          109 0x7ffff593841d 


В процессе привязки ещё вижу попытки спросить пользователя нужно ли трансформировать растр:

Код
[09:12:03.249 /W]: MsgBoxCall msg: Карта и растр имеют разные параметры проекции.
 /home/vegorov/testsMaps/rsw/spb_test_bind/SPb.rsw.1_TMP.rsw 

 Трансформировать растр? title: Открытие растра flag: 8227
[09:12:05.167 /W]: MsgBoxCall msg: Карта и растр имеют разные параметры проекции.
 /home/vegorov/testsMaps/rsw/spb_test_bind/SPb.rsw 

 Трансформировать растр? title: Открытие растра flag: 8227


Привязка по 4 и более точкам на 12.5.* и на 12.6.* работает одинаково и ничего не падает. По крайней мере, если сравнивать 12.5.* на наших устройствах и 12.6.* с сайта.
 
Здравствуйте!

В ближайшее время уточним данное поведение. Спасибо!
 
Здравствуйте, Владимир!

Использование флага на выдачу сообщений в функции AttachRswWithScalingAndRotationEx будет дорабатываться.  Описанный Вами способ с использованием функции запрета выдачи сообщений на экран _MAPIMP long int _MAPAPI mapMessageEnable(long int enable) является приемлемым.

Мы внесли исправления: теперь, если имя выходного растра не задано или совпадает с исходным именем,  будет перезаписан исходный файл, с сохранением резервной копии исходного файла.  
Описание данного поведения добавлено в комментарии к функциям AttachRswWithScalingAndRotationEx, RswTransformingBySquareMethod , MtwTransformingBySquareMethod и MtqTransformingBySquareMethodUn .

Новая версия ГИС Конструктор для Astra Linux SE c описанными выше исправлениями доступна для скачивания на сайте.

Пожалуйста, протестируйте поведение функции LoadRstOptimization, в новой версии. Если описанное Вами поведение повторяется, то для проведения диагностики потребуются дополнительные данные: пример, воспроизводящий проблему, а также исходный и полученный вами растр.

Спасибо!

Страницы: 1
Читают тему (гостей: 1)



© КБ Панорама, 1991-2024

Регистрируясь или авторизуясь на форуме, Вы соглашаетесь с Политикой конфиденциальности