Sure, let me start one. Thanks Szehon
On Wed, Oct 8, 2025 at 10:24 AM Huang-Hsiang Cheng <[email protected]> wrote: > +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 > >>>>>> > >
