1

I need to unify many raster tiles of global land use (856 tiles, in a total of 297 GB, single band, 8 bite unsigned integer, WGS84) in a single file, I chose geopackage because of the high dimensions.

I tried using the following steps:

  1. building a GDAL virtual raster with all the tiles (Parameters: NOT checking the separate band option, high resolution, resempling=mode)

  2. converting it into a geopackage by means of gdal_translate:

gdal_translate -of GPKG -co QUALITY=100 -b 1 -mask 1 -r mode -a_offset value input.vrt output.gpkg

but the output has the following errors:

  • there are some pixels with a wrong value
  • the output raster has 4 bands (3 with the same values and the last with NoData, 255)

I noted that in every passage there is a shift of the pixels, a sort of cell value resampling, despite mode resampling should select the value which appears most often of all the sampled points.

How it is possible to create a single file with exactly the same pixels and parameter as the input rasters?

The original raster tile:

![original raster tile

the same tile converted to virtual raster (info on the same cell):

![the same tile converted to virtual raster

the final GPKG output (info on the same cell):

enter image description here

In the GPKG there is a wrong new cell value (for ex. 41 instead of 40) and 4 bands instead of 1.

Note that despite the partial wrong output (some wrong pixel values and presence of 4 bands instead of 1), from a dataset of 297 GB I obtained a geopackage of 10 GB for the southern hemisphere and 34 GB for the northern hemisphere!

Improve this question
  • is your input using the same coordinate system? – Johan Feb 19 '20 at 15:56
  • yes, all in WGS84 – chiarar Feb 19 '20 at 15:57
  • If you check the pixel size on a couple of your input files, you will probably see that they vary slightly. This is because the length of a degree longitude decreases with the distance from the equator. When GDAL creates a single mosaic, all individual files must be resampled to a common pixel size, thus explaining the shift in pixels. There is no way to avoid this, short of producing the data in a global mercator projection (like EPSG:3857). – Matsamentet Feb 24 '20 at 10:32
  • The problem is not much the positional shift but the shift of values: the values correspond to a land-use classification, so changing of values leads to errors. (I have updated the post with a picture of the final GPKG output, that shows better the problem). – chiarar Mar 3 '20 at 8:57

Your Answer

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

Browse other questions tagged or ask your own question.