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