Re: AutoCreateWarpedVRT missing latitude clamping heuristic for Mercator projections

--===============1344253596988677178==
Content-Type: multipart/alternative; boundary="000000000000aca3c70652e84039"

--000000000000aca3c70652e84039
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I would hope against use of "unbounded" raster reprojection, to me that is
a bad smell and unfortunately it's becoming more prevalent not less in
modern downstream and related software. It's not just Mercator, any
Stereographic has the same problem and many others.

It's really not hard to get the four numbers of the bounding box for the
target, practitioners and tools should highlight that need and encourage
against in-built heuristics. The clamping of Mercator to square is entirely
arbitrary anyway, as would be any other limit place on Stereographic or
others.

If this feature was put in I'd still encourage for a better heuristic,
apply a configurable size (pixels) limit (around the centre point of the
result), an ncols and nrows parameter - or radius (in the target crs). That
has practical benefits, limiting any auto-heuristic to a sane number of
pixels, and configurable-away, or ignored when you provide a sensible
target specification: size, bbox, crs (or bbox, resolution crs
equivalently).

Cheers, Mike



On Mon, May 25, 2026 at 8:05=E2=80=AFPM Denis Rykov via gdal-dev <
[email protected]> wrote:

> In https://github.com/OSGeo/gdal/commit/5b7829 a useful heuristic was
> added to gdalwarp that clamps latitudes when warping from geographic CRS =
to
> Mercator projections. However, AutoCreateWarpedVRT does not apply the sam=
e
> heuristic. Users who create warped VRTs programmatically will silently ge=
t
> unbounded extents in the same scenario, with no warning issued.  It would
> be great to have this heuristic available at a lower level so other calle=
rs
> beyond gdalwarp can benefit from it as well.
> _______________________________________________
> gdal-dev mailing list
> [email protected]
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>


--=20
Michael Sumner
Research Software Engineer
Australian Antarctic Division
Hobart, Australia
0438489030
e-mail: [email protected]

--000000000000aca3c70652e84039
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">I would hope against use of &quot;unbound=
ed&quot; raster reprojection, to me that is a bad smell and unfortunately i=
t&#39;s becoming more prevalent not less in modern downstream and related s=
oftware. It&#39;s not just Mercator, any Stereographic has the same problem=
 and many others.=C2=A0</div><div dir=3D"ltr"><div><br></div><div>It&#39;s =
really not hard to get the four numbers of the bounding box for the target,=
 practitioners and tools should highlight that need and encourage against i=
n-built heuristics. The clamping of Mercator to square is entirely arbitrar=
y anyway, as would be any other limit place on Stereographic or others.=C2=
=A0</div></div><div><br></div>If this feature was put in I&#39;d still enco=
urage for a better heuristic, apply a configurable size (pixels) limit (aro=
und the centre point of the result), an ncols and nrows parameter - or radi=
us (in the target crs). That has practical=C2=A0benefits, limiting any auto=
-heuristic to a sane number of pixels, and configurable-away, or ignored wh=
en you provide a sensible target specification: size, bbox, crs (or bbox, r=
esolution crs equivalently).=C2=A0<div><br></div><div>Cheers, Mike</div><di=
v><br><div><br></div><div><br><div class=3D"gmail_quote gmail_quote_contain=
er"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, May 25, 2026 at 8:05=E2=
=80=AFPM Denis Rykov via gdal-dev &lt;<a href=3D"mailto:[email protected]=
o.org">[email protected]</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr">In <a href=3D"https://git=
hub.com/OSGeo/gdal/commit/5b7829" target=3D"_blank">https://github.com/OSGe=
o/gdal/commit/5b7829</a> a useful heuristic was added to gdalwarp that clam=
ps latitudes when warping from geographic CRS to Mercator projections.=C2=
=A0However, AutoCreateWarpedVRT does not apply the same heuristic. Users wh=
o create warped VRTs programmatically will silently get unbounded extents i=
n the same scenario, with no warning issued.=C2=A0=C2=A0It would be great t=
o have this heuristic available at a lower level so other callers beyond gd=
alwarp can benefit from it as well.</div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">gdal-dev@list=
s.osgeo.org</a><br>
<a href=3D"https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel=3D"norefe=
rrer" target=3D"_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</=
a><br>
</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature"><div dir=3D"ltr"><div dir=3D"ltr" style=3D"color:rgb(34,34,34)"><=
div dir=3D"ltr">Michael Sumner</div><div dir=3D"ltr">Research Software Engi=
neer<br>Australian Antarctic Division<br>Hobart, Australia</div><div dir=3D=
"ltr">0438489030<br>e-mail:=C2=A0<a href=3D"mailto:[email protected]" styl=
e=3D"color:rgb(17,85,204)" target=3D"_blank">[email protected]</a></div></=
div></div></div></div></div></div>

--000000000000aca3c70652e84039--

--===============1344253596988677178==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

--===============1344253596988677178==--