Wow. Can't believe I missed the middle one, at least. Thank you, Even, as
always!
Simon
On Fri, May 3, 2024 at 3:03 PM Even Rouault
wrote:
> ==> GDALCreateApproxTransformer():
> https://gdal.org/api/gdal_alg.html#_CPPv427GDALCreateApproxTransformer19GDALTransformerFuncPvd
>
> Otherwise there's
==> GDALCreateApproxTransformer():
https://gdal.org/api/gdal_alg.html#_CPPv427GDALCreateApproxTransformer19GDALTransformerFuncPvd
Otherwise there's OGRCoordinateTransformation::TransformBounds(), but
this works from a rectangle in the source CRS
Most simple would be to use
I like it.
On Fri, May 3, 2024 at 2:24 PM Javier Jimenez Shaw
wrote:
> Now I think I understand what you mean.
> One effective way is to convert the four sides of the image. To avoid the
> conversion of every pixel, you can start a partition process. Then compare
> the difference between the
Now I think I understand what you mean.
One effective way is to convert the four sides of the image. To avoid the
conversion of every pixel, you can start a partition process. Then compare
the difference between the transformed central point and just the mid point
between the extremes. If that
I don't have a real example to hand, but consider satellite imagery which
has not been processed but the file just has a GCP-based transformation
which warps it to something like this in flat (lon/lat or mercator) space.
The bbox is created using the xmin,ymin,xmax,ymax found in the geometry.
Assuming every pixel can be represented as a geometry, that's your bbox.
On 5/3/24 13:18, Simon Eves via gdal-dev wrote:
Yes, but that's just the corners.
Consider, say, a raster that contains a satellite sweep which is
Yes, but that's just the corners.
Consider, say, a raster that contains a satellite sweep which is not
axis-aligned but forms a "windshield wiper" shape in lon/lat space. The
bounding box of ALL the pixels is not just the bounding box of the corners.
On Fri, May 3, 2024 at 1:09 PM Javier Jimenez
Maybe I don't understand your question, but in gdalinfo you have the four
corners as lat-lon
On Fri, 3 May 2024, 21:46 Simon Eves via gdal-dev,
wrote:
> So we are trying to optimize our raster import process, and particularly
> the steps to derive the final WGS84/4326 bounding box for a raster
So we are trying to optimize our raster import process, and particularly
the steps to derive the final WGS84/4326 bounding box for a raster file or
tile thereof.
Obviously in the general case, the transform is from integer pixel
coordinate through the Affine Transformation matrix and then
Dear Even,
Apologies for taking your time. I couldn’t locate the mentioned error in
arcpy. It runs smoothly . I’ve shared the arcpy projection python script
and associated data with the link
https://u.pcloud.link/publink/show?code=kZj5wh0ZtFWXtI9UGjQiD6KXxn5A9hiWDpEX.
If you find a way using
10 matches
Mail list logo
