Sounds good, I propose a spec pr with the agreement to close the issue in V3 and not support Geometry_with_wraparound: https://github.com/apache/iceberg/pull/14250
As it seems it is a bit far off from a concrete proposal, we defer it to V4. Then the implementation can proceed without having to worry about CRS in the calculations because of this potential scenario, and it will be much simpler. Does it make sense to community? Can start a formal vote if there is consensus on this. Thanks Szehon On Fri, Oct 3, 2025 at 6:06 AM Feng Zhang <[email protected]> wrote: > I really appreciate the discussion here because it seems there has been a > lot of interest recently in geo types support for native geospatial > analytics in the communities. And as the parquet geo types rolled out with > a stable specification, I think it is the right time to prioritize the > native Iceberg implementation for the developer community. We could follow > up with a specific discussion and decision on "wraparound" details after > the initial features landed. > > On 2025/09/20 08:53:48 Szehon Ho 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: > > > > 1. It is much easier to calculate/interpret lower and upper bounds of > > geospatial objects when using linear/Cartesian edges, rather than > spherical > > edges. > > 2. 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: > > > > 1. Wraparound bounds is allowed only for Geography, and not Geometry > type > > 2. No 'linear' edge is defined in Geography type > > > > There is a long offline debate on how to support this case, options > > included: > > > > 1. 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. > > 2. 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 > > >
