> Proposed: For the X values of the Geography type only, xmin may be greater than xmax
+1 on Jia's proposed spec clarification that only allows X wraparound for geography. On Sun, Sep 21, 2025 at 9:45 PM Jia Yu <ji...@apache.org> wrote: > Hi all, > > > I agree that it has been difficult to reach consensus on the > wraparound longitude of the X-axis bounding box in the Geometry type. > To move forward, I suggest we adjust the spec language as follows: > > > Current: For the X values only, xmin may be greater than xmax > > Proposed: For the X values of the Geography type only, xmin may be > greater than xmax > > > What do you guys think? > > Jia > > On Sat, Sep 20, 2025 at 1:54 AM Szehon Ho <szehon.apa...@gmail.com> wrote: > > > > Hello > > > > As we implement Geometry/Geography type support in the engines, we > notice one problem we missed to close when adopting these types in the V3 > spec. > > > > First, the use case: > > > > It is much easier to calculate/interpret lower and upper bounds of > geospatial objects when using linear/Cartesian edges, rather than spherical > edges. > > To properly model the earth we need wraparound bounds (allow xmin > xmax > to represent, if the object crosses the anti-meridian). > > > > > > However, the spec does not allow for this use case: > > > > Wraparound bounds is allowed only for Geography, and not Geometry type > > No 'linear' edge is defined in Geography type > > > > There is a long offline debate on how to support this case, options > included: > > > > Allowing wraparound for Geometry type for certain CRS, but now Iceberg > library needs to understand CRS's and if they support wraparound when > writing/interpreting bounds for predicate pushdown, rather than treating it > as just type metadata. > > Defining a Linear edge for Geography type, however this is not so common > and a bit confusing to the user. > > > > A compromise is somehow updating the format to allow "Geometry with > Wraparound" by adding a boolean to simply indicate whether the bounds are > wraparound or not (whether the objects cross the anti-meridian) instead of > having to read the CRS. The exact format seems not to have been proposed > yet. > > > > In any case, all options seem to involve a format version bump to V4 in > the strictest sense. If we take this interpretation, we may unfortunately > not support this use case until then and we add guards against it, as we > proceed with work of Geometry/Geography types in Iceberg reference > implementation. > > > > This is discussed in https://github.com/apache/iceberg/pull/13227 and > https://github.com/apache/iceberg/pull/12667 where it was suggested to > put a DISCUSS thread on devlist to spread more awareness of this > discussion. I apologize for my lack of deep geo knowledge as I may > mis-speak about something. But I am curious if this path makes sense, or > if we should take another approach. I'm also open to supporting this > earlier than V4 if there is consensus on the way forward and if there's no > conflicting implementation out there. > > > > Thanks! > > Szehon >
