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