[gdal-dev] Weird issue when running gdaltranslate

[Travis Kirstine]

I think something is wrong in you vrt file.  The number of pixels seems
extremely high 2147483647 x 2147483647.  This would result in a huge
geotiff ~ 4611686014132420609 bytes.  A regular geotiff is limited to 4 GB
in size.  This can be increased with Big Tiff support.


On 1 April 2014 03:31, <Moses.Gone at t-systems.com> wrote:

>  Hi everyone,
> I am getting this weird error when I try to convert a vrt to a tif.
>
> Some context: We are tiling a set of tifs(in a list file). First we
> generate a vrt from the list. Then we assign a projection on the generated
> vrt using gdaltranslate. We then clip the output using gdalwarp applying a
> clipping at the same time to the desired BBOX(This is achieved using the
> -te option). In the warp operation we also specify the target SRS(using the
> -t_srs option). Lastly we tile using our customized gdal_retile.py. All is
> fine with the projection and clipping, but the resultant tiles are empty-no
> data just white images.
>
> So I tried to backtrack my steps, to check at what point is the data being
> lost. Generation of the VRT works fine. However, performing gdaltranslate
> to assign the source SRS on the VRT result into this error:
>
> bash-2.05$ gdal_translate -of GTiff ffm_dtk200_wdd.vrt test.tif
> Input file size is 2147483647, 2147483647
> 0ERROR 1: GTiffCreateCopy():No space for strip arrays
> ERROR 1: MissingRequired:TIFF directory is missing required "StripOffsets"
> field
> ERROR 1: MissingRequired:TIFF directory is missing required "StripOffsets"
> field
>
> I tried to also convert to AAIGrid format, thinking that something is
> wrong converting to Tiff, but also got this error:
>
> bash-2.05$ gdal_translate -of  AAIGrid ffm_dtk200_wdd.vrt test3
> Input file size is 2147483647, 2147483647
> 0ERROR 1: CPLMalloc(-4): Silly size requested.
>
> ERROR 1: ffm_dtk200_wdd.vrt, band 1: The buffer into which the data should
> be read is null
> Segmentation Fault
>
> Other tiling jobs following a similar method, with different source data
> works fine though. Could the problem be with the data? If so how comes it
> worked before?
>
> Regards,
> Moses
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140401/8bc602ac/attachment.html>