Импорт TIFF и публикация RSW на веб-сервисе

Чудеса продолжаются, но теперь с разоблачениями.

Отчаявшись импортировать растр из TIF с привязкой по файлу TAB теми функциями, которые предлагает API Панорамы (навроде picexLoadTiffToRstAndCompressExUn и тому подобных, имеющих параметр //    flagIgnoreGeoTiff - (0/1) флаг игнорирования GeoTiff тегов) решил пойти иным путём. Функции эти все до единой возвращают ноль, но picexGetLastError тоже возвращает ноль, то есть установить причину ошибки невозможно. Ну, всё как обычно, к этому уже начинаю привыкать.

Так вот, решил сначала конвертнуть TIF в JPG, а потом уже получившийся растр без всяких геопривязок внутри импортировать со своим файлом привязки. Для конвертирования использую GDALTranslate. Получил растр jpeg, прописал имя файла в файл привязки и вижу новое чудо - при импортировании таким образом любого TIF с одним и тем же файлом привязки они привязываются не туда, куда файл привязки указывает, а туда, куда указано в TIF. Но ведь я уже сконвертировал TIF в JPEG,эти данные утрачены! В чём дело?

А дело оказалось вот в чём. GDAL при конвертировании сгенерил помимо растра JPEG ещё и некий файл с именем filename.jpg.aux.xml, в котором записаны всякие данные для привязки. А Панорама при импорте этот файл прочла и привязала туда, куда указано в этом файле, файл же привязки filename.tab, лежащий рядом с filename.jpg проигнорирован начисто. И это при том, что про функцию picexLoadRasterToRswUn написано:
Про файл filename.jpg.aux.xml, обращаю внимание, ни намёком не упомянуто. Т.е. функция ведёт себя совершенно не так, как написано.

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

Стыдоба.

Задача стояла импортировать графические файлы не с помощью  «ГИС Панорама Мини» для Linux, а своей программой - модулем к appservice. Панорама Мини использовалась только как подручное средство для просмотра сконвертированных файлов, генерации файлов привязки, проверки работоспособности подходов к решению задачи.

Так что если библиотеки, реализующие API остались без изменения, а просто в Панораме Мини сделан некий костыль, выполняющий конвертацию, то к решению задачи мы не приблизились ни на шаг.

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

Здравствуйте. Совершенно неясно, как воспользоваться этой функцией в принятом алгоритме решения задачи. Вы обратите внимание на первое сообщение - откуда взяться параметрам для вызова этой функции?

Можете Вы сюда запостить фрагмент того кода, который иллюстрирует решение задачи, на котором Вы проверяли, что с этой функцией всё сработает?

С координатами вопросов нет. Есть вопросы по первым двум параметрам. Первый, hMap, должен быть ссылкой на открытую карту, наличие которой не предусматривается алгоритмом конвертации, который я описал в начале темы. Второй параметр тоже непонятно откуда взять. Вы всё-таки почтите первое сообщение темы, чтоб нам в одном контексте беседовать.
Думаю, в этом нет необходимости. В панорамовском API есть функции для вычитывания данных из файлов привязки. Они ведь корректно работают под Astra Linux SE, не так ли?
Я, конечно, имею ввиду сертифицированную версию.