I meant that the input GeoTIFF file should use the tile size and
compression method that you expect for the final COG, to be usable with
cogger. If you need to re-tile or change compression method, use the
GDAL COG driver
Le 07/06/2021 à 23:17, matt.wil...@yukon.ca a écrit :
…I'd expect it t
…I'd expect it to be much faster than gdal_translate -of COG (if your input is
GeoTIFF and always properly tiled and compressed of course!).
I’m confident I know what a properly compressed geotiff is, but what is a
properly tiled one? (or if it’s easier to define: what are improperly tiled
geot
Even,
Thanks for the explanation in the second paragraph of your response. My
colleagues are probably gonna give me grief because the warp operation could
have been much faster all these years, but hey, better late than never. J
It sounds like using the approximate warp will work great then.
Martin,
it would be interesting if you could identify which change caused the
slow down you notice. Nothing jumps to mind. git bisect could help
(assuming this is only GDAL related, and not due to changes in PROJ
versions)
The value of the error threshold is in pixels. So 0.125 means you acc
Even, Frank or anyone in the know about gdal warp API,
I have been using the GDALCreateGenImgProjTransformer function to create my
transformer arg in the warp options for the ChunkAndWarpImage function with
an error threshold set to 0.0 for a while now and everything works great. I
did this in
Hi all,
I hope my email finds you well
I would like to report you a convention issue with our SPOT6-7 RPC model.
Gdal has previously updated RPC model interpretation of Pléiades so that image
coordinate normalized rn,cn = -1,-1 corresponds to r,c = 0,0 by subtracting 1
pixel to the offset value
