3

EDIT: this question was not properly answered. An actionable answer should be provided. Maybe involving gdaledit -mo or gdal_translate in.tif in.vrt together with xml manipulations, or any operation which would eventually output a raster GIS with full restored metadata.


I) Given a DEM file which $gdalinfo returns:

+ gdalinfo crop.origin.tif
Driver: GTiff/GeoTIFF
Files: crop.origin.tif
Size is 1920, 1950
Coordinate System is `'
Origin = (66.991666666666674,37.508333333333354)
Pixel Size = (0.016666666666667,-0.016666666666667)
Metadata:
  NC_GLOBAL#Conventions=COARDS/CF-1.0
  NC_GLOBAL#GMT_version=4.4.0
  NC_GLOBAL#history=grdreformat ETOPO1_Ice_g_gdal.grd ETOPO1_Ice_g_gmt4.grd=ni
  NC_GLOBAL#node_offset=0
  NC_GLOBAL#title=ETOPO1_Ice_g_gmt4.grd
  x#actual_range=-180, 180
  x#long_name=Longitude
  x#units=degrees
  y#actual_range=-90, 90
  y#long_name=Latitude
  y#units=degrees
  z#_FillValue=-2147483648
  z#actual_range=-10898, 8271
  z#long_name=z
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  66.9916667,  37.5083333) 
Lower Left  (  66.9916667,   5.0083333) 
Upper Right (  98.9916667,  37.5083333) 
Lower Right (  98.9916667,   5.0083333) 
Center      (  82.9916667,  21.2583333) 
Band 1 Block=1920x2 Type=Int16, ColorInterp=Gray
  NoData Value=-2147483648
  Metadata:
    NETCDF_VARNAME=z

II) I then process this raster tif via ImageMagick, here, for a resizing (but it could be any GIS metadata destroying operation) :

convert crop.origin.tif     -resize $(WIDTH) crop.small.tif

The file has lost its GIS metadata !

III) So, I reinject georeferencing & altitudes :

gdal_translate -a_ullr 44 44 33 33 crop.small.tif crop.tif
gdalinfo -mm crop.tif

But when doing again gdalinfo, the result is really limite :

$gdalinfo crop.tif

result:

Driver: GTiff/GeoTIFF
Files: crop.tif
Size is 1280, 1300
Coordinate System is `'
Origin = (67.000000000000000,37.500000000000000)
Pixel Size = (0.025000000000000,-0.025000000000000)
Metadata:
  TIFFTAG_DOCUMENTNAME=crop.small.tif
  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
  TIFFTAG_XRESOLUTION=72
  TIFFTAG_YRESOLUTION=72
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  67.0000000,  37.5000000) 
Lower Left  (  67.0000000,   5.0000000) 
Upper Right (  99.0000000,  37.5000000) 
Lower Right (  99.0000000,   5.0000000) 
Center      (  83.0000000,  21.2500000) 
Band 1 Block=1280x3 Type=UInt16, ColorInterp=Gray

There are important metadata lost. Most of them could be recalculated, but were not.

enter image description here


QUESTION : how to restore full metadata into an processed raster file which lost its metadata ?

4
  • Punctually, I could resize with a specific gdal tool (which?). But I doesn't solve the issue of getting obvious metadata such z#actual_range back after heavy image processing. – Hugolpz Aug 7 '14 at 18:49
  • 1
    Probably the easiest thing to do is use gdal_translate to get the resized image, but if you do need to use imagemagick, try translating your raster to a .vrt: gdal_translate in.tif in.vrt. That XML document should include all the relevant metadata, including the coordinate reference system, et cetera. You'll have to manually recompute differences based on transformations like resizing if that's being preformed outside of the GDAL context. – scw Aug 7 '14 at 19:18
  • @scw I think this is worth a valid answer. – AndreJ Aug 8 '14 at 5:12
  • @AndreJoost OK, added it as an answer. You're right that for the GeoTIFF format, the .aux.xml should be sufficient as well. – scw Aug 8 '14 at 15:55
4

Probably the easiest thing to do is use gdal_translate to create the resized image with something like:

gdal_translate -outside 50% in.tif in.small.tif

But if you do need to use ImageMagick, try translating your raster to a VRT first:

gdal_translate in.tif in.vrt

The resulting XML document should include all the relevant metadata, including the coordinate reference system, and extent. You'll still have to manually recompute differences based on transformations like resizing if that's being preformed outside of the GDAL context, since GDAL can't infer these changes, but this should work well if you're doing other kinds of image analysis while keeping the raster to the same extent.

3
  • Ok, what you propose is to 1. create a xml with that data, 2. to use a set of cat file.xml | grep <commands> to get these data back, 3. to reinject them into the processed image (how). Right ? – Hugolpz Aug 8 '14 at 16:05
  • 1
    If you create the VRT file, you can edit it and set the data source to a new file -- so if you created a 'from-imagemagick.tif' that has the same spatial extent, and edited the VRT to point at that file, you'll be able to use it in GDAL as before. – scw Aug 8 '14 at 16:08
  • Bumping back into this issue, I think it was not properly answered. An actionable answer should be provided. Maybe involving gdaledit -mo or other operation whic would output a raster with full metadata. cc @scw if you are still active in this field. – Hugolpz Sep 8 '20 at 12:02
2

If you save the Geotiff to png format using gdal_translate, an additional file with the extension.aux.xml will be written. It contains the metadata that your target format does not know.

So it should be possible to process your image with ImageMagick, and use the information in the .aux.xml file afterwards.

0
2
+50

In order to copy metadata you have to add to the gdal_translate command the flags -mo key="value".

If you were not using ImageMagik, you could copy them directly. But since you lost them using that tool, you would need to read the metadata from the original image, and copy it back. Possible with bash, but much easier with Python and rasterio.

import rasterio
import os

original_image='path to image with info'
modified_image='path to image modified with Image Magik'
output_image='Final image' 
tags_str = ''

with rasterio.open(original_image) as src:
    tags = src.tags()
    for k, v in tags.items():
        tags_str += f'-mo {k}="{v}" '
gdal_cmd = (
    f"gdal_translate -of GTIFF -co COMPRESS=DEFLATE -co PREDICTOR=2 "
    f"{tags_str} "
    f"-co ZLEVEL=9 {modified_image} {output_image}"
)
os.system(gdal_cmd)

Of course you need to substitute accordingly original_image, modified_image and output_image

3
  • Yes, sill a valid answer. Hunger to see that. – Hugolpz Sep 16 '20 at 6:11
  • Thanks for this script. I will see if i use it as python or migrage it to bash somehow. Thanks for the help. – Hugolpz Sep 16 '20 at 16:46
  • Can you add comments : what type of file should we use .tif, .shp, .vrt ? What are k and v ? tag title-key and tag content-value ? I think I get what you do. Nice ! – Hugolpz Sep 16 '20 at 17:11
0

Tif files have predetermined tags for the metadata, and the entries that you have are not standard.

In your case, your original file has a set of NetCDF metadata tags, which indeed disappear when you further work with TIF. As mentioned here , Other non standard metadata items can be stored in a TIFF file created with the profile GDALGeoTIFF (the default, see below in the Creation issues section). Those metadata items are grouped together into a XML string stored in the non standard TIFFTAG_GDAL_METADATA ASCII tag (code 42112). Those metadata would not be used in GIS software anyway.

What is more important is that the coordinate system of your file is not specified, and that you lose the geotransform. In a tif file (no need to create a new file), this can be solved using gdal_edit.

gdal_edit -a_ullr 67 37.5 99 5 

Still you don't have a coordinate system, and the coordinate system was not specified in your original file. (** Coordinate system is '' **)

My guess is that the data is in WGS84 (you are obviously in a geographic coordinate system and this is the most common), but this has to be checked. To set up a coordinate system, you can use (example with the EPSG code of WGS84):

gdal_edit -a_srs EPSG:4326 

This is the kind of information that you need for subsequent use in a GIS.

1
  • thanks for this explainations. Also, I'am looking for a procedural answer to copy the initial metadata somewhre, so when my raster lose them, metadata could "reinject" them into the final raster. From what I understand, your solution will lose some of the original metadata. – Hugolpz Sep 10 '20 at 20:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.