Should we also make sure that Parquet spec is also in sync whatever the change is?
On Mon, Sep 29, 2025 at 12:30 PM Jia Yu <[email protected]> wrote: > Hi all, > > Should we start a vote on this if there are no objections in the > discussion thread? > > Jia > > > > > On Mon, Sep 22, 2025 at 10:51 AM Steven Wu <[email protected]> wrote: > > > > > Proposed: For the X values of the Geography type only, xmin may be > greater than xmax > > > > +1 on Jia's proposed spec clarification that only allows X wraparound > for geography. > > > > On Sun, Sep 21, 2025 at 9:45 PM Jia Yu <[email protected]> wrote: > >> > >> Hi all, > >> > >> > >> I agree that it has been difficult to reach consensus on the > >> wraparound longitude of the X-axis bounding box in the Geometry type. > >> To move forward, I suggest we adjust the spec language as follows: > >> > >> > >> Current: For the X values only, xmin may be greater than xmax > >> > >> Proposed: For the X values of the Geography type only, xmin may be > >> greater than xmax > >> > >> > >> What do you guys think? > >> > >> Jia > >> > >> On Sat, Sep 20, 2025 at 1:54 AM Szehon Ho <[email protected]> > 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: > >> > > >> > It is much easier to calculate/interpret lower and upper bounds of > geospatial objects when using linear/Cartesian edges, rather than spherical > edges. > >> > 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: > >> > > >> > Wraparound bounds is allowed only for Geography, and not Geometry type > >> > No 'linear' edge is defined in Geography type > >> > > >> > There is a long offline debate on how to support this case, options > included: > >> > > >> > 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. > >> > 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 >
