Hi everyone, We have started a discussion on the Calcite dev list about adding planner-level GEOGRAPHY support [1], following the feedback in this thread.
The proposal [2] introduces GEOGRAPHY as a distinct SQL and relational type, with parsing, validation, type propagation, and unparsing support. The aim is to address the concerns about maintaining Flink-specific changes to Calcite classes and handling type-system edge cases. The proposed first change leaves runtime representation, serialization, spatial functions, and connector/format mappings outside its scope. We have highlighted Jia’s feedback on CRS/SRID, spherical-edge semantics, validation, equality, and shared serialization, and invited feedback on which guarantees are needed at the Calcite planner level. The Flink dev list and Jia are copied on the Calcite thread. We would appreciate your input there, particularly on whether the proposed scope provides a sufficient foundation for Flink integration. Subject to Calcite review and acceptance, the intended path is to merge the support upstream, bring the necessary changes into Flink, and remove any temporary copies when Flink upgrades its Calcite dependency. Flink runtime and interoperability decisions remain part of this FLIP discussion. Best regards, David [1] Calcite GEOGRAPHY discussion <https://lists.apache.org/thread/ykhbf99bggw2ylo4q1nbsyx2244m8cso> [2] Planner-level GEOGRAPHY type in Apache Calcite proposal <https://docs.google.com/document/d/1Btqd0oZT8ctqIaGI_AROyAFJQe68RsVyeQbtmK4wHQw/edit> On Wed, Oct 28, 2026 at 7:24 AM Jia Yu <[email protected]> wrote: > Hi Martijn, > > Thanks for the questions. > > Current support. SedonaFlink exposes Geography through RAW with a > dedicated serializer and serializer snapshot. I verified that a > Geography-containing compiled plan can be serialized, reloaded, and > executed on Flink 1.19 with Sedona loaded. SQL Gateway supports > executing our functions and returning scalar outputs such as > ST_AsText, while direct RAW result serialization and native > Iceberg/Parquet geography mappings remain gaps. > > Semantics and ownership. I’m open to either Sedona or Calcite > implementing the shared spatial type and SerDe. We should jointly > define CRS/SRID handling, spherical-edge semantics, validation, and > equality, involving Sedona contributors. > > Integration path. We plan to change our internal SerDe format and > adopt a unified SRID-prefixed WKB SerDe format, which could benefit > Spark and Iceberg integration. I would prefer Flink to adopt a similar > implementation rather than develop a brand new spatial type and > serialization implementation. We could explore retaining RAW with > Sedona-maintained adapters, or integrating a Calcite-provided type and > SerDe. Either path would still require explicit Flink runtime and > connector mappings, with generic extension hooks where needed. > > Thanks, > Jia > > On Mon, Oct 26, 2026 at 3:49 AM Martijn Visser <[email protected]> > wrote: > > > > Hi Jia, > > > > Thanks for joining the discussion. That's a fair point: Sedona came up > > several times in this thread, including how it might consume the proposed > > type, and involving the Sedona community directly would have been the > right > > call. Glad you're here now. > > > > Your input would be valuable in three areas: > > > > 1. SedonaFlink's current Geography support. The FLIP describes Sedona as > > geometry-first and based on a RAW type that doesn't survive compiled > plans, > > the SQL Gateway protocol, or connector schema mapping, and uses that as a > > key reason for adding a core type. Since that no longer seems accurate, > > could you share how Geography is represented in SedonaFlink today? In > > particular: is it still a RAW type, and can it be mapped from an Iceberg > v3 > > or Parquet geography column without the connector depending on Sedona? > That > > answer matters a lot for the case for a native type in Flink. > > > > 2. Semantics. Following the discussion above, the direction is to define > > GEOGRAPHY in Calcite first and then bring it into Flink. Having Sedona > > involved there would help keep the semantics aligned with Iceberg v3 and > > SedonaFlink. There are certain choices being proposed in the FLIP where I > > think feedback would be valuable. > > > > 3. Scope. My understanding of the FLIP is that Flink would own the type > and > > its interoperability (serialization, state, connectors/formats such as > > Iceberg and Parquet) with only constructor and conversion functions, > while > > richer geospatial computation stays in projects like Sedona. Would > > SedonaFlink be able to build on a native Flink GEOGRAPHY type, and do you > > see parts of the proposal that would duplicate or conflict with what > Sedona > > provides? > > > > @David, perhaps it makes sense to include Jia and the Sedona dev list > when > > you start the Calcite discussion? > > > > Best regards, > > > > Martijn > > > > Op ma 26 okt 2026 om 05:34 schreef Jia Yu <[email protected]>: > > > > > Hi all, > > > > > > This is Jia Yu, the PMC chair of Apache Sedona. Thanks for mentioning > > > Sedona in this thread and the proposal. The Sedona community is the > main > > > driving force that puts Geometry and Geography types into the Iceberg > v3 > > > spec. > > > > > > It is surprising to me that nobody in the Flink community ever reached > out > > > to the Sedona community despise the comprehensive Flink support that > Sedona > > > provides. > > > > > > BTW, Sedona is no longer a Geometry first system and we do have strong > > > Geography type and functions support in SedonaFlink. And it works with > > > Flink SQL Gateway. > > > https://sedona.apache.org/latest/api/flink/Geography-Functions/ > > > > > > Thanks, > > > Jia > > > > > > On 2026/10/23 08:39:11 Maximilian Michels wrote: > > > > Hi David, > > > > > > > > Thank you for your patience. We would greatly value the support of > > > GEOGRAPHY! > > > > > > > > The usual process is: > > > > > > > > 1. File a JIRA issue for CALCITE: > > > https://issues.apache.org/jira/browse/CALCITE > > > > 2. Start a thread on the Calcite dev mailing list. > > > > 3. If there are no objections, raise the PR. > > > > 4. Once merged, copy over the relevant Calcite files into the Flink > PR. > > > > > > > > As for the reviewers, the mailing list thread may help. We can also > > > > contact authors or reviewers of the existing Geometry implementation. > > > > If anybody else has a point of contact, please drop the name here. > > > > > > > > Cheers, > > > > Max > > > > > > > > On Tue, Oct 13, 2026 at 7:58 PM David Chaava via dev > > > > <[email protected]> wrote: > > > > > > > > > > Hi everyone, > > > > > > > > > > Following up on the Calcite contribution discussed above. We would > > > > > appreciate any guidance on the appropriate discussion and review > path, > > > > > including whom it would be useful to involve. > > > > > > > > > > Best regards, > > > > > David > > > > > > > > > > On Tue, Oct 6, 2026 at 4:20 PM David Chaava < > [email protected]> > > > wrote: > > > > > > > > > > > Hi Sergey, > > > > > > > > > > > > Thanks for explaining the longer-term concern. Adding GEOGRAPHY > to > > > Calcite > > > > > > first should help avoid Flink-specific planner handling and make > > > future > > > > > > Calcite upgrades easier. We’re ready to prepare a Calcite > > > contribution and > > > > > > then bring the necessary changes into Flink. > > > > > > > > > > > > Could we count on your help with early technical feedback and > review > > > on > > > > > > the Calcite side, and with bringing in other reviewers as needed? > > > > > > > > > > > > Thanks, > > > > > > David > > > > > > > > > > > > On Fri, Oct 2, 2026 at 10:35 PM Sergey Nuyanzin < > [email protected] > > > > > > > > > > wrote: > > > > > > > > > > > >> Hi David > > > > > >> > > > > > >> I think implementation in Calcite including approval/merging > should > > > be > > > > > >> fine (please raise in case of objections). > > > > > >> In this case the required changes might be copied as is to > Flink. > > > > > >> And will be dropped together with Calcite upgrade. > > > > > >> If there is changes no changes in Flink's Calcite classes not > > > > > >> presented in Calcite it should be fine > > > > > >> > > > > > >> On Wed, Sep 30, 2026 at 10:48 AM David Chaava via dev > > > > > >> <[email protected]> wrote: > > > > > >> > > > > > > >> > Hi Max, Sergey, Dylan, > > > > > >> > > > > > > >> > Thank you for the thoughtful feedback. > > > > > >> > > > > > > >> > I understand the concern Sergey raised about long-term > > > Flink-specific > > > > > >> > planner handling, particularly in light of the BITMAP > example. I > > > also > > > > > >> agree > > > > > >> > with Dylan that discussing GEOGRAPHY semantics with the > Calcite > > > > > >> community > > > > > >> > early would help avoid divergence. Max’s question about how a > > > future > > > > > >> > transition to a Calcite type would work is important for the > FLIP. > > > > > >> > > > > > > >> > Would you consider this sequence acceptable: first discuss and > > > document > > > > > >> > GEOGRAPHY semantics with the Calcite community; then, if the > > > Flink FLIP > > > > > >> > reaches consensus and the PR passes review, allow the core > Flink > > > > > >> GEOGRAPHY > > > > > >> > type to be merged without waiting for a Calcite > implementation or > > > > > >> release? > > > > > >> > Calcite implementation and any subsequent Flink migration > would be > > > > > >> > discussed separately. > > > > > >> > > > > > > >> > If you would not consider that sequence safe, what specific > > > Calcite > > > > > >> > milestone would you see as a prerequisite for merging the > Flink > > > PR? What > > > > > >> > compatibility requirements should we address in the FLIP? > > > > > >> > > > > > > >> > Thanks, > > > > > >> > David > > > > > >> > > > > > > >> > On Tue, Sep 29, 2026 at 9:25 AM dylanhz <[email protected]> > wrote: > > > > > >> > > > > > > >> > > +1 for discussing with Calcite first. > > > > > >> > > > > > > > >> > > Whether each project adopts the type is a separate > decision, but > > > > > >> > > discussing the semantics early should make any future > switch to > > > native > > > > > >> > > Calcite support easier. > > > > > >> > > > > > > > >> > > New types touch many parts of the system, and fixes will be > > > needed > > > > > >> over > > > > > >> > > time. RAW has been in Flink for years and still has a > similar > > > > > >> problem. I > > > > > >> > > also found another issue involving UNION and nullability. > > > > > >> > > > > > > > >> > > I'd suggest putting together a guide for adding new types: > what > > > to > > > > > >> check, > > > > > >> > > which SQL cases to test, and what pitfalls we've already > found. > > > We > > > > > >> can keep > > > > > >> > > updating it as more issues come up. This would help with > both > > > > > >> > > Calcite-native and Flink-specific types. > > > > > >> > > > > > > > >> > > ---------- > > > > > >> > > Best regards, > > > > > >> > > dylanhz > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > 2026年9月29日 04:55，Sergey Nuyanzin <[email protected]> > 写道： > > > > > >> > > > > > > > > >> > > > The problem of skipping Calcite for now will bite later > > > > > >> > > > > > > > > >> > > > Earlier there was mentioned BitMap type > > > > > >> > > > And now it appears that we need to hack Calcite classes to > > > support > > > > > >> edge > > > > > >> > > cases > > > > > >> > > > for instance [1]. > > > > > >> > > > To be honest I'd like to avoid this with other types > > > > > >> > > > > > > > > >> > > > [1] https://issues.apache.org/jira/browse/FLINK-40839 > > > > > >> > > > > > > > > >> > > > On Mon, Sep 28, 2026 at 3:41 PM Maximilian Michels < > > > [email protected]> > > > > > >> > > wrote: > > > > > >> > > >> > > > > > >> > > >> Thanks for looking into adding GEOGRAPHY support! I > think it > > > comes > > > > > >> > > >> down to how hard it would be to swap the built-in > GEOGRAPHY > > > with a > > > > > >> > > >> future Calcite GEOGRAPHY. If we keep the implementation > > > around > > > > > >> > > >> GEOMETRY slim and only add basic functions, it may be > > > feasible to > > > > > >> skip > > > > > >> > > >> Calcite for now. Modeling GEOGRAPHY as defined in the > > > Iceberg table > > > > > >> > > >> spec looks like a pretty safe bet. > > > > > >> > > >> > > > > > >> > > >> -Max > > > > > >> > > >> > > > > > >> > > >> On Wed, Sep 23, 2026 at 2:41 PM David Chaava via dev > > > > > >> > > >> <[email protected]> wrote: > > > > > >> > > >>> > > > > > >> > > >>> Hi everyone, > > > > > >> > > >>> > > > > > >> > > >>> > > > > > >> > > >>> Just bringing the GEOGRAPHY FLIP back to the list in > case > > > it got > > > > > >> > > buried. > > > > > >> > > >>> The discussion has been quiet for a while, and we’d > still > > > > > >> appreciate > > > > > >> > > the > > > > > >> > > >>> community’s feedback on the proposal and the open > > > > > >> implementation-path > > > > > >> > > >>> question. > > > > > >> > > >>> > > > > > >> > > >>> > > > > > >> > > >>> If you have a chance, please share your thoughts on the > > > proposal. > > > > > >> Any > > > > > >> > > >>> feedback on what we should address to move the > discussion > > > forward > > > > > >> > > would be > > > > > >> > > >>> very helpful. > > > > > >> > > >>> > > > > > >> > > >>> > > > > > >> > > >>> Thanks, > > > > > >> > > >>> David > > > > > >> > > >>> > > > > > >> > > >>> On Fri, Jul 17, 2026 at 8:03 PM David Chaava < > > > > > >> [email protected]> > > > > > >> > > >>> wrote: > > > > > >> > > >>> > > > > > >> > > >>>> Hi everyone, > > > > > >> > > >>>> > > > > > >> > > >>>> We would like to ask for help moving the Geography type > > > support > > > > > >> FLIP > > > > > >> > > >>>> forward. > > > > > >> > > >>>> > > > > > >> > > >>>> The discussion has been open for some time, and we > have now > > > > > >> prepared > > > > > >> > > the > > > > > >> > > >>>> first PR for the core GEOGRAPHY logical type support > so the > > > > > >> proposal > > > > > >> > > can be > > > > > >> > > >>>> reviewed against concrete implementation work [1]. > > > > > >> > > >>>> > > > > > >> > > >>>> This PR focuses on the base logical type support and > > > wiring, > > > > > >> while > > > > > >> > > keeping > > > > > >> > > >>>> unrelated dependency and format-specific changes > separate > > > to > > > > > >> make the > > > > > >> > > >>>> review easier. > > > > > >> > > >>>> > > > > > >> > > >>>> Best regards, > > > > > >> > > >>>> David > > > > > >> > > >>>> > > > > > >> > > >>>> [1] https://github.com/apache/flink/pull/28740 > > > > > >> > > >>>> > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > -- > > > > > >> > > > Best regards, > > > > > >> > > > Sergey > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > >> > > > > > >> > > > > > >> -- > > > > > >> Best regards, > > > > > >> Sergey > > > > > >> > > > > > > > > > > > > > >
