Convertir un énorme CSV XYZ en GeoTIFF

11

J'ai une énorme quantité de données sous la forme de CSV contenant les coordonnées UTM en Xet Yet une valeur d'élévation comme Zinformation. J'ai besoin de convertir ces données en DEM en tant que GeoTIFF pour une analyse plus approfondie. Dans ce cas, une énorme quantité signifie 16 m. lignes, avec un point dans X, Yet Zpar ligne. Les points sont également répartis, donc une interpolation n'est pas nécessaire; chaque point doit simplement être converti en cellule raster.

Les données d'origine étaient fournies sans séparateur, avec des largeurs de colonne fixes. J'ai déjà compris comment convertir la syntaxe du fichier pour utiliser un séparateur au lieu de largeurs fixes et éliminer tous les caractères d'espace, en utilisant l'éditeur de texte de flux sed . A partir de là, normalement mon flux de travail serait d'importer les données dans ArcGIS en créant une classe d'entités des X, Yet des Zdonnées et en tant que deuxième étape, la conversion du point shapefile en GeoTIFF, en utilisant le point à Raster outil. Cependant, le fichier que j'ai actuellement est trop volumineux pour ce processus.

Au lieu du workflow décrit ci-dessus, je cherchais une alternative efficace et j'ai découvert GDAL. Cependant, dans gdal_translate, le format pris en charge le plus proche que je peux trouver dans la liste des types de fichiers pris en charge, est la grille ASCII mais pas de XYZ séparé par des virgules. Une autre difficulté est que j'ai des coordonnées UTM , alors que la plupart des exemples semblent utiliser des coordonnées en degrés décimaux. Cependant, je dois rester dans le système UTM (ou au moins, ma sortie GeoTIFF doit être dans un système de coordonnées UTM).

Je cherche donc un moyen de convertir le CSV XYZ en GeoTIFF, en utilisant GDAL , mais jusqu'à présent je n'ai pas pu trouver d'exemples traitant de ce problème exact. Je serais très heureux pour quelques conseils ou même des exemples de code.

gdal geotiff-tiff csv gdal-translate xyz Arne
la source
Pourquoi pensez-vous que la méthode GDAL serait plus efficace que la méthode Esri?
artwork21
L'exemple exact de l'utilisation d'un xyz-csv pour un tiff est dans la documentaion ici: gdal.org/gdal_grid.html
Matte
Quelle est exactement la question? En ce moment, la réponse est "oui, vous pouvez utiliser GDAL pour convertir". :}
bugmenot123
La question est de savoir comment appliquer la conversion. Le commentaire de Matte semble fournir la solution - je vais essayer cela.
Arne
D'accord! Pouvez-vous fournir un exemple minimal de données? Voulez-vous une réponse dans GDAL ou d'autres outils gratuits (par exemple GMT) seraient-ils également acceptables?
bugmenot123

Réponses:

16

Vous pouvez le faire en utilisant GDAL, il prend directement en charge le format XYZ . Peu importe si vos coordonnées sont UTM, gdal_translate sortira dans le même système de coordonnées.

Donc, convertir en GeoTIFF est aussi simple que:

gdal_translate test.xyz test.tif

Regardez le doc GeoTIFF pour les options de sortie (comme la compression) et le doc gdal_translate pour plus d'informations d'utilisation. En particulier, vous devez spécifier le système de coordonnées avec le -a_srsparamètre.

-a_srs srs_def:

Remplacez la projection du fichier de sortie. Le srs_def peut être l'un des formulaires GDAL / OGR habituels, compléter WKT, PROJ.4, EPSG: n ou un fichier contenant le WKT.

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

Les largeurs de colonne séparées par des virgules / espaces et avec ou sans ligne d'en-tête sont prises en charge.

Les séparateurs de colonnes pris en charge sont l'espace, la virgule, le point-virgule et les tabulations.

$ 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...

Les seuls problèmes que je connaisse sont:

  1. L'ouverture d'un ensemble de données volumineux peut être lente car le pilote doit analyser l'intégralité du fichier pour déterminer la taille de l'ensemble de données et la résolution spatiale; et

  2. Le fichier doit être trié correctement (par Y, puis X).

    Les cellules avec les mêmes coordonnées Y doivent être placées sur des lignes consécutives. Pour une même valeur de coordonnée Y, les lignes de l'ensemble de données doivent être organisées en augmentant les valeurs X. Cependant, la valeur de la coordonnée Y peut augmenter ou diminuer. 

    $ 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
la source
2
Je suggérerais fortement d'assigner un CRS à la sortie pour clarifier quelles sont les coordonnées:-a_srs EPSG:12345
bugmenot123
1
Bon point @bugmenot
user2856