Hi all, Should we start a vote on this if there are no objections in the discussion thread?
Jia On Mon, Sep 22, 2025 at 10:51 AM Steven Wu <[email protected]> wrote: > > > 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 <[email protected]> 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 <[email protected]> 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
