Thanks Even, your suggestion works, I found an example here for Python
that could help others with this powerful feature:
https://gis.stackexchange.com/a/140053/17733
On 05/17/2018 09:02 PM, Even Rouault wrote:
>
> On jeudi 17 mai 2018 11:33:40 CEST Bang Pham Huu wrote:
>
> > Hi,
>
> >
>
> > I ha
You could use osr's CoordinateTransformation to evaluate the new location of
the four corners in the destination spatial reference:
http://gdal.org/python/osgeo.osr.CoordinateTransformation-class.html
From there a min/max on the four coordinates will give you the extent of the
new image space.
On jeudi 17 mai 2018 11:33:40 CEST Bang Pham Huu wrote:
> Hi,
>
> I have a hard problem to find the width/height of a 2D GeoTiff file
> which is reprojected from a source CRS (e.g: EPSG:4326) to target CRS
> (e.g: EPSG:3857) without running gdalwarp. Because, the file could be
> large (GBs) and I
Ari,
> In 2.3 the installed header files is limited to a fixed list. That is a
> good thing. Even better would be to install the header files into a GDAL
> specific subdir.
>
> However, that change broke one thing: the bindings cannot now be built
> against the public header files. At least cpl_v
In 2.3 the installed header files is limited to a fixed list. That is a
good thing. Even better would be to install the header files into a GDAL
specific subdir.
However, that change broke one thing: the bindings cannot now be built
against the public header files. At least cpl_vsi_error.h is
Hi,
I have a hard problem to find the width/height of a 2D GeoTiff file
which is reprojected from a source CRS (e.g: EPSG:4326) to target CRS
(e.g: EPSG:3857) without running gdalwarp. Because, the file could be
large (GBs) and I don't need the projected output file, just need the
width/height of
