[gdal-dev] gdaladdo slowness for VRTs
Denis Rykov
rykovd at gmail.com
Tue Jun 4 18:35:38 PDT 2024
Hi,
I spotted a slow calculation of overviews and I'm wondering what could be
the reason.
$ gdal_create in.tif -if 20240602_230818_SN26_RR_VISUAL_MS.vrt
$ time gdaladdo -ro in.tif
gdaladdo -ro in.tif 4,25s user 6,23s system 34% cpu 30,623 total
But on the file of the same size and num of bands but VRT it takes much
more time:
$ time gdaladdo -ro 20240602_230818_SN26_RR_VISUAL_MS.vrt
gdaladdo -ro 55,36s user 5,06s system 44% cpu 2:14,79 total
Here is the output of gdalinfo of the VRT:
$ gdalinfo 20240602_230818_SN26_RR_VISUAL_MS.vrt
Driver: VRT/Virtual Raster
Files: 20240602_230818_SN26_RR_VISUAL_MS.vrt
20240602_230818_SN26_RR_VISUAL_MS_340_5020.tif
20240602_230818_SN26_RR_VISUAL_MS_340_5040.tif
20240602_230818_SN26_RR_VISUAL_MS_360_5020.tif
20240602_230818_SN26_RR_VISUAL_MS_360_5040.tif
20240602_230818_SN26_RR_VISUAL_MS_360_5060.tif
Size is 20779, 46754
Coordinate System is:
PROJCRS["WGS 84 / UTM zone 59S",
BASEGEOGCRS["WGS 84",
DATUM["World Geodetic System 1984",
ELLIPSOID["WGS 84",6378137,298.257223563,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4326]],
CONVERSION["UTM zone 59S",
METHOD["Transverse Mercator",
ID["EPSG",9807]],
PARAMETER["Latitude of natural origin",0,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8801]],
PARAMETER["Longitude of natural origin",171,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8802]],
PARAMETER["Scale factor at natural origin",0.9996,
SCALEUNIT["unity",1],
ID["EPSG",8805]],
PARAMETER["False easting",500000,
LENGTHUNIT["metre",1],
ID["EPSG",8806]],
PARAMETER["False northing",10000000,
LENGTHUNIT["metre",1],
ID["EPSG",8807]]],
CS[Cartesian,2],
AXIS["easting",east,
ORDER[1],
LENGTHUNIT["metre",1]],
AXIS["northing",north,
ORDER[2],
LENGTHUNIT["metre",1]],
ID["EPSG",32759]]
Data axis to CRS axis mapping: 1,2
Origin = (353999.799999999988358,5068000.629999999888241)
Pixel Size = (0.770000000000000,-0.770000000000000)
Corner Coordinates:
Upper Left ( 353999.800, 5068000.630) (169d 9'45.50"E, 44d31'35.55"S)
Lower Left ( 353999.800, 5032000.050) (169d 9' 8.52"E, 44d51' 1.68"S)
Upper Right ( 369999.630, 5068000.630) (169d21'50.06"E, 44d31'46.58"S)
Lower Right ( 369999.630, 5032000.050) (169d21'17.12"E, 44d51'12.83"S)
Center ( 361999.715, 5050000.340) (169d15'30.36"E, 44d41'24.33"S)
Band 1 Block=128x128 Type=Byte, ColorInterp=Red
NoData Value=0
Band 2 Block=128x128 Type=Byte, ColorInterp=Green
NoData Value=0
Band 3 Block=128x128 Type=Byte, ColorInterp=Blue
NoData Value=0
Band 4 Block=128x128 Type=Byte, ColorInterp=Undefined
NoData Value=0
And gdalinfo output for one of the underlying rasters:
gdalinfo 20240602_230818_SN26_RR_VISUAL_MS_360_5040.tif
Driver: GTiff/GeoTIFF
Files: 20240602_230818_SN26_RR_VISUAL_MS_360_5040.tif
Size is 10390, 25974
Coordinate System is:
PROJCRS["WGS 84 / UTM zone 59S",
BASEGEOGCRS["WGS 84",
DATUM["World Geodetic System 1984",
ELLIPSOID["WGS 84",6378137,298.257223563,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4326]],
CONVERSION["UTM zone 59S",
METHOD["Transverse Mercator",
ID["EPSG",9807]],
PARAMETER["Latitude of natural origin",0,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8801]],
PARAMETER["Longitude of natural origin",171,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8802]],
PARAMETER["Scale factor at natural origin",0.9996,
SCALEUNIT["unity",1],
ID["EPSG",8805]],
PARAMETER["False easting",500000,
LENGTHUNIT["metre",1],
ID["EPSG",8806]],
PARAMETER["False northing",10000000,
LENGTHUNIT["metre",1],
ID["EPSG",8807]]],
CS[Cartesian,2],
AXIS["(E)",east,
ORDER[1],
LENGTHUNIT["metre",1]],
AXIS["(N)",north,
ORDER[2],
LENGTHUNIT["metre",1]],
USAGE[
SCOPE["Engineering survey, topographic mapping."],
AREA["Between 168°E and 174°E, southern hemisphere between 80°S and
equator, onshore and offshore. New Zealand."],
BBOX[-80,168,0,174]],
ID["EPSG",32759]]
Data axis to CRS axis mapping: 1,2
Origin = (359999.640000000013970,5060000.330000000074506)
Pixel Size = (0.770000000000000,-0.770000000000000)
Metadata:
AREA_OR_POINT=Area
Image Structure Metadata:
COMPRESSION=LZW
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 359999.640, 5060000.330) (169d14' 9.36"E, 44d35'59.00"S)
Lower Left ( 359999.640, 5040000.350) (169d13'49.66"E, 44d46'46.86"S)
Upper Right ( 367999.940, 5060000.330) (169d20'12.11"E, 44d36' 4.44"S)
Lower Right ( 367999.940, 5040000.350) (169d19'53.53"E, 44d46'52.34"S)
Center ( 363999.790, 5050000.340) (169d17' 1.19"E, 44d41'25.70"S)
Band 1 Block=256x256 Type=Byte, ColorInterp=Red
NoData Value=0
Band 2 Block=256x256 Type=Byte, ColorInterp=Green
NoData Value=0
Band 3 Block=256x256 Type=Byte, ColorInterp=Blue
NoData Value=0
Band 4 Block=256x256 Type=Byte, ColorInterp=Undefined
NoData Value=0
What could be the reason for such a significant difference?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240605/a5451e8c/attachment.htm>
More information about the gdal-dev
mailing list