Это указано самом первом сообщении, а в обсуждении все ответы даны, с полным игнором этого факта. Начать надо было с того, что выяснить КАК так в ГИС не имеющих план-схемы данные TAB-файла попали куда надо. Если есть знание о проекции данных, то задача решается в два хода:
1) сменить СК у вектора - программа приведена выше;
2а) сменить СК у растра. Для QGIS и прочих достаточно создать ПРАВИЛЬНЫЙ VRT. Для Mapinfo сменить одну(или две) строки в текстовом файле.
2б) сменить привязку ВНУТРИ ECW файла на правильную. GDAL где-то имел утилиту для этого. Или просто транслировать "убогий" растр в полноценный через gdal_translate.
---
Да нет в этом никакого ни мучения, ни трагедии. По крайней мере в Mapinfo- 30 секунд на слой, и то это время работы транслятора в MIF (29с) + (1 с) работы строкового редактора - чел/часы не отнимает практически совсем. Регулярно при обмене приходится так делать. Координаты в МСК, в строка проекции NonEarth - нет у начальства желания выставлять свою ... спину для выяснения проблемы - параметры МСК, что лежат в интернете, секретны или уже нет.
PS
Ну по СК = WGS84, тут и без меня прошлись. Прикольно. Достойно. "Убить лопатой - спасти генофонд".Files: 3-4_R_1.ecw
Size is 14285, 14285
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]]
Origin = (2518999.850000000093132,7401999.200000000186265)
Pixel Size = (0.070000000000013,-0.070000000000013)
Но Pixel Size = (0.07,-0.07) Вот это задача! Сколько денег надо будет закопать в привязку снимков такой точности... Там 10000 раз затраты на смены проекции утонут.