[gdal-dev] Odd comment in ogr_spatialref.h for TransformBounds API

Greg Troxel gdt at lexort.com
Thu Nov 5 05:04:09 PST 2026


Ray at Daylon via gdal-dev <gdal-dev at lists.osgeo.org> writes:

>      * If the destination CRS is geographic, the first axis is longitude, 
>      * and xmax < xmin then the bounds crossed the antimeridian.
>      * In this scenario there are two polygons, one on each side of the
>      * antimeridian. The first polygon should be constructed with (xmin, ymin,
>      * 180, ymax) and the second with (-180, ymin, xmax, ymax).

I see now why I failed to parse this, and it's a very fine point of
English phrasing that I'm not sure I can explain or point to a rule.  I
think Ray's interpretation/confusion is the same as mine.

(As an aside:
I find "transform boundary" confusing, because boundary feels like
it should be an arbitrary polygon.  Here, it is "bounding box".
)


When I read this, I interpreted

>      * If the destination CRS is geographic, the first axis is longitude, 

as

       * If the destination CRS is geographic, then the first axis is longitude, 

I would prefer big picture up front and then details:

  * If the destination CRS is geographic, it is possible that the output
  * will cross the anitmeridian.  If so, there will be two polygons, one
  * on each side of the antimeridian.  Depending on axis order:
  *
  * If the first axis is longitude and xmax < xmin:
  * The first polygon will be (xmin, ymin, 180, ymax) and the second
  * with (-180, ymin, xmax, ymax).
  *
  * If first axis is latitude and ymax < ymin:
  * The first polygon will be (ymin, xmin, ymax, 180) and the second
  * with (ymin, -180, ymax, xmax).

I also changed "should be constructed with" to "will be", because it's a
statement about function behavior, not advice to the user about the form
of inputs.  Except that there is one output, and thus there could be a
bounding box that crosses the antimeridian just like a source bounding
box could be like that.  And this is is just explaining the semantics of
such coordinates, which are not especially about this function.


So perhaps this needs to be entirely rewritten.


More information about the gdal-dev mailing list