+1 on starting a vote. Thanks, -Hsiang
> On Oct 7, 2025, at 11:27 PM, Jia Yu <[email protected]> wrote: > > 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 >>>>>>
