巨大なXYZ CSVをGeoTIFFに変換する

私はUTM座標を含むCSV形式のデータの膨大な量を持っているXとYように標高値Z情報。さらに分析するには、これらのデータをGeoTIFFとしてDEMに変換する必要があります。この場合、膨大な量は16 mを意味します。行、1つのポイントX、YおよびZ行ごと。点は均等に分布しているため、補間は必要ありません。各ポイントをラスタセルに変換する必要があります。

元のデータにはセパレータがなく、固定列幅が使用されていました。ストリームテキストエディターsedを使用して、固定幅の代わりにセパレーターを使用し、すべてのスペース文字を削除するようにファイル構文を変換する方法を既に考えました。ここからは、通常、私のワークフローからフィーチャクラスを作成することにより、ArcGISのデータをインポートするだろうX、YとZ使用して、データと第2段階としてのGeoTIFFにポイントシェープファイルを変換ポイントラスタにツールを。しかし、私が現在持っているファイルは、このプロセスには大きすぎます。

上記のワークフローの代わりに、効率的な代替手段を探していて、GDALを発見しました。ただし、ではgdal_translate、サポートされているファイルタイプリストで最も近いサポートされている形式はASCIIグリッドですが、カンマ区切りのXYZはありません。もう1つの難点は、UTM座標を持っていることですが、ほとんどの例では10進度座標を使用しているようです。ただし、UTMシステム内にとどまる必要があります（または少なくとも、出力GeoTIFFはUTM座標系にある必要があります）。

したがって、GDALを使用してCSV XYZをGeoTIFFに変換する方法を探していますが、これまでのところ、この正確な問題に対処する例を見つけることができませんでした。いくつかのヒントやコード例があればとても嬉しいです。

— アルネ
ソース

なぜGDALメソッドはEsriメソッドよりも効率的だと思いますか？

— アートワーク21

TIFFのためのXYZ-CSVを使用して、正確な例がここにdocumentaionである：gdal.org/gdal_grid.html

— マット

質問は何ですか？現時点での答えは「はい、GDALを使用して変換できます」です。：}

— bugmenot123

問題は、変換の適用方法です。Matteのコメントは解決策を提供しているようです。これを試してみます。

— アルネ

OK！データの最小限の例を提供できますか？GDALで回答が必要ですか、または他の無料ツール（GMTなど）も同様に大丈夫ですか？

— bugmenot123

回答:

GDALを使用してこれを行うことができ、XYZ形式を直接サポートします。座標がUTMであるかどうかは関係ありません。gdal_translateは同じ座標系で出力します。

GeoTIFFへの変換は次のように簡単です：

gdal_translate test.xyz test.tif

出力オプション（圧縮など）についてはGeoTIFFドキュメントを、使用方法の詳細についてはgdal_translateドキュメントをご覧ください。特に、-a_srsパラメーターで座標系を指定する必要があります。

-a_srs srs_def：

出力ファイルの投影をオーバーライドします。srs_defは、通常のGDAL / OGR形式、完全なWKT、PROJ.4、EPSG：n、またはWKTを含むファイルのいずれかです。

gdal_translate -a_srs EPSG:12345 test.xyz test.tif

ヘッダー行の有無にかかわらず、カンマ/スペースで区切られた固定列幅がサポートされています。

サポートされている列区切り記号は、スペース、コンマ、セミコロン、および表です。

$ head -n 2 test_space.xyz 
x y z
146.360047076550984 -39.0631214488636616 0.627969205379486084

$ gdalinfo test_space.xyz
Driver: XYZ/ASCII Gridded XYZ
Files: test_space.xyz
Size is 84, 66
Coordinate System is `'
Origin = (146.359922066953317,-39.062997159090934)
Pixel Size = (0.000250019195332,-0.000248579545455)
Corner Coordinates:
Upper Left  ( 146.3599221, -39.0629972) 
Lower Left  ( 146.3599221, -39.0794034) 
Upper Right ( 146.3809237, -39.0629972) 
Lower Right ( 146.3809237, -39.0794034) 
Center      ( 146.3704229, -39.0712003) 
Band 1 Block=84x1 Type=Float32, ColorInterp=Undefined
  Min=0.336 Max=0.721 

$ head -n 2 test_commas.xyz 
x, y, z
146.360047076550984, -39.0631214488636616, 0.627969205379486084

$ gdalinfo test_commas.xyz
Driver: XYZ/ASCII Gridded XYZ
etc...

$ head -n 2 test_formatted.xyz
x                       y                       z
146.3600471            -39.06312145             0.627969205

$ gdalinfo test_formatted.xyz
Driver: XYZ/ASCII Gridded XYZ
etc...

私が知っている唯一の落とし穴は次のとおりです。

ドライバーがファイル全体をスキャンしてデータセットのサイズと空間解像度を決定する必要があるため、大きなデータセットを開くのに時間がかかる場合があります。そして

ファイルは（Y、次にXで）正しくソートする必要があります。

同じY座標を持つセルは、連続する行に配置する必要があります。同じY座標値の場合、データセット内の行は、X値を増やして整理する必要があります。ただし、Y座標の値は増減できます。

$ head -n 5 test.csv
x,y,z
146.3707979,-39.07778764,0.491866767
146.3787985,-39.07157315,0.614820838
146.3637974,-39.07132457,0.555555582
146.3630473,-39.07579901,0.481217861

$ gdalinfo test.csv
ERROR 1: Ungridded dataset: At line 3, too many stepY values
gdalinfo failed - unable to open 'test.csv'.

$ tail -n +2 test.csv| sort -n -t ',' -k2 -k1 > test_sorted.xyz

$ head -n 5 test_sorted.xyz 
146.3600471,-39.07927912,0.606096148
146.3602971,-39.07927912,0.603663027
146.3605471,-39.07927912,0.603663027
146.3607971,-39.07927912,0.589507282
146.3610472,-39.07927912,0.581049323

$ gdalinfo test_sorted.xyz
Driver: XYZ/ASCII Gridded XYZ
etc...

— user2856
ソース

私は非常に座標が何であるかを明確にするために、出力にCRSを割り当てることをお勧め：-a_srs EPSG:12345

— bugmenot123

良い点@bugmenot

— user2856

ドイツのオープンデータDGM200：https ://gdz.bkg.bund.de/index.php/default/open-data/digitales-gelandemodell-gitterweite-200-m-dgm200.html

xyzファイルをダウンロードします：https : //daten.gdz.bkg.bund.de/produkte/dgm/dgm200/aktuell/dgm200.utm32s.xyzascii.zip

xyzをGeoTIFFファイルに変換します。

gdal_translate -a_srs utm32s.prj dgm200_utm32s.xyz germanyDGM200.tif

— ホップ
ソース