You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by David Chaava via dev <de...@flink.apache.org> on 2026/06/05 08:18:27 UTC
[DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
lHi everyone,
I would like to start a discussion on FLIP-XXX: GEOGRAPHY type in Flink SQL
and Table API [1].
Flink currently has no first-class geospatial type. Users working with
geographic data are forced into unsatisfying workarounds — encoding
geometries as raw strings, storing binary blobs, or pulling in external
libraries with no SQL-level integration. None of these options are
ergonomic, interoperable, or type-safe.
We propose introducing a native GEOGRAPHY type to Flink SQL and the Table
API, bringing first-class geospatial support to streaming and batch
pipelines. The key changes are:
1. New GEOGRAPHY Type - A dedicated logical type representing geospatial
values (points, lines, polygons, etc.) following the WKT/WKB standard, with
proper serialization and catalog integration.
2. Built-in Geospatial Functions - A set of SQL functions (e.g.
ST_Distance, ST_Contains, ST_AsText) enabling spatial predicates and
transformations directly in SQL queries.
3. Connector & Format Support - Pluggable encoding support so connectors
can read and write GEOGRAPHY values in standard formats (WKT, WKB, GeoJSON).
Looking forward to your feedback!
Best regards,
David Chaava
[1]
https://docs.google.com/document/d/1rpOTETT_Ui3TlEGioUr2NKJ1p1dlxjJQudXHndxBpO0/edit?usp=sharing
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by Martijn Visser <ma...@apache.org>.
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 <ji...@apache.org>:
> 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
> > <de...@flink.apache.org> 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 <da...@akvelon.us>
> 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 <snuyanzin@gmail.com
> >
> > > > 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
> > > >> <de...@flink.apache.org> 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 <dy...@163.com> 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 <sn...@gmail.com> 写道：
> > > >> > > >
> > > >> > > > 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 <
> mxm@apache.org>
> > > >> > > 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
> > > >> > > >> <de...@flink.apache.org> 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 <
> > > >> david.chaava@akvelon.us>
> > > >> > > >>> 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
> > > >>
> > > >
> >
>
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by Jia Yu <ji...@apache.org>.
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
> <de...@flink.apache.org> 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 <da...@akvelon.us> 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 <sn...@gmail.com>
> > > 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
> > >> <de...@flink.apache.org> 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 <dy...@163.com> 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 <sn...@gmail.com> 写道：
> > >> > > >
> > >> > > > 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 <mx...@apache.org>
> > >> > > 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
> > >> > > >> <de...@flink.apache.org> 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 <
> > >> david.chaava@akvelon.us>
> > >> > > >>> 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
> > >>
> > >
>
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by Maximilian Michels <mx...@apache.org>.
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
<de...@flink.apache.org> 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 <da...@akvelon.us> 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 <sn...@gmail.com>
> > 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
> >> <de...@flink.apache.org> 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 <dy...@163.com> 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 <sn...@gmail.com> 写道：
> >> > > >
> >> > > > 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 <mx...@apache.org>
> >> > > 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
> >> > > >> <de...@flink.apache.org> 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 <
> >> david.chaava@akvelon.us>
> >> > > >>> 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
> >>
> >
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by David Chaava via dev <de...@flink.apache.org>.
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 <da...@akvelon.us> 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 <sn...@gmail.com>
> 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
>> <de...@flink.apache.org> 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 <dy...@163.com> 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 <sn...@gmail.com> 写道：
>> > > >
>> > > > 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 <mx...@apache.org>
>> > > 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
>> > > >> <de...@flink.apache.org> 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 <
>> david.chaava@akvelon.us>
>> > > >>> 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
>>
>
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by David Chaava via dev <de...@flink.apache.org>.
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 <sn...@gmail.com> 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
> <de...@flink.apache.org> 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 <dy...@163.com> 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 <sn...@gmail.com> 写道：
> > > >
> > > > 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 <mx...@apache.org>
> > > 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
> > > >> <de...@flink.apache.org> 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 <
> david.chaava@akvelon.us>
> > > >>> 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
>
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by Sergey Nuyanzin <sn...@gmail.com>.
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
<de...@flink.apache.org> 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 <dy...@163.com> 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 <sn...@gmail.com> 写道：
> > >
> > > 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 <mx...@apache.org>
> > 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
> > >> <de...@flink.apache.org> 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 <da...@akvelon.us>
> > >>> 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
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by David Chaava via dev <de...@flink.apache.org>.
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 <dy...@163.com> 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 <sn...@gmail.com> 写道：
> >
> > 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 <mx...@apache.org>
> 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
> >> <de...@flink.apache.org> 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 <da...@akvelon.us>
> >>> 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
>
>
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by dylanhz <dy...@163.com>.
+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 <sn...@gmail.com> 写道：
>
> 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 <mx...@apache.org> 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
>> <de...@flink.apache.org> 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 <da...@akvelon.us>
>>> 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
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by Sergey Nuyanzin <sn...@gmail.com>.
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 <mx...@apache.org> 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
> <de...@flink.apache.org> 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 <da...@akvelon.us>
> > 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
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by Maximilian Michels <mx...@apache.org>.
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
<de...@flink.apache.org> 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 <da...@akvelon.us>
> 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
> >
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by David Chaava via dev <de...@flink.apache.org>.
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 <da...@akvelon.us>
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
>
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by David Chaava via dev <de...@flink.apache.org>.
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
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by David Chaava via dev <de...@flink.apache.org>.
Hi Talat,
Thank you for sharing the Iceberg use case. This is exactly where we would
like to get with this FLIP: make GEOGRAPHY available as a native Flink SQL
/ Table API type so that Iceberg GEOGRAPHY columns can be used directly
from Flink.
To show how a Flink-native GEOGRAPHY type could be implemented, we started
prototyping it [1][2].
These draft PRs introduce the native Flink GEOGRAPHY logical type model and
the initial Java Table API / runtime representation pieces.
Native Calcite support could be considered as a possible follow-up. Making
Calcite support a prerequisite, however, would add another upstream release
path before Flink users can use GEOGRAPHY. Recent Calcite upgrades in Flink
show that this can take many months, and in some cases more than a year,
which would be a long wait for the Iceberg GEOGRAPHY use case.
We would appreciate feedback from Flink committers / PMC members on these
prototype PRs, especially on whether the proposed type-system shape and
implementation boundaries look reasonable for the FLIP discussion. That
feedback would help us refine the proposal and prepare the next step in the
process.
Best regards,
David
[1] https://github.com/apache/flink/pull/28679
[2] https://github.com/apache/flink/pull/28680
On Mon, Jul 6, 2026 at 11:03 PM Talat Uyarer <ta...@apache.org> wrote:
> Hi David, Ramin, Sergey,
>
> I would like to express strong support for this FLIP! I am writing to you
> as an Apache Iceberg contributor. :)
>
> In the Iceberg community, we are highly anticipating first-class
> geospatial support in Flink. With Apache Iceberg v3, the table
> specification now natively supports GEOGRAPHY spatial types (backed by
> WKB). For Flink users to seamlessly read, write, and query these tables,
> having native GEOGRAPHY support in Flink SQL and the Table API is a crucial
> prerequisite. We are eager to leverage this FLIP to implement Iceberg's Geo
> Type support on Flink.
>
> Regarding the implementation path, while aligning with Calcite is a great
> long-term goal, making a Calcite-first implementation a hard blocker will
> significantly delay this FLIP. The process of introducing the type in
> Calcite, waiting for a Calcite release, and then upgrading Calcite in Flink
> is historically a 1-to-2 year journey. We saw similar situation with Flink
> variant support. At that time Calcite was supporting Variant. In this case
> There is no type in Calcite also.
>
> Ramin and Sergey, what do you think about Flink introducing GEOGRAPHY as a
> native logical type (backed by WKB) within its own type system first? This
> would unblock the Iceberg-Flink integration immediately, while the
> community can explore upstreaming or refactoring toward Calcite as a
> secondary, non-blocking phase.
>
> I believe implementing this natively within Flink first is the most
> pragmatic way to deliver value to the community quickly without stalling
> ecosystem integrations. Thank you again, David, for initiating this FLIP. I
> look forward to contributing to and supporting this effort from the Iceberg
> side!
>
> Best regards,
>
> Talat
> Apache Iceberg Contributor
>
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by Talat Uyarer <ta...@apache.org>.
Hi David, Ramin, Sergey,
I would like to express strong support for this FLIP! I am writing to you as an Apache Iceberg contributor. :)
In the Iceberg community, we are highly anticipating first-class geospatial support in Flink. With Apache Iceberg v3, the table specification now natively supports GEOGRAPHY spatial types (backed by WKB). For Flink users to seamlessly read, write, and query these tables, having native GEOGRAPHY support in Flink SQL and the Table API is a crucial prerequisite. We are eager to leverage this FLIP to implement Iceberg's Geo Type support on Flink.
Regarding the implementation path, while aligning with Calcite is a great long-term goal, making a Calcite-first implementation a hard blocker will significantly delay this FLIP. The process of introducing the type in Calcite, waiting for a Calcite release, and then upgrading Calcite in Flink is historically a 1-to-2 year journey. We saw similar situation with Flink variant support. At that time Calcite was supporting Variant. In this case There is no type in Calcite also.
Ramin and Sergey, what do you think about Flink introducing GEOGRAPHY as a native logical type (backed by WKB) within its own type system first? This would unblock the Iceberg-Flink integration immediately, while the community can explore upstreaming or refactoring toward Calcite as a secondary, non-blocking phase.
I believe implementing this natively within Flink first is the most pragmatic way to deliver value to the community quickly without stalling ecosystem integrations. Thank you again, David, for initiating this FLIP. I look forward to contributing to and supporting this effort from the Iceberg side!
Best regards,
Talat
Apache Iceberg Contributor
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by Ramin Gharib <ra...@gmail.com>.
Hi David,
Thanks for the proposal and the great discussion on introducing GEOGRAPHY
as a native Flink logical type. I agree with Sergey that we should
implement this in Calcite first before bringing it to Flink. If we don't,
there is a risk someone else might introduce a similar type in Calcite,
leaving us to maintain both.
Best,
Ramin
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by Sergey Nuyanzin <sn...@gmail.com>.
thanks for explanation
>For this FLIP, however, introducing
>GEOGRAPHY as a native Flink logical type allows us to move forward
>independently of the Calcite contribution and release process. An upstream
>Calcite contribution could still be pursued as a possible future follow-up.
personally I would vote to have it Calcite first, since otherwise we
could again come to situation where we have different Flink and
Calcite implementation
and need to maintain Flink one and keep in mind Calcite's one while
upgrading Calcite.
however curious about what others think
On Mon, Jun 29, 2026 at 8:49 PM David Chaava via dev
<de...@flink.apache.org> wrote:
>
> Hi everyone,
>
> A gentle reminder about this proposal for native GEOGRAPHY support in Flink
> SQL and Table API [1], for those who may have missed the original
> discussion.
>
> [1]
> https://docs.google.com/document/d/1rpOTETT_Ui3TlEGioUr2NKJ1p1dlxjJQudXHndxBpO0/edit
>
> Best regards,
>
> David
>
> On Tue, Jun 23, 2026 at 8:43 PM David Chaava <da...@akvelon.us>
> wrote:
>
> > Hi Sergey,
> >
> > Thanks for raising this question.
> >
> > I did consider Calcite's existing GEOMETRY type. The key reason not to use
> > it is that GEOMETRY and GEOGRAPHY represent different user-facing models.
> >
> > GEOMETRY is planar: coordinates are interpreted in a flat coordinate
> > space, and operations such as distance, area, intersection, buffering, and
> > containment are modeled in that planar space. This is the right model for
> > projected local data, CAD/GIS-style datasets, indoor maps, building
> > footprints, parcels, or any workload where the user intentionally chooses a
> > planar CRS.
> >
> > GEOGRAPHY is different: coordinates are longitude/latitude, the CRS is
> > part of the type contract, and operations are expected to use
> > spherical/geodesic semantics. This is the right model for GPS points,
> > routing, and other workloads involving the Earth’s surface.
> >
> > If Flink represented GEOGRAPHY internally as Calcite GEOMETRY, we would
> > lose that distinction at the planner boundary. That would make it harder to
> > add a future Flink GEOMETRY type cleanly, and it would make function typing
> > ambiguous. For example, ST_DISTANCE over GEOGRAPHY should produce a
> > geodesic distance over the Earth's surface, while ST_DISTANCE over GEOMETRY
> > should produce a planar distance in the coordinate system chosen by the
> > user. These should be different overloads with different semantics, not the
> > same planner type with out-of-band interpretation.
> >
> > Regarding contributing GEOGRAPHY to Calcite first: I think that’s a
> > reasonable long-term direction. For this FLIP, however, introducing
> > GEOGRAPHY as a native Flink logical type allows us to move forward
> > independently of the Calcite contribution and release process. An upstream
> > Calcite contribution could still be pursued as a possible future follow-up.
> >
> > The plan we propose to proceed in this FLIP is: (1) GEOGRAPHY as a native
> > Flink logical type; (2) bridged through Flink's Calcite integration layer,
> > following Flink’s BITMAP data type implementation pattern; (3) an upstream
> > Calcite GEOGRAPHY contribution left as a possible future follow-up if the
> > Calcite community shows interest.
> >
> > I've updated the FLIP to make the Calcite boundary explicit and noted
> > Calcite GEOMETRY as a considered alternative, with an explanation that it
> > would collapse planar and spherical/geodesic use cases into one planner
> > type and make geography-specific function modeling ambiguous.
> >
> > Best,
> >
> > David
> >
> >
> > On Sat, Jun 20, 2026 at 11:38 PM Sergey Nuyanzin <sn...@gmail.com>
> > wrote:
> >
> >> or a follow up question: have you considered first adding GEOGRAPHY
> >> type to Calcite and then using it from Flink?
> >>
> >> On Sat, Jun 20, 2026 at 11:33 PM Sergey Nuyanzin <sn...@gmail.com>
> >> wrote:
> >> >
> >> > Hi David
> >> >
> >> > since you mentioned Calcite and mentioned type name GEOGRAPHY
> >> >
> >> > why do we need a new type instead of using existing Calcite's type
> >> > which is called GEOMETRY[1]?
> >> >
> >> > [1]
> >> https://github.com/apache/calcite/blob/00aec5236cf9c57ce90eb4a30f777798c3b52abb/core/src/main/java/org/apache/calcite/sql/type/SqlTypeName.java#L137
> >> >
> >> > On Fri, Jun 12, 2026 at 11:17 PM David Chaava via dev
> >> > <de...@flink.apache.org> wrote:
> >> > >
> >> > > Hi Dylan,
> >> > >
> >> > >
> >> > >
> >> > > Thanks for the detailed review. I clarified these points in the
> >> proposal.
> >> > >
> >> > >
> >> > >
> >> > > Q1: The core proposal of this FLIP is the native `GEOGRAPHY` type and
> >> the
> >> > > interoperability contract support in Flink: SQL/planner type support,
> >> > > runtime representation, serialization/state, SQL Gateway/compiled plan
> >> > > support, and connector/format interoperability with
> >> > >
> >> > > Iceberg and Parquet. The FLIP does not intend that Flink core will
> >> become a
> >> > >
> >> > > replacement for dedicated geospatial projects such as Sedona.
> >> > >
> >> > >
> >> > >
> >> > > I added clarification of the function scope in the proposal doc. The
> >> v1
> >> > > function surface is intentionally small and is not meant to become a
> >> full
> >> > > geospatial function catalog. Constructor
> >> > >
> >> > > and conversion functions are part of making the native type usable for
> >> > > interoperability purposes. Richer geospatial processing, spatial
> >> joins,
> >> > > indexing, reprojection, and larger
> >> > >
> >> > > PostGIS/Sedona-like function coverage remains outside the scope of
> >> this
> >> > > FLIP.
> >> > >
> >> > >
> >> > >
> >> > > Q2: Regarding Sedona, I added clarification in the proposal doc that
> >> > > `GeographyData` is a Flink internal runtime representation, not a
> >> required
> >> > > computation API for Sedona. The stable interoperability path for
> >> Sedona and
> >> > > similar projects is ISO WKB via
> >> > >
> >> > > `GeographyData.toBytes()`, `ST_ASWKB`, and `ST_GEOGFROMWKB`. Sedona
> >> may
> >> > > still
> >> > >
> >> > > convert values into its own internal representation for computation
> >> and
> >> > > produce
> >> > >
> >> > > Flink `GEOGRAPHY` values back through WKB.
> >> > >
> >> > >
> >> > >
> >> > > Q3: For display and casts, I added clarification in the proposal that
> >> > > display rendering is separate from SQL casts. SQL Client,
> >> > > `TableResult.print()`, and SQL Gateway textual results should render
> >> > > `GEOGRAPHY` values as WKT, equivalent to `ST_ASTEXT`, for
> >> human-readable
> >> > > output. This display path does not imply an implicit cast to
> >> `STRING`. I
> >> > > also clarified that Java `toString()` should not be treated as the SQL
> >> > > conversion contract; explicit textual conversion remains `ST_ASTEXT`.
> >> > >
> >> > >
> >> > >
> >> > > Q4: For SQL semantics, I added explicit wording for equality,
> >> grouping, and
> >> > >
> >> > > comparability. The proposed v1 semantics are representation-based:
> >> equality
> >> > > and
> >> > >
> >> > > hashing are based on the stored/canonical WKB representation, not
> >> > > topological
> >> > >
> >> > > geospatial equality. `GROUP BY` and `DISTINCT` use the same
> >> equality/hash
> >> > >
> >> > > semantics. Topological equality, if exposed, is a separate geospatial
> >> > > predicate
> >> > >
> >> > > and should not be confused with SQL grouping semantics. `GEOGRAPHY`
> >> is not
> >> > >
> >> > > order-comparable, so ordering comparisons such as `<`, `<=`, `>`,
> >> `>=`, as
> >> > > well
> >> > >
> >> > > as `MIN` and `MAX`, are not defined for this type unless users
> >> explicitly
> >> > >
> >> > > convert the value to another representation, such as WKT or WKB.
> >> > >
> >> > >
> >> > >
> >> > > For the minor issues:
> >> > >
> >> > > - You are right about the JTS license. I corrected the license note.
> >> JTS
> >> > > would be included as a dependency (similar to how it’s included in
> >> Apache
> >> > > Sedona [1]), following Apache licensing guidelines for Eclipse
> >> Distribution
> >> > > License 1.0 [2].
> >> > >
> >> > > - I fixed the `GEOMETRYCOLLECTION` inconsistency. It remains listed
> >> as a
> >> > > supported standard 2D WKB subtype and was removed from Future Work.
> >> > >
> >> > >
> >> > >
> >> > > I hope this clarifies the intent and addresses your questions.
> >> > >
> >> > >
> >> > >
> >> > > Best,
> >> > >
> >> > > David
> >> > >
> >> > > [1] - https://github.com/apache/sedona/blob/master/pom.xml#L155-L159
> >> > >
> >> > > [2] - https://www.apache.org/legal/resolved.html
> >> > >
> >> > >
> >> > > On Thu, Jun 11, 2026 at 11:25 AM dylanhz <dy...@163.com> wrote:
> >> > >
> >> > > > Hi David,
> >> > > >
> >> > > > Thanks for the proposal. The FLIP is very detailed and explains the
> >> > > > motivation clearly. I have a few questions about the scope and
> >> semantics.
> >> > > >
> >> > > > 1. What is the expected scope of Flink in this area? Should Flink
> >> only
> >> > > > provide the native type and interoperability with
> >> formats/connectors, or
> >> > > > also maintain geospatial computation functions? I can understand
> >> having
> >> > > > constructor/conversion functions in core, but the supported scope
> >> and
> >> > > > long-term maintenance cost of domain-specific computation functions
> >> seem to
> >> > > > be an important concern. I am not sure whether those functions
> >> should be
> >> > > > maintained by Flink rather than a dedicated geospatial project such
> >> as
> >> > > > Sedona.
> >> > > >
> >> > > > 2. Have we considered how Sedona would adapt to this new type? Is
> >> the
> >> > > > proposed GeographyData interface enough for Sedona to consume and
> >> produce
> >> > > > GEOGRAPHY values efficiently? Or would Sedona not be able to
> >> directly use
> >> > > > Flink’s internal interface for computation and still need to
> >> convert to its
> >> > > > own internal representation?
> >> > > >
> >> > > > 3. If GEOGRAPHY does not support cast to STRING, how will values be
> >> > > > displayed in SQL Client, TableResult.print(), and SQL Gateway
> >> results? Do
> >> > > > we plan to add a display-specific converter, or should explicit
> >> cast to
> >> > > > STRING be supported?
> >> > > >
> >> > > > 4. Could the FLIP define the SQL semantics of GEOGRAPHY more
> >> explicitly?
> >> > > > For example, equality, comparability, GROUP BY and DISTINCT .
> >> > > >
> >> > > > A couple of minor issues:
> >> > > >
> >> > > > a. The JTS license in the document seems inaccurate.
> >> > > >
> >> > > > b. GEOMETRYCOLLECTION is listed as supported, but also appears in
> >> future
> >> > > > work.
> >> > > >
> >> > > >
> >> > > > ----------
> >> > > > Best regards,
> >> > > > dylanhz
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > > 2026年6月9日 02:32，David Chaava via dev <de...@flink.apache.org> 写道：
> >> > > > >
> >> > > > > Hi Martijn,
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > Thanks for raising this point. I updated the proposal with a
> >> dedicated
> >> > > > > Calcite / Planner Integration section to clarify how `GEOGRAPHY`
> >> and the
> >> > > > > proposed `ST_*` functions fit into Flink's SQL/planner path.
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > Please let us know if this addresses the question or if there are
> >> any
> >> > > > > additional
> >> > > > > planner details you would like us to cover.
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > Thanks
> >> > > > >
> >> > > > > On Mon, Jun 8, 2026 at 11:46 AM Martijn Visser <
> >> martijnvisser@apache.org
> >> > > > >
> >> > > > > wrote:
> >> > > > >
> >> > > > >> Hi David,
> >> > > > >>
> >> > > > >> Thanks for the FLIP. It doesn't contain any
> >> information/reference to
> >> > > > >> Calcite though. Are you not planning to leverage Calcite at all
> >> for
> >> > > > >> this?
> >> > > > >>
> >> > > > >> Best regards,
> >> > > > >>
> >> > > > >> Martijn
> >> > > > >>
> >> > > > >> Op vr 5 jun 2026 om 10:19 schreef David Chaava via dev <
> >> > > > >> dev@flink.apache.org>:
> >> > > > >>>
> >> > > > >>> lHi everyone,
> >> > > > >>>
> >> > > > >>> I would like to start a discussion on FLIP-XXX: GEOGRAPHY type
> >> in Flink
> >> > > > >> SQL
> >> > > > >>> and Table API [1].
> >> > > > >>>
> >> > > > >>> Flink currently has no first-class geospatial type. Users
> >> working with
> >> > > > >>> geographic data are forced into unsatisfying workarounds —
> >> encoding
> >> > > > >>> geometries as raw strings, storing binary blobs, or pulling in
> >> external
> >> > > > >>> libraries with no SQL-level integration. None of these options
> >> are
> >> > > > >>> ergonomic, interoperable, or type-safe.
> >> > > > >>>
> >> > > > >>> We propose introducing a native GEOGRAPHY type to Flink SQL and
> >> the
> >> > > > Table
> >> > > > >>> API, bringing first-class geospatial support to streaming and
> >> batch
> >> > > > >>> pipelines. The key changes are:
> >> > > > >>>
> >> > > > >>> 1. New GEOGRAPHY Type - A dedicated logical type representing
> >> > > > geospatial
> >> > > > >>> values (points, lines, polygons, etc.) following the WKT/WKB
> >> standard,
> >> > > > >> with
> >> > > > >>> proper serialization and catalog integration.
> >> > > > >>>
> >> > > > >>> 2. Built-in Geospatial Functions - A set of SQL functions (e.g.
> >> > > > >>> ST_Distance, ST_Contains, ST_AsText) enabling spatial
> >> predicates and
> >> > > > >>> transformations directly in SQL queries.
> >> > > > >>>
> >> > > > >>> 3. Connector & Format Support - Pluggable encoding support so
> >> > > > connectors
> >> > > > >>> can read and write GEOGRAPHY values in standard formats (WKT,
> >> WKB,
> >> > > > >> GeoJSON).
> >> > > > >>>
> >> > > > >>> Looking forward to your feedback!
> >> > > > >>>
> >> > > > >>> Best regards,
> >> > > > >>> David Chaava
> >> > > > >>>
> >> > > > >>> [1]
> >> > > > >>>
> >> > > > >>
> >> > > >
> >> https://docs.google.com/document/d/1rpOTETT_Ui3TlEGioUr2NKJ1p1dlxjJQudXHndxBpO0/edit?usp=sharing
> >> > > > >>
> >> > > >
> >> > > >
> >> >
> >> >
> >> >
> >> > --
> >> > Best regards,
> >> > Sergey
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Sergey
> >>
> >
--
Best regards,
Sergey
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by David Chaava via dev <de...@flink.apache.org>.
Hi everyone,
A gentle reminder about this proposal for native GEOGRAPHY support in Flink
SQL and Table API [1], for those who may have missed the original
discussion.
[1]
https://docs.google.com/document/d/1rpOTETT_Ui3TlEGioUr2NKJ1p1dlxjJQudXHndxBpO0/edit
Best regards,
David
On Tue, Jun 23, 2026 at 8:43 PM David Chaava <da...@akvelon.us>
wrote:
> Hi Sergey,
>
> Thanks for raising this question.
>
> I did consider Calcite's existing GEOMETRY type. The key reason not to use
> it is that GEOMETRY and GEOGRAPHY represent different user-facing models.
>
> GEOMETRY is planar: coordinates are interpreted in a flat coordinate
> space, and operations such as distance, area, intersection, buffering, and
> containment are modeled in that planar space. This is the right model for
> projected local data, CAD/GIS-style datasets, indoor maps, building
> footprints, parcels, or any workload where the user intentionally chooses a
> planar CRS.
>
> GEOGRAPHY is different: coordinates are longitude/latitude, the CRS is
> part of the type contract, and operations are expected to use
> spherical/geodesic semantics. This is the right model for GPS points,
> routing, and other workloads involving the Earth’s surface.
>
> If Flink represented GEOGRAPHY internally as Calcite GEOMETRY, we would
> lose that distinction at the planner boundary. That would make it harder to
> add a future Flink GEOMETRY type cleanly, and it would make function typing
> ambiguous. For example, ST_DISTANCE over GEOGRAPHY should produce a
> geodesic distance over the Earth's surface, while ST_DISTANCE over GEOMETRY
> should produce a planar distance in the coordinate system chosen by the
> user. These should be different overloads with different semantics, not the
> same planner type with out-of-band interpretation.
>
> Regarding contributing GEOGRAPHY to Calcite first: I think that’s a
> reasonable long-term direction. For this FLIP, however, introducing
> GEOGRAPHY as a native Flink logical type allows us to move forward
> independently of the Calcite contribution and release process. An upstream
> Calcite contribution could still be pursued as a possible future follow-up.
>
> The plan we propose to proceed in this FLIP is: (1) GEOGRAPHY as a native
> Flink logical type; (2) bridged through Flink's Calcite integration layer,
> following Flink’s BITMAP data type implementation pattern; (3) an upstream
> Calcite GEOGRAPHY contribution left as a possible future follow-up if the
> Calcite community shows interest.
>
> I've updated the FLIP to make the Calcite boundary explicit and noted
> Calcite GEOMETRY as a considered alternative, with an explanation that it
> would collapse planar and spherical/geodesic use cases into one planner
> type and make geography-specific function modeling ambiguous.
>
> Best,
>
> David
>
>
> On Sat, Jun 20, 2026 at 11:38 PM Sergey Nuyanzin <sn...@gmail.com>
> wrote:
>
>> or a follow up question: have you considered first adding GEOGRAPHY
>> type to Calcite and then using it from Flink?
>>
>> On Sat, Jun 20, 2026 at 11:33 PM Sergey Nuyanzin <sn...@gmail.com>
>> wrote:
>> >
>> > Hi David
>> >
>> > since you mentioned Calcite and mentioned type name GEOGRAPHY
>> >
>> > why do we need a new type instead of using existing Calcite's type
>> > which is called GEOMETRY[1]?
>> >
>> > [1]
>> https://github.com/apache/calcite/blob/00aec5236cf9c57ce90eb4a30f777798c3b52abb/core/src/main/java/org/apache/calcite/sql/type/SqlTypeName.java#L137
>> >
>> > On Fri, Jun 12, 2026 at 11:17 PM David Chaava via dev
>> > <de...@flink.apache.org> wrote:
>> > >
>> > > Hi Dylan,
>> > >
>> > >
>> > >
>> > > Thanks for the detailed review. I clarified these points in the
>> proposal.
>> > >
>> > >
>> > >
>> > > Q1: The core proposal of this FLIP is the native `GEOGRAPHY` type and
>> the
>> > > interoperability contract support in Flink: SQL/planner type support,
>> > > runtime representation, serialization/state, SQL Gateway/compiled plan
>> > > support, and connector/format interoperability with
>> > >
>> > > Iceberg and Parquet. The FLIP does not intend that Flink core will
>> become a
>> > >
>> > > replacement for dedicated geospatial projects such as Sedona.
>> > >
>> > >
>> > >
>> > > I added clarification of the function scope in the proposal doc. The
>> v1
>> > > function surface is intentionally small and is not meant to become a
>> full
>> > > geospatial function catalog. Constructor
>> > >
>> > > and conversion functions are part of making the native type usable for
>> > > interoperability purposes. Richer geospatial processing, spatial
>> joins,
>> > > indexing, reprojection, and larger
>> > >
>> > > PostGIS/Sedona-like function coverage remains outside the scope of
>> this
>> > > FLIP.
>> > >
>> > >
>> > >
>> > > Q2: Regarding Sedona, I added clarification in the proposal doc that
>> > > `GeographyData` is a Flink internal runtime representation, not a
>> required
>> > > computation API for Sedona. The stable interoperability path for
>> Sedona and
>> > > similar projects is ISO WKB via
>> > >
>> > > `GeographyData.toBytes()`, `ST_ASWKB`, and `ST_GEOGFROMWKB`. Sedona
>> may
>> > > still
>> > >
>> > > convert values into its own internal representation for computation
>> and
>> > > produce
>> > >
>> > > Flink `GEOGRAPHY` values back through WKB.
>> > >
>> > >
>> > >
>> > > Q3: For display and casts, I added clarification in the proposal that
>> > > display rendering is separate from SQL casts. SQL Client,
>> > > `TableResult.print()`, and SQL Gateway textual results should render
>> > > `GEOGRAPHY` values as WKT, equivalent to `ST_ASTEXT`, for
>> human-readable
>> > > output. This display path does not imply an implicit cast to
>> `STRING`. I
>> > > also clarified that Java `toString()` should not be treated as the SQL
>> > > conversion contract; explicit textual conversion remains `ST_ASTEXT`.
>> > >
>> > >
>> > >
>> > > Q4: For SQL semantics, I added explicit wording for equality,
>> grouping, and
>> > >
>> > > comparability. The proposed v1 semantics are representation-based:
>> equality
>> > > and
>> > >
>> > > hashing are based on the stored/canonical WKB representation, not
>> > > topological
>> > >
>> > > geospatial equality. `GROUP BY` and `DISTINCT` use the same
>> equality/hash
>> > >
>> > > semantics. Topological equality, if exposed, is a separate geospatial
>> > > predicate
>> > >
>> > > and should not be confused with SQL grouping semantics. `GEOGRAPHY`
>> is not
>> > >
>> > > order-comparable, so ordering comparisons such as `<`, `<=`, `>`,
>> `>=`, as
>> > > well
>> > >
>> > > as `MIN` and `MAX`, are not defined for this type unless users
>> explicitly
>> > >
>> > > convert the value to another representation, such as WKT or WKB.
>> > >
>> > >
>> > >
>> > > For the minor issues:
>> > >
>> > > - You are right about the JTS license. I corrected the license note.
>> JTS
>> > > would be included as a dependency (similar to how it’s included in
>> Apache
>> > > Sedona [1]), following Apache licensing guidelines for Eclipse
>> Distribution
>> > > License 1.0 [2].
>> > >
>> > > - I fixed the `GEOMETRYCOLLECTION` inconsistency. It remains listed
>> as a
>> > > supported standard 2D WKB subtype and was removed from Future Work.
>> > >
>> > >
>> > >
>> > > I hope this clarifies the intent and addresses your questions.
>> > >
>> > >
>> > >
>> > > Best,
>> > >
>> > > David
>> > >
>> > > [1] - https://github.com/apache/sedona/blob/master/pom.xml#L155-L159
>> > >
>> > > [2] - https://www.apache.org/legal/resolved.html
>> > >
>> > >
>> > > On Thu, Jun 11, 2026 at 11:25 AM dylanhz <dy...@163.com> wrote:
>> > >
>> > > > Hi David,
>> > > >
>> > > > Thanks for the proposal. The FLIP is very detailed and explains the
>> > > > motivation clearly. I have a few questions about the scope and
>> semantics.
>> > > >
>> > > > 1. What is the expected scope of Flink in this area? Should Flink
>> only
>> > > > provide the native type and interoperability with
>> formats/connectors, or
>> > > > also maintain geospatial computation functions? I can understand
>> having
>> > > > constructor/conversion functions in core, but the supported scope
>> and
>> > > > long-term maintenance cost of domain-specific computation functions
>> seem to
>> > > > be an important concern. I am not sure whether those functions
>> should be
>> > > > maintained by Flink rather than a dedicated geospatial project such
>> as
>> > > > Sedona.
>> > > >
>> > > > 2. Have we considered how Sedona would adapt to this new type? Is
>> the
>> > > > proposed GeographyData interface enough for Sedona to consume and
>> produce
>> > > > GEOGRAPHY values efficiently? Or would Sedona not be able to
>> directly use
>> > > > Flink’s internal interface for computation and still need to
>> convert to its
>> > > > own internal representation?
>> > > >
>> > > > 3. If GEOGRAPHY does not support cast to STRING, how will values be
>> > > > displayed in SQL Client, TableResult.print(), and SQL Gateway
>> results? Do
>> > > > we plan to add a display-specific converter, or should explicit
>> cast to
>> > > > STRING be supported?
>> > > >
>> > > > 4. Could the FLIP define the SQL semantics of GEOGRAPHY more
>> explicitly?
>> > > > For example, equality, comparability, GROUP BY and DISTINCT .
>> > > >
>> > > > A couple of minor issues:
>> > > >
>> > > > a. The JTS license in the document seems inaccurate.
>> > > >
>> > > > b. GEOMETRYCOLLECTION is listed as supported, but also appears in
>> future
>> > > > work.
>> > > >
>> > > >
>> > > > ----------
>> > > > Best regards,
>> > > > dylanhz
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > > 2026年6月9日 02:32，David Chaava via dev <de...@flink.apache.org> 写道：
>> > > > >
>> > > > > Hi Martijn,
>> > > > >
>> > > > >
>> > > > >
>> > > > > Thanks for raising this point. I updated the proposal with a
>> dedicated
>> > > > > Calcite / Planner Integration section to clarify how `GEOGRAPHY`
>> and the
>> > > > > proposed `ST_*` functions fit into Flink's SQL/planner path.
>> > > > >
>> > > > >
>> > > > >
>> > > > > Please let us know if this addresses the question or if there are
>> any
>> > > > > additional
>> > > > > planner details you would like us to cover.
>> > > > >
>> > > > >
>> > > > >
>> > > > > Thanks
>> > > > >
>> > > > > On Mon, Jun 8, 2026 at 11:46 AM Martijn Visser <
>> martijnvisser@apache.org
>> > > > >
>> > > > > wrote:
>> > > > >
>> > > > >> Hi David,
>> > > > >>
>> > > > >> Thanks for the FLIP. It doesn't contain any
>> information/reference to
>> > > > >> Calcite though. Are you not planning to leverage Calcite at all
>> for
>> > > > >> this?
>> > > > >>
>> > > > >> Best regards,
>> > > > >>
>> > > > >> Martijn
>> > > > >>
>> > > > >> Op vr 5 jun 2026 om 10:19 schreef David Chaava via dev <
>> > > > >> dev@flink.apache.org>:
>> > > > >>>
>> > > > >>> lHi everyone,
>> > > > >>>
>> > > > >>> I would like to start a discussion on FLIP-XXX: GEOGRAPHY type
>> in Flink
>> > > > >> SQL
>> > > > >>> and Table API [1].
>> > > > >>>
>> > > > >>> Flink currently has no first-class geospatial type. Users
>> working with
>> > > > >>> geographic data are forced into unsatisfying workarounds —
>> encoding
>> > > > >>> geometries as raw strings, storing binary blobs, or pulling in
>> external
>> > > > >>> libraries with no SQL-level integration. None of these options
>> are
>> > > > >>> ergonomic, interoperable, or type-safe.
>> > > > >>>
>> > > > >>> We propose introducing a native GEOGRAPHY type to Flink SQL and
>> the
>> > > > Table
>> > > > >>> API, bringing first-class geospatial support to streaming and
>> batch
>> > > > >>> pipelines. The key changes are:
>> > > > >>>
>> > > > >>> 1. New GEOGRAPHY Type - A dedicated logical type representing
>> > > > geospatial
>> > > > >>> values (points, lines, polygons, etc.) following the WKT/WKB
>> standard,
>> > > > >> with
>> > > > >>> proper serialization and catalog integration.
>> > > > >>>
>> > > > >>> 2. Built-in Geospatial Functions - A set of SQL functions (e.g.
>> > > > >>> ST_Distance, ST_Contains, ST_AsText) enabling spatial
>> predicates and
>> > > > >>> transformations directly in SQL queries.
>> > > > >>>
>> > > > >>> 3. Connector & Format Support - Pluggable encoding support so
>> > > > connectors
>> > > > >>> can read and write GEOGRAPHY values in standard formats (WKT,
>> WKB,
>> > > > >> GeoJSON).
>> > > > >>>
>> > > > >>> Looking forward to your feedback!
>> > > > >>>
>> > > > >>> Best regards,
>> > > > >>> David Chaava
>> > > > >>>
>> > > > >>> [1]
>> > > > >>>
>> > > > >>
>> > > >
>> https://docs.google.com/document/d/1rpOTETT_Ui3TlEGioUr2NKJ1p1dlxjJQudXHndxBpO0/edit?usp=sharing
>> > > > >>
>> > > >
>> > > >
>> >
>> >
>> >
>> > --
>> > Best regards,
>> > Sergey
>>
>>
>>
>> --
>> Best regards,
>> Sergey
>>
>
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by David Chaava via dev <de...@flink.apache.org>.
Hi Sergey,
Thanks for raising this question.
I did consider Calcite's existing GEOMETRY type. The key reason not to use
it is that GEOMETRY and GEOGRAPHY represent different user-facing models.
GEOMETRY is planar: coordinates are interpreted in a flat coordinate space,
and operations such as distance, area, intersection, buffering, and
containment are modeled in that planar space. This is the right model for
projected local data, CAD/GIS-style datasets, indoor maps, building
footprints, parcels, or any workload where the user intentionally chooses a
planar CRS.
GEOGRAPHY is different: coordinates are longitude/latitude, the CRS is part
of the type contract, and operations are expected to use spherical/geodesic
semantics. This is the right model for GPS points, routing, and other
workloads involving the Earth’s surface.
If Flink represented GEOGRAPHY internally as Calcite GEOMETRY, we would
lose that distinction at the planner boundary. That would make it harder to
add a future Flink GEOMETRY type cleanly, and it would make function typing
ambiguous. For example, ST_DISTANCE over GEOGRAPHY should produce a
geodesic distance over the Earth's surface, while ST_DISTANCE over GEOMETRY
should produce a planar distance in the coordinate system chosen by the
user. These should be different overloads with different semantics, not the
same planner type with out-of-band interpretation.
Regarding contributing GEOGRAPHY to Calcite first: I think that’s a
reasonable long-term direction. For this FLIP, however, introducing
GEOGRAPHY as a native Flink logical type allows us to move forward
independently of the Calcite contribution and release process. An upstream
Calcite contribution could still be pursued as a possible future follow-up.
The plan we propose to proceed in this FLIP is: (1) GEOGRAPHY as a native
Flink logical type; (2) bridged through Flink's Calcite integration layer,
following Flink’s BITMAP data type implementation pattern; (3) an upstream
Calcite GEOGRAPHY contribution left as a possible future follow-up if the
Calcite community shows interest.
I've updated the FLIP to make the Calcite boundary explicit and noted
Calcite GEOMETRY as a considered alternative, with an explanation that it
would collapse planar and spherical/geodesic use cases into one planner
type and make geography-specific function modeling ambiguous.
Best,
David
On Sat, Jun 20, 2026 at 11:38 PM Sergey Nuyanzin <sn...@gmail.com>
wrote:
> or a follow up question: have you considered first adding GEOGRAPHY
> type to Calcite and then using it from Flink?
>
> On Sat, Jun 20, 2026 at 11:33 PM Sergey Nuyanzin <sn...@gmail.com>
> wrote:
> >
> > Hi David
> >
> > since you mentioned Calcite and mentioned type name GEOGRAPHY
> >
> > why do we need a new type instead of using existing Calcite's type
> > which is called GEOMETRY[1]?
> >
> > [1]
> https://github.com/apache/calcite/blob/00aec5236cf9c57ce90eb4a30f777798c3b52abb/core/src/main/java/org/apache/calcite/sql/type/SqlTypeName.java#L137
> >
> > On Fri, Jun 12, 2026 at 11:17 PM David Chaava via dev
> > <de...@flink.apache.org> wrote:
> > >
> > > Hi Dylan,
> > >
> > >
> > >
> > > Thanks for the detailed review. I clarified these points in the
> proposal.
> > >
> > >
> > >
> > > Q1: The core proposal of this FLIP is the native `GEOGRAPHY` type and
> the
> > > interoperability contract support in Flink: SQL/planner type support,
> > > runtime representation, serialization/state, SQL Gateway/compiled plan
> > > support, and connector/format interoperability with
> > >
> > > Iceberg and Parquet. The FLIP does not intend that Flink core will
> become a
> > >
> > > replacement for dedicated geospatial projects such as Sedona.
> > >
> > >
> > >
> > > I added clarification of the function scope in the proposal doc. The v1
> > > function surface is intentionally small and is not meant to become a
> full
> > > geospatial function catalog. Constructor
> > >
> > > and conversion functions are part of making the native type usable for
> > > interoperability purposes. Richer geospatial processing, spatial joins,
> > > indexing, reprojection, and larger
> > >
> > > PostGIS/Sedona-like function coverage remains outside the scope of this
> > > FLIP.
> > >
> > >
> > >
> > > Q2: Regarding Sedona, I added clarification in the proposal doc that
> > > `GeographyData` is a Flink internal runtime representation, not a
> required
> > > computation API for Sedona. The stable interoperability path for
> Sedona and
> > > similar projects is ISO WKB via
> > >
> > > `GeographyData.toBytes()`, `ST_ASWKB`, and `ST_GEOGFROMWKB`. Sedona may
> > > still
> > >
> > > convert values into its own internal representation for computation and
> > > produce
> > >
> > > Flink `GEOGRAPHY` values back through WKB.
> > >
> > >
> > >
> > > Q3: For display and casts, I added clarification in the proposal that
> > > display rendering is separate from SQL casts. SQL Client,
> > > `TableResult.print()`, and SQL Gateway textual results should render
> > > `GEOGRAPHY` values as WKT, equivalent to `ST_ASTEXT`, for
> human-readable
> > > output. This display path does not imply an implicit cast to `STRING`.
> I
> > > also clarified that Java `toString()` should not be treated as the SQL
> > > conversion contract; explicit textual conversion remains `ST_ASTEXT`.
> > >
> > >
> > >
> > > Q4: For SQL semantics, I added explicit wording for equality,
> grouping, and
> > >
> > > comparability. The proposed v1 semantics are representation-based:
> equality
> > > and
> > >
> > > hashing are based on the stored/canonical WKB representation, not
> > > topological
> > >
> > > geospatial equality. `GROUP BY` and `DISTINCT` use the same
> equality/hash
> > >
> > > semantics. Topological equality, if exposed, is a separate geospatial
> > > predicate
> > >
> > > and should not be confused with SQL grouping semantics. `GEOGRAPHY` is
> not
> > >
> > > order-comparable, so ordering comparisons such as `<`, `<=`, `>`,
> `>=`, as
> > > well
> > >
> > > as `MIN` and `MAX`, are not defined for this type unless users
> explicitly
> > >
> > > convert the value to another representation, such as WKT or WKB.
> > >
> > >
> > >
> > > For the minor issues:
> > >
> > > - You are right about the JTS license. I corrected the license note.
> JTS
> > > would be included as a dependency (similar to how it’s included in
> Apache
> > > Sedona [1]), following Apache licensing guidelines for Eclipse
> Distribution
> > > License 1.0 [2].
> > >
> > > - I fixed the `GEOMETRYCOLLECTION` inconsistency. It remains listed as
> a
> > > supported standard 2D WKB subtype and was removed from Future Work.
> > >
> > >
> > >
> > > I hope this clarifies the intent and addresses your questions.
> > >
> > >
> > >
> > > Best,
> > >
> > > David
> > >
> > > [1] - https://github.com/apache/sedona/blob/master/pom.xml#L155-L159
> > >
> > > [2] - https://www.apache.org/legal/resolved.html
> > >
> > >
> > > On Thu, Jun 11, 2026 at 11:25 AM dylanhz <dy...@163.com> wrote:
> > >
> > > > Hi David,
> > > >
> > > > Thanks for the proposal. The FLIP is very detailed and explains the
> > > > motivation clearly. I have a few questions about the scope and
> semantics.
> > > >
> > > > 1. What is the expected scope of Flink in this area? Should Flink
> only
> > > > provide the native type and interoperability with
> formats/connectors, or
> > > > also maintain geospatial computation functions? I can understand
> having
> > > > constructor/conversion functions in core, but the supported scope and
> > > > long-term maintenance cost of domain-specific computation functions
> seem to
> > > > be an important concern. I am not sure whether those functions
> should be
> > > > maintained by Flink rather than a dedicated geospatial project such
> as
> > > > Sedona.
> > > >
> > > > 2. Have we considered how Sedona would adapt to this new type? Is the
> > > > proposed GeographyData interface enough for Sedona to consume and
> produce
> > > > GEOGRAPHY values efficiently? Or would Sedona not be able to
> directly use
> > > > Flink’s internal interface for computation and still need to convert
> to its
> > > > own internal representation?
> > > >
> > > > 3. If GEOGRAPHY does not support cast to STRING, how will values be
> > > > displayed in SQL Client, TableResult.print(), and SQL Gateway
> results? Do
> > > > we plan to add a display-specific converter, or should explicit cast
> to
> > > > STRING be supported?
> > > >
> > > > 4. Could the FLIP define the SQL semantics of GEOGRAPHY more
> explicitly?
> > > > For example, equality, comparability, GROUP BY and DISTINCT .
> > > >
> > > > A couple of minor issues:
> > > >
> > > > a. The JTS license in the document seems inaccurate.
> > > >
> > > > b. GEOMETRYCOLLECTION is listed as supported, but also appears in
> future
> > > > work.
> > > >
> > > >
> > > > ----------
> > > > Best regards,
> > > > dylanhz
> > > >
> > > >
> > > >
> > > >
> > > > > 2026年6月9日 02:32，David Chaava via dev <de...@flink.apache.org> 写道：
> > > > >
> > > > > Hi Martijn,
> > > > >
> > > > >
> > > > >
> > > > > Thanks for raising this point. I updated the proposal with a
> dedicated
> > > > > Calcite / Planner Integration section to clarify how `GEOGRAPHY`
> and the
> > > > > proposed `ST_*` functions fit into Flink's SQL/planner path.
> > > > >
> > > > >
> > > > >
> > > > > Please let us know if this addresses the question or if there are
> any
> > > > > additional
> > > > > planner details you would like us to cover.
> > > > >
> > > > >
> > > > >
> > > > > Thanks
> > > > >
> > > > > On Mon, Jun 8, 2026 at 11:46 AM Martijn Visser <
> martijnvisser@apache.org
> > > > >
> > > > > wrote:
> > > > >
> > > > >> Hi David,
> > > > >>
> > > > >> Thanks for the FLIP. It doesn't contain any information/reference
> to
> > > > >> Calcite though. Are you not planning to leverage Calcite at all
> for
> > > > >> this?
> > > > >>
> > > > >> Best regards,
> > > > >>
> > > > >> Martijn
> > > > >>
> > > > >> Op vr 5 jun 2026 om 10:19 schreef David Chaava via dev <
> > > > >> dev@flink.apache.org>:
> > > > >>>
> > > > >>> lHi everyone,
> > > > >>>
> > > > >>> I would like to start a discussion on FLIP-XXX: GEOGRAPHY type
> in Flink
> > > > >> SQL
> > > > >>> and Table API [1].
> > > > >>>
> > > > >>> Flink currently has no first-class geospatial type. Users
> working with
> > > > >>> geographic data are forced into unsatisfying workarounds —
> encoding
> > > > >>> geometries as raw strings, storing binary blobs, or pulling in
> external
> > > > >>> libraries with no SQL-level integration. None of these options
> are
> > > > >>> ergonomic, interoperable, or type-safe.
> > > > >>>
> > > > >>> We propose introducing a native GEOGRAPHY type to Flink SQL and
> the
> > > > Table
> > > > >>> API, bringing first-class geospatial support to streaming and
> batch
> > > > >>> pipelines. The key changes are:
> > > > >>>
> > > > >>> 1. New GEOGRAPHY Type - A dedicated logical type representing
> > > > geospatial
> > > > >>> values (points, lines, polygons, etc.) following the WKT/WKB
> standard,
> > > > >> with
> > > > >>> proper serialization and catalog integration.
> > > > >>>
> > > > >>> 2. Built-in Geospatial Functions - A set of SQL functions (e.g.
> > > > >>> ST_Distance, ST_Contains, ST_AsText) enabling spatial predicates
> and
> > > > >>> transformations directly in SQL queries.
> > > > >>>
> > > > >>> 3. Connector & Format Support - Pluggable encoding support so
> > > > connectors
> > > > >>> can read and write GEOGRAPHY values in standard formats (WKT,
> WKB,
> > > > >> GeoJSON).
> > > > >>>
> > > > >>> Looking forward to your feedback!
> > > > >>>
> > > > >>> Best regards,
> > > > >>> David Chaava
> > > > >>>
> > > > >>> [1]
> > > > >>>
> > > > >>
> > > >
> https://docs.google.com/document/d/1rpOTETT_Ui3TlEGioUr2NKJ1p1dlxjJQudXHndxBpO0/edit?usp=sharing
> > > > >>
> > > >
> > > >
> >
> >
> >
> > --
> > Best regards,
> > Sergey
>
>
>
> --
> Best regards,
> Sergey
>
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by Sergey Nuyanzin <sn...@gmail.com>.
or a follow up question: have you considered first adding GEOGRAPHY
type to Calcite and then using it from Flink?
On Sat, Jun 20, 2026 at 11:33 PM Sergey Nuyanzin <sn...@gmail.com> wrote:
>
> Hi David
>
> since you mentioned Calcite and mentioned type name GEOGRAPHY
>
> why do we need a new type instead of using existing Calcite's type
> which is called GEOMETRY[1]?
>
> [1] https://github.com/apache/calcite/blob/00aec5236cf9c57ce90eb4a30f777798c3b52abb/core/src/main/java/org/apache/calcite/sql/type/SqlTypeName.java#L137
>
> On Fri, Jun 12, 2026 at 11:17 PM David Chaava via dev
> <de...@flink.apache.org> wrote:
> >
> > Hi Dylan,
> >
> >
> >
> > Thanks for the detailed review. I clarified these points in the proposal.
> >
> >
> >
> > Q1: The core proposal of this FLIP is the native `GEOGRAPHY` type and the
> > interoperability contract support in Flink: SQL/planner type support,
> > runtime representation, serialization/state, SQL Gateway/compiled plan
> > support, and connector/format interoperability with
> >
> > Iceberg and Parquet. The FLIP does not intend that Flink core will become a
> >
> > replacement for dedicated geospatial projects such as Sedona.
> >
> >
> >
> > I added clarification of the function scope in the proposal doc. The v1
> > function surface is intentionally small and is not meant to become a full
> > geospatial function catalog. Constructor
> >
> > and conversion functions are part of making the native type usable for
> > interoperability purposes. Richer geospatial processing, spatial joins,
> > indexing, reprojection, and larger
> >
> > PostGIS/Sedona-like function coverage remains outside the scope of this
> > FLIP.
> >
> >
> >
> > Q2: Regarding Sedona, I added clarification in the proposal doc that
> > `GeographyData` is a Flink internal runtime representation, not a required
> > computation API for Sedona. The stable interoperability path for Sedona and
> > similar projects is ISO WKB via
> >
> > `GeographyData.toBytes()`, `ST_ASWKB`, and `ST_GEOGFROMWKB`. Sedona may
> > still
> >
> > convert values into its own internal representation for computation and
> > produce
> >
> > Flink `GEOGRAPHY` values back through WKB.
> >
> >
> >
> > Q3: For display and casts, I added clarification in the proposal that
> > display rendering is separate from SQL casts. SQL Client,
> > `TableResult.print()`, and SQL Gateway textual results should render
> > `GEOGRAPHY` values as WKT, equivalent to `ST_ASTEXT`, for human-readable
> > output. This display path does not imply an implicit cast to `STRING`. I
> > also clarified that Java `toString()` should not be treated as the SQL
> > conversion contract; explicit textual conversion remains `ST_ASTEXT`.
> >
> >
> >
> > Q4: For SQL semantics, I added explicit wording for equality, grouping, and
> >
> > comparability. The proposed v1 semantics are representation-based: equality
> > and
> >
> > hashing are based on the stored/canonical WKB representation, not
> > topological
> >
> > geospatial equality. `GROUP BY` and `DISTINCT` use the same equality/hash
> >
> > semantics. Topological equality, if exposed, is a separate geospatial
> > predicate
> >
> > and should not be confused with SQL grouping semantics. `GEOGRAPHY` is not
> >
> > order-comparable, so ordering comparisons such as `<`, `<=`, `>`, `>=`, as
> > well
> >
> > as `MIN` and `MAX`, are not defined for this type unless users explicitly
> >
> > convert the value to another representation, such as WKT or WKB.
> >
> >
> >
> > For the minor issues:
> >
> > - You are right about the JTS license. I corrected the license note. JTS
> > would be included as a dependency (similar to how it’s included in Apache
> > Sedona [1]), following Apache licensing guidelines for Eclipse Distribution
> > License 1.0 [2].
> >
> > - I fixed the `GEOMETRYCOLLECTION` inconsistency. It remains listed as a
> > supported standard 2D WKB subtype and was removed from Future Work.
> >
> >
> >
> > I hope this clarifies the intent and addresses your questions.
> >
> >
> >
> > Best,
> >
> > David
> >
> > [1] - https://github.com/apache/sedona/blob/master/pom.xml#L155-L159
> >
> > [2] - https://www.apache.org/legal/resolved.html
> >
> >
> > On Thu, Jun 11, 2026 at 11:25 AM dylanhz <dy...@163.com> wrote:
> >
> > > Hi David,
> > >
> > > Thanks for the proposal. The FLIP is very detailed and explains the
> > > motivation clearly. I have a few questions about the scope and semantics.
> > >
> > > 1. What is the expected scope of Flink in this area? Should Flink only
> > > provide the native type and interoperability with formats/connectors, or
> > > also maintain geospatial computation functions? I can understand having
> > > constructor/conversion functions in core, but the supported scope and
> > > long-term maintenance cost of domain-specific computation functions seem to
> > > be an important concern. I am not sure whether those functions should be
> > > maintained by Flink rather than a dedicated geospatial project such as
> > > Sedona.
> > >
> > > 2. Have we considered how Sedona would adapt to this new type? Is the
> > > proposed GeographyData interface enough for Sedona to consume and produce
> > > GEOGRAPHY values efficiently? Or would Sedona not be able to directly use
> > > Flink’s internal interface for computation and still need to convert to its
> > > own internal representation?
> > >
> > > 3. If GEOGRAPHY does not support cast to STRING, how will values be
> > > displayed in SQL Client, TableResult.print(), and SQL Gateway results? Do
> > > we plan to add a display-specific converter, or should explicit cast to
> > > STRING be supported?
> > >
> > > 4. Could the FLIP define the SQL semantics of GEOGRAPHY more explicitly?
> > > For example, equality, comparability, GROUP BY and DISTINCT .
> > >
> > > A couple of minor issues:
> > >
> > > a. The JTS license in the document seems inaccurate.
> > >
> > > b. GEOMETRYCOLLECTION is listed as supported, but also appears in future
> > > work.
> > >
> > >
> > > ----------
> > > Best regards,
> > > dylanhz
> > >
> > >
> > >
> > >
> > > > 2026年6月9日 02:32，David Chaava via dev <de...@flink.apache.org> 写道：
> > > >
> > > > Hi Martijn,
> > > >
> > > >
> > > >
> > > > Thanks for raising this point. I updated the proposal with a dedicated
> > > > Calcite / Planner Integration section to clarify how `GEOGRAPHY` and the
> > > > proposed `ST_*` functions fit into Flink's SQL/planner path.
> > > >
> > > >
> > > >
> > > > Please let us know if this addresses the question or if there are any
> > > > additional
> > > > planner details you would like us to cover.
> > > >
> > > >
> > > >
> > > > Thanks
> > > >
> > > > On Mon, Jun 8, 2026 at 11:46 AM Martijn Visser <martijnvisser@apache.org
> > > >
> > > > wrote:
> > > >
> > > >> Hi David,
> > > >>
> > > >> Thanks for the FLIP. It doesn't contain any information/reference to
> > > >> Calcite though. Are you not planning to leverage Calcite at all for
> > > >> this?
> > > >>
> > > >> Best regards,
> > > >>
> > > >> Martijn
> > > >>
> > > >> Op vr 5 jun 2026 om 10:19 schreef David Chaava via dev <
> > > >> dev@flink.apache.org>:
> > > >>>
> > > >>> lHi everyone,
> > > >>>
> > > >>> I would like to start a discussion on FLIP-XXX: GEOGRAPHY type in Flink
> > > >> SQL
> > > >>> and Table API [1].
> > > >>>
> > > >>> Flink currently has no first-class geospatial type. Users working with
> > > >>> geographic data are forced into unsatisfying workarounds — encoding
> > > >>> geometries as raw strings, storing binary blobs, or pulling in external
> > > >>> libraries with no SQL-level integration. None of these options are
> > > >>> ergonomic, interoperable, or type-safe.
> > > >>>
> > > >>> We propose introducing a native GEOGRAPHY type to Flink SQL and the
> > > Table
> > > >>> API, bringing first-class geospatial support to streaming and batch
> > > >>> pipelines. The key changes are:
> > > >>>
> > > >>> 1. New GEOGRAPHY Type - A dedicated logical type representing
> > > geospatial
> > > >>> values (points, lines, polygons, etc.) following the WKT/WKB standard,
> > > >> with
> > > >>> proper serialization and catalog integration.
> > > >>>
> > > >>> 2. Built-in Geospatial Functions - A set of SQL functions (e.g.
> > > >>> ST_Distance, ST_Contains, ST_AsText) enabling spatial predicates and
> > > >>> transformations directly in SQL queries.
> > > >>>
> > > >>> 3. Connector & Format Support - Pluggable encoding support so
> > > connectors
> > > >>> can read and write GEOGRAPHY values in standard formats (WKT, WKB,
> > > >> GeoJSON).
> > > >>>
> > > >>> Looking forward to your feedback!
> > > >>>
> > > >>> Best regards,
> > > >>> David Chaava
> > > >>>
> > > >>> [1]
> > > >>>
> > > >>
> > > https://docs.google.com/document/d/1rpOTETT_Ui3TlEGioUr2NKJ1p1dlxjJQudXHndxBpO0/edit?usp=sharing
> > > >>
> > >
> > >
>
>
>
> --
> Best regards,
> Sergey
--
Best regards,
Sergey
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by Sergey Nuyanzin <sn...@gmail.com>.
Hi David
since you mentioned Calcite and mentioned type name GEOGRAPHY
why do we need a new type instead of using existing Calcite's type
which is called GEOMETRY[1]?
[1] https://github.com/apache/calcite/blob/00aec5236cf9c57ce90eb4a30f777798c3b52abb/core/src/main/java/org/apache/calcite/sql/type/SqlTypeName.java#L137
On Fri, Jun 12, 2026 at 11:17 PM David Chaava via dev
<de...@flink.apache.org> wrote:
>
> Hi Dylan,
>
>
>
> Thanks for the detailed review. I clarified these points in the proposal.
>
>
>
> Q1: The core proposal of this FLIP is the native `GEOGRAPHY` type and the
> interoperability contract support in Flink: SQL/planner type support,
> runtime representation, serialization/state, SQL Gateway/compiled plan
> support, and connector/format interoperability with
>
> Iceberg and Parquet. The FLIP does not intend that Flink core will become a
>
> replacement for dedicated geospatial projects such as Sedona.
>
>
>
> I added clarification of the function scope in the proposal doc. The v1
> function surface is intentionally small and is not meant to become a full
> geospatial function catalog. Constructor
>
> and conversion functions are part of making the native type usable for
> interoperability purposes. Richer geospatial processing, spatial joins,
> indexing, reprojection, and larger
>
> PostGIS/Sedona-like function coverage remains outside the scope of this
> FLIP.
>
>
>
> Q2: Regarding Sedona, I added clarification in the proposal doc that
> `GeographyData` is a Flink internal runtime representation, not a required
> computation API for Sedona. The stable interoperability path for Sedona and
> similar projects is ISO WKB via
>
> `GeographyData.toBytes()`, `ST_ASWKB`, and `ST_GEOGFROMWKB`. Sedona may
> still
>
> convert values into its own internal representation for computation and
> produce
>
> Flink `GEOGRAPHY` values back through WKB.
>
>
>
> Q3: For display and casts, I added clarification in the proposal that
> display rendering is separate from SQL casts. SQL Client,
> `TableResult.print()`, and SQL Gateway textual results should render
> `GEOGRAPHY` values as WKT, equivalent to `ST_ASTEXT`, for human-readable
> output. This display path does not imply an implicit cast to `STRING`. I
> also clarified that Java `toString()` should not be treated as the SQL
> conversion contract; explicit textual conversion remains `ST_ASTEXT`.
>
>
>
> Q4: For SQL semantics, I added explicit wording for equality, grouping, and
>
> comparability. The proposed v1 semantics are representation-based: equality
> and
>
> hashing are based on the stored/canonical WKB representation, not
> topological
>
> geospatial equality. `GROUP BY` and `DISTINCT` use the same equality/hash
>
> semantics. Topological equality, if exposed, is a separate geospatial
> predicate
>
> and should not be confused with SQL grouping semantics. `GEOGRAPHY` is not
>
> order-comparable, so ordering comparisons such as `<`, `<=`, `>`, `>=`, as
> well
>
> as `MIN` and `MAX`, are not defined for this type unless users explicitly
>
> convert the value to another representation, such as WKT or WKB.
>
>
>
> For the minor issues:
>
> - You are right about the JTS license. I corrected the license note. JTS
> would be included as a dependency (similar to how it’s included in Apache
> Sedona [1]), following Apache licensing guidelines for Eclipse Distribution
> License 1.0 [2].
>
> - I fixed the `GEOMETRYCOLLECTION` inconsistency. It remains listed as a
> supported standard 2D WKB subtype and was removed from Future Work.
>
>
>
> I hope this clarifies the intent and addresses your questions.
>
>
>
> Best,
>
> David
>
> [1] - https://github.com/apache/sedona/blob/master/pom.xml#L155-L159
>
> [2] - https://www.apache.org/legal/resolved.html
>
>
> On Thu, Jun 11, 2026 at 11:25 AM dylanhz <dy...@163.com> wrote:
>
> > Hi David,
> >
> > Thanks for the proposal. The FLIP is very detailed and explains the
> > motivation clearly. I have a few questions about the scope and semantics.
> >
> > 1. What is the expected scope of Flink in this area? Should Flink only
> > provide the native type and interoperability with formats/connectors, or
> > also maintain geospatial computation functions? I can understand having
> > constructor/conversion functions in core, but the supported scope and
> > long-term maintenance cost of domain-specific computation functions seem to
> > be an important concern. I am not sure whether those functions should be
> > maintained by Flink rather than a dedicated geospatial project such as
> > Sedona.
> >
> > 2. Have we considered how Sedona would adapt to this new type? Is the
> > proposed GeographyData interface enough for Sedona to consume and produce
> > GEOGRAPHY values efficiently? Or would Sedona not be able to directly use
> > Flink’s internal interface for computation and still need to convert to its
> > own internal representation?
> >
> > 3. If GEOGRAPHY does not support cast to STRING, how will values be
> > displayed in SQL Client, TableResult.print(), and SQL Gateway results? Do
> > we plan to add a display-specific converter, or should explicit cast to
> > STRING be supported?
> >
> > 4. Could the FLIP define the SQL semantics of GEOGRAPHY more explicitly?
> > For example, equality, comparability, GROUP BY and DISTINCT .
> >
> > A couple of minor issues:
> >
> > a. The JTS license in the document seems inaccurate.
> >
> > b. GEOMETRYCOLLECTION is listed as supported, but also appears in future
> > work.
> >
> >
> > ----------
> > Best regards,
> > dylanhz
> >
> >
> >
> >
> > > 2026年6月9日 02:32，David Chaava via dev <de...@flink.apache.org> 写道：
> > >
> > > Hi Martijn,
> > >
> > >
> > >
> > > Thanks for raising this point. I updated the proposal with a dedicated
> > > Calcite / Planner Integration section to clarify how `GEOGRAPHY` and the
> > > proposed `ST_*` functions fit into Flink's SQL/planner path.
> > >
> > >
> > >
> > > Please let us know if this addresses the question or if there are any
> > > additional
> > > planner details you would like us to cover.
> > >
> > >
> > >
> > > Thanks
> > >
> > > On Mon, Jun 8, 2026 at 11:46 AM Martijn Visser <martijnvisser@apache.org
> > >
> > > wrote:
> > >
> > >> Hi David,
> > >>
> > >> Thanks for the FLIP. It doesn't contain any information/reference to
> > >> Calcite though. Are you not planning to leverage Calcite at all for
> > >> this?
> > >>
> > >> Best regards,
> > >>
> > >> Martijn
> > >>
> > >> Op vr 5 jun 2026 om 10:19 schreef David Chaava via dev <
> > >> dev@flink.apache.org>:
> > >>>
> > >>> lHi everyone,
> > >>>
> > >>> I would like to start a discussion on FLIP-XXX: GEOGRAPHY type in Flink
> > >> SQL
> > >>> and Table API [1].
> > >>>
> > >>> Flink currently has no first-class geospatial type. Users working with
> > >>> geographic data are forced into unsatisfying workarounds — encoding
> > >>> geometries as raw strings, storing binary blobs, or pulling in external
> > >>> libraries with no SQL-level integration. None of these options are
> > >>> ergonomic, interoperable, or type-safe.
> > >>>
> > >>> We propose introducing a native GEOGRAPHY type to Flink SQL and the
> > Table
> > >>> API, bringing first-class geospatial support to streaming and batch
> > >>> pipelines. The key changes are:
> > >>>
> > >>> 1. New GEOGRAPHY Type - A dedicated logical type representing
> > geospatial
> > >>> values (points, lines, polygons, etc.) following the WKT/WKB standard,
> > >> with
> > >>> proper serialization and catalog integration.
> > >>>
> > >>> 2. Built-in Geospatial Functions - A set of SQL functions (e.g.
> > >>> ST_Distance, ST_Contains, ST_AsText) enabling spatial predicates and
> > >>> transformations directly in SQL queries.
> > >>>
> > >>> 3. Connector & Format Support - Pluggable encoding support so
> > connectors
> > >>> can read and write GEOGRAPHY values in standard formats (WKT, WKB,
> > >> GeoJSON).
> > >>>
> > >>> Looking forward to your feedback!
> > >>>
> > >>> Best regards,
> > >>> David Chaava
> > >>>
> > >>> [1]
> > >>>
> > >>
> > https://docs.google.com/document/d/1rpOTETT_Ui3TlEGioUr2NKJ1p1dlxjJQudXHndxBpO0/edit?usp=sharing
> > >>
> >
> >
--
Best regards,
Sergey
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by David Chaava via dev <de...@flink.apache.org>.
Hi Dylan,
Thanks for the detailed review. I clarified these points in the proposal.
Q1: The core proposal of this FLIP is the native `GEOGRAPHY` type and the
interoperability contract support in Flink: SQL/planner type support,
runtime representation, serialization/state, SQL Gateway/compiled plan
support, and connector/format interoperability with
Iceberg and Parquet. The FLIP does not intend that Flink core will become a
replacement for dedicated geospatial projects such as Sedona.
I added clarification of the function scope in the proposal doc. The v1
function surface is intentionally small and is not meant to become a full
geospatial function catalog. Constructor
and conversion functions are part of making the native type usable for
interoperability purposes. Richer geospatial processing, spatial joins,
indexing, reprojection, and larger
PostGIS/Sedona-like function coverage remains outside the scope of this
FLIP.
Q2: Regarding Sedona, I added clarification in the proposal doc that
`GeographyData` is a Flink internal runtime representation, not a required
computation API for Sedona. The stable interoperability path for Sedona and
similar projects is ISO WKB via
`GeographyData.toBytes()`, `ST_ASWKB`, and `ST_GEOGFROMWKB`. Sedona may
still
convert values into its own internal representation for computation and
produce
Flink `GEOGRAPHY` values back through WKB.
Q3: For display and casts, I added clarification in the proposal that
display rendering is separate from SQL casts. SQL Client,
`TableResult.print()`, and SQL Gateway textual results should render
`GEOGRAPHY` values as WKT, equivalent to `ST_ASTEXT`, for human-readable
output. This display path does not imply an implicit cast to `STRING`. I
also clarified that Java `toString()` should not be treated as the SQL
conversion contract; explicit textual conversion remains `ST_ASTEXT`.
Q4: For SQL semantics, I added explicit wording for equality, grouping, and
comparability. The proposed v1 semantics are representation-based: equality
and
hashing are based on the stored/canonical WKB representation, not
topological
geospatial equality. `GROUP BY` and `DISTINCT` use the same equality/hash
semantics. Topological equality, if exposed, is a separate geospatial
predicate
and should not be confused with SQL grouping semantics. `GEOGRAPHY` is not
order-comparable, so ordering comparisons such as `<`, `<=`, `>`, `>=`, as
well
as `MIN` and `MAX`, are not defined for this type unless users explicitly
convert the value to another representation, such as WKT or WKB.
For the minor issues:
- You are right about the JTS license. I corrected the license note. JTS
would be included as a dependency (similar to how it’s included in Apache
Sedona [1]), following Apache licensing guidelines for Eclipse Distribution
License 1.0 [2].
- I fixed the `GEOMETRYCOLLECTION` inconsistency. It remains listed as a
supported standard 2D WKB subtype and was removed from Future Work.
I hope this clarifies the intent and addresses your questions.
Best,
David
[1] - https://github.com/apache/sedona/blob/master/pom.xml#L155-L159
[2] - https://www.apache.org/legal/resolved.html
On Thu, Jun 11, 2026 at 11:25 AM dylanhz <dy...@163.com> wrote:
> Hi David,
>
> Thanks for the proposal. The FLIP is very detailed and explains the
> motivation clearly. I have a few questions about the scope and semantics.
>
> 1. What is the expected scope of Flink in this area? Should Flink only
> provide the native type and interoperability with formats/connectors, or
> also maintain geospatial computation functions? I can understand having
> constructor/conversion functions in core, but the supported scope and
> long-term maintenance cost of domain-specific computation functions seem to
> be an important concern. I am not sure whether those functions should be
> maintained by Flink rather than a dedicated geospatial project such as
> Sedona.
>
> 2. Have we considered how Sedona would adapt to this new type? Is the
> proposed GeographyData interface enough for Sedona to consume and produce
> GEOGRAPHY values efficiently? Or would Sedona not be able to directly use
> Flink’s internal interface for computation and still need to convert to its
> own internal representation?
>
> 3. If GEOGRAPHY does not support cast to STRING, how will values be
> displayed in SQL Client, TableResult.print(), and SQL Gateway results? Do
> we plan to add a display-specific converter, or should explicit cast to
> STRING be supported?
>
> 4. Could the FLIP define the SQL semantics of GEOGRAPHY more explicitly?
> For example, equality, comparability, GROUP BY and DISTINCT .
>
> A couple of minor issues:
>
> a. The JTS license in the document seems inaccurate.
>
> b. GEOMETRYCOLLECTION is listed as supported, but also appears in future
> work.
>
>
> ----------
> Best regards,
> dylanhz
>
>
>
>
> > 2026年6月9日 02:32，David Chaava via dev <de...@flink.apache.org> 写道：
> >
> > Hi Martijn,
> >
> >
> >
> > Thanks for raising this point. I updated the proposal with a dedicated
> > Calcite / Planner Integration section to clarify how `GEOGRAPHY` and the
> > proposed `ST_*` functions fit into Flink's SQL/planner path.
> >
> >
> >
> > Please let us know if this addresses the question or if there are any
> > additional
> > planner details you would like us to cover.
> >
> >
> >
> > Thanks
> >
> > On Mon, Jun 8, 2026 at 11:46 AM Martijn Visser <martijnvisser@apache.org
> >
> > wrote:
> >
> >> Hi David,
> >>
> >> Thanks for the FLIP. It doesn't contain any information/reference to
> >> Calcite though. Are you not planning to leverage Calcite at all for
> >> this?
> >>
> >> Best regards,
> >>
> >> Martijn
> >>
> >> Op vr 5 jun 2026 om 10:19 schreef David Chaava via dev <
> >> dev@flink.apache.org>:
> >>>
> >>> lHi everyone,
> >>>
> >>> I would like to start a discussion on FLIP-XXX: GEOGRAPHY type in Flink
> >> SQL
> >>> and Table API [1].
> >>>
> >>> Flink currently has no first-class geospatial type. Users working with
> >>> geographic data are forced into unsatisfying workarounds — encoding
> >>> geometries as raw strings, storing binary blobs, or pulling in external
> >>> libraries with no SQL-level integration. None of these options are
> >>> ergonomic, interoperable, or type-safe.
> >>>
> >>> We propose introducing a native GEOGRAPHY type to Flink SQL and the
> Table
> >>> API, bringing first-class geospatial support to streaming and batch
> >>> pipelines. The key changes are:
> >>>
> >>> 1. New GEOGRAPHY Type - A dedicated logical type representing
> geospatial
> >>> values (points, lines, polygons, etc.) following the WKT/WKB standard,
> >> with
> >>> proper serialization and catalog integration.
> >>>
> >>> 2. Built-in Geospatial Functions - A set of SQL functions (e.g.
> >>> ST_Distance, ST_Contains, ST_AsText) enabling spatial predicates and
> >>> transformations directly in SQL queries.
> >>>
> >>> 3. Connector & Format Support - Pluggable encoding support so
> connectors
> >>> can read and write GEOGRAPHY values in standard formats (WKT, WKB,
> >> GeoJSON).
> >>>
> >>> Looking forward to your feedback!
> >>>
> >>> Best regards,
> >>> David Chaava
> >>>
> >>> [1]
> >>>
> >>
> https://docs.google.com/document/d/1rpOTETT_Ui3TlEGioUr2NKJ1p1dlxjJQudXHndxBpO0/edit?usp=sharing
> >>
>
>
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by dylanhz <dy...@163.com>.
Hi David,
Thanks for the proposal. The FLIP is very detailed and explains the motivation clearly. I have a few questions about the scope and semantics.
1. What is the expected scope of Flink in this area? Should Flink only provide the native type and interoperability with formats/connectors, or also maintain geospatial computation functions? I can understand having constructor/conversion functions in core, but the supported scope and long-term maintenance cost of domain-specific computation functions seem to be an important concern. I am not sure whether those functions should be maintained by Flink rather than a dedicated geospatial project such as Sedona.
2. Have we considered how Sedona would adapt to this new type? Is the proposed GeographyData interface enough for Sedona to consume and produce GEOGRAPHY values efficiently? Or would Sedona not be able to directly use Flink’s internal interface for computation and still need to convert to its own internal representation?
3. If GEOGRAPHY does not support cast to STRING, how will values be displayed in SQL Client, TableResult.print(), and SQL Gateway results? Do we plan to add a display-specific converter, or should explicit cast to STRING be supported?
4. Could the FLIP define the SQL semantics of GEOGRAPHY more explicitly? For example, equality, comparability, GROUP BY and DISTINCT .
A couple of minor issues:
a. The JTS license in the document seems inaccurate.
b. GEOMETRYCOLLECTION is listed as supported, but also appears in future work.
----------
Best regards,
dylanhz
> 2026年6月9日 02:32，David Chaava via dev <de...@flink.apache.org> 写道：
>
> Hi Martijn,
>
>
>
> Thanks for raising this point. I updated the proposal with a dedicated
> Calcite / Planner Integration section to clarify how `GEOGRAPHY` and the
> proposed `ST_*` functions fit into Flink's SQL/planner path.
>
>
>
> Please let us know if this addresses the question or if there are any
> additional
> planner details you would like us to cover.
>
>
>
> Thanks
>
> On Mon, Jun 8, 2026 at 11:46 AM Martijn Visser <ma...@apache.org>
> wrote:
>
>> Hi David,
>>
>> Thanks for the FLIP. It doesn't contain any information/reference to
>> Calcite though. Are you not planning to leverage Calcite at all for
>> this?
>>
>> Best regards,
>>
>> Martijn
>>
>> Op vr 5 jun 2026 om 10:19 schreef David Chaava via dev <
>> dev@flink.apache.org>:
>>>
>>> lHi everyone,
>>>
>>> I would like to start a discussion on FLIP-XXX: GEOGRAPHY type in Flink
>> SQL
>>> and Table API [1].
>>>
>>> Flink currently has no first-class geospatial type. Users working with
>>> geographic data are forced into unsatisfying workarounds — encoding
>>> geometries as raw strings, storing binary blobs, or pulling in external
>>> libraries with no SQL-level integration. None of these options are
>>> ergonomic, interoperable, or type-safe.
>>>
>>> We propose introducing a native GEOGRAPHY type to Flink SQL and the Table
>>> API, bringing first-class geospatial support to streaming and batch
>>> pipelines. The key changes are:
>>>
>>> 1. New GEOGRAPHY Type - A dedicated logical type representing geospatial
>>> values (points, lines, polygons, etc.) following the WKT/WKB standard,
>> with
>>> proper serialization and catalog integration.
>>>
>>> 2. Built-in Geospatial Functions - A set of SQL functions (e.g.
>>> ST_Distance, ST_Contains, ST_AsText) enabling spatial predicates and
>>> transformations directly in SQL queries.
>>>
>>> 3. Connector & Format Support - Pluggable encoding support so connectors
>>> can read and write GEOGRAPHY values in standard formats (WKT, WKB,
>> GeoJSON).
>>>
>>> Looking forward to your feedback!
>>>
>>> Best regards,
>>> David Chaava
>>>
>>> [1]
>>>
>> https://docs.google.com/document/d/1rpOTETT_Ui3TlEGioUr2NKJ1p1dlxjJQudXHndxBpO0/edit?usp=sharing
>>
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by David Chaava via dev <de...@flink.apache.org>.
Hi Martijn,
Thanks for raising this point. I updated the proposal with a dedicated
Calcite / Planner Integration section to clarify how `GEOGRAPHY` and the
proposed `ST_*` functions fit into Flink's SQL/planner path.
Please let us know if this addresses the question or if there are any
additional
planner details you would like us to cover.
Thanks
On Mon, Jun 8, 2026 at 11:46 AM Martijn Visser <ma...@apache.org>
wrote:
> Hi David,
>
> Thanks for the FLIP. It doesn't contain any information/reference to
> Calcite though. Are you not planning to leverage Calcite at all for
> this?
>
> Best regards,
>
> Martijn
>
> Op vr 5 jun 2026 om 10:19 schreef David Chaava via dev <
> dev@flink.apache.org>:
> >
> > lHi everyone,
> >
> > I would like to start a discussion on FLIP-XXX: GEOGRAPHY type in Flink
> SQL
> > and Table API [1].
> >
> > Flink currently has no first-class geospatial type. Users working with
> > geographic data are forced into unsatisfying workarounds — encoding
> > geometries as raw strings, storing binary blobs, or pulling in external
> > libraries with no SQL-level integration. None of these options are
> > ergonomic, interoperable, or type-safe.
> >
> > We propose introducing a native GEOGRAPHY type to Flink SQL and the Table
> > API, bringing first-class geospatial support to streaming and batch
> > pipelines. The key changes are:
> >
> > 1. New GEOGRAPHY Type - A dedicated logical type representing geospatial
> > values (points, lines, polygons, etc.) following the WKT/WKB standard,
> with
> > proper serialization and catalog integration.
> >
> > 2. Built-in Geospatial Functions - A set of SQL functions (e.g.
> > ST_Distance, ST_Contains, ST_AsText) enabling spatial predicates and
> > transformations directly in SQL queries.
> >
> > 3. Connector & Format Support - Pluggable encoding support so connectors
> > can read and write GEOGRAPHY values in standard formats (WKT, WKB,
> GeoJSON).
> >
> > Looking forward to your feedback!
> >
> > Best regards,
> > David Chaava
> >
> > [1]
> >
> https://docs.google.com/document/d/1rpOTETT_Ui3TlEGioUr2NKJ1p1dlxjJQudXHndxBpO0/edit?usp=sharing
>
Re: [DISCUSS] FLIP-XXX: GEOGRAPHY type in Flink SQL and Table API
Posted by Martijn Visser <ma...@apache.org>.
Hi David,
Thanks for the FLIP. It doesn't contain any information/reference to
Calcite though. Are you not planning to leverage Calcite at all for
this?
Best regards,
Martijn
Op vr 5 jun 2026 om 10:19 schreef David Chaava via dev <de...@flink.apache.org>:
>
> lHi everyone,
>
> I would like to start a discussion on FLIP-XXX: GEOGRAPHY type in Flink SQL
> and Table API [1].
>
> Flink currently has no first-class geospatial type. Users working with
> geographic data are forced into unsatisfying workarounds — encoding
> geometries as raw strings, storing binary blobs, or pulling in external
> libraries with no SQL-level integration. None of these options are
> ergonomic, interoperable, or type-safe.
>
> We propose introducing a native GEOGRAPHY type to Flink SQL and the Table
> API, bringing first-class geospatial support to streaming and batch
> pipelines. The key changes are:
>
> 1. New GEOGRAPHY Type - A dedicated logical type representing geospatial
> values (points, lines, polygons, etc.) following the WKT/WKB standard, with
> proper serialization and catalog integration.
>
> 2. Built-in Geospatial Functions - A set of SQL functions (e.g.
> ST_Distance, ST_Contains, ST_AsText) enabling spatial predicates and
> transformations directly in SQL queries.
>
> 3. Connector & Format Support - Pluggable encoding support so connectors
> can read and write GEOGRAPHY values in standard formats (WKT, WKB, GeoJSON).
>
> Looking forward to your feedback!
>
> Best regards,
> David Chaava
>
> [1]
> https://docs.google.com/document/d/1rpOTETT_Ui3TlEGioUr2NKJ1p1dlxjJQudXHndxBpO0/edit?usp=sharing