Hi Szehon, We received multiple LGTM on the spec change PR and many community members also commented in this thread. Should we start a vote now?
Thanks, Jia On Fri, Oct 3, 2025 at 9:32 PM Steven Wu <[email protected]> wrote: > > +1 on starting a vote to avoid wraparound for geometry > > On Fri, Oct 3, 2025 at 6:31 PM Jia Yu <[email protected]> wrote: >> >> Hi Szehon, >> >> Thanks for proposing the PR. This LGTM. It would be great if we can >> start a vote on this. >> >> Jia >> >> On Fri, Oct 3, 2025 at 5:33 PM Szehon Ho <[email protected]> wrote: >> > >> > 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 >> >> >
