Как сохранить исходную растровую проекцию при использовании gdal_translate? - PullRequest
0 голосов
/ 02 мая 2019

В настоящее время я работаю над небольшим инструментом для растра.Цель состоит в том, чтобы иметь простой инструмент CLI, чтобы вычислять плитки из исходного растра с географической привязкой и создавать соответствующий index.shp.Для этого я использую Python 3.7 и GDAL.Инструмент работает гладко и генерирует ожидаемые листы и шейп-файл, но он избавляется от проекции, которая сохраняется в исходном растре.Qgis по умолчанию рассчитывает новые плитки на EPSG 4326, информируя меня о неизвестной проекции.Исходный растр находится в EPSG 25832.

Моя настройка:

Windows 10 64 бит

Python 3.7.2

Гдал Я не могу получить доступ к конкретной версии, поскольку gdal-config не установлен, и я не могу заставить его работать, но он 64-битный, и я установил его через двоичные файлы, предоставленные на gisinternals.com.Список программного обеспечения Windows гласит: GDAL 204 MSVC 2017.

Во время работы скрипта я получаю сообщения об ошибках, в которых говорится о отсутствующих файлах, например, pcs.csv, datum.csv ellipsoid.csv и так далее.Это указывает на то, что наличие этих файлов решит мою проблему.Но, как ни странно, я использовал Osgeo4W для установки Python 2.7 с gdal, и он работает как шарм, конечно, настроив части Python.Плитки рассчитываются и остаются в проекции источника.Без каких-либо внешних файлов, которые определяют проекцию, фактически используя те же самые данные, которые меня действительно смущают.

Насколько я понимаю, нет флага или опции, которая заставляет gdal сохранять проекцию.Если вы пропустили или неправильно поняли документы, я рад советам.

Прежде чем кто-либо спросит, я знаю, что использование установщика osgeo4w, очевидно, является простым и работающим решением.Но, имея в виду, что Python 2.7 скоро будет снят с производства, а также использовать его как возможность узнать что-то новое, я хотел создать инструмент на основе 3.7 с установленным на моей машине gdal

Соответствующий код выглядит так и делаетследующее:

1.) Строка команды является сборкой

2.) Строка передается в os.system, которая, в свою очередь, выполняет соответственно

    for i in range(0, width, tilelenght):
        y = 0
        for j in range(0, height, tilelenght):
            gdaltranString = f'gdal_translate -of GTIFF -srcwin {i}, {j}, {tilelenght}, {tilelenght} {input_filepath} {output_filepath}{x}_{y}.tif'
            subprocess.run(gdaltranString)
            y = y+1
        x = x+1

Ожидаемый результат, будет набором функциональных файлов .tif, имеющих код EPSG исходного файла, в данном случае 25832.

Но, как уже упоминалось, проекция теряется где-то в процессе.

1 Ответ

0 голосов
/ 06 мая 2019

Итак, я нашел решение своей проблемы, не понимая с самого начала, как она стала проблемой.

Решением было создание пользовательской переменной GDAL_DATA с путемк файлам определения проекции.

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

Если кто-тознает больше о таинственных способах системных переменных Windows, пожалуйста, поделитесь своей мудростью или источником этой мудрости.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...