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 <[email protected]> 写道： > > 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 <[email protected]> > 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 < >> [email protected]>: >>> >>> 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 >>
