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 <[email protected]> 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 <[email protected]> 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 <[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 > > >> > > > > -- Best regards, Sergey
