+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 > >> > >
