I think so. But we need to get a consensus on if we want to drop it or not first.
On Mon, Sep 29, 2025 at 12:39 AM Gang Wu <[email protected]> wrote: > > 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
