Hi Julian, Thank you for the thoughtful questions, especially about how we can keep the implementation small and maintainable. I shared my thoughts in the other branch of the discussion and wanted to link to that reply here for anyone following this branch.
https://lists.apache.org/thread/n6xdnnbf5o627bwl626jyhtvfvvmpnn5 Best, David On Tue, Nov 3, 2026 at 7:11 PM Julian Hyde <[email protected]> wrote: > There are a lot of geospatial functions. Would the functions that > currently take GEOMETRY also be applicable to GEOGRAPHY? Do we need > additional functions for the GEOGRAPHY type? > > Is GEOGRAPHY a subtype if GEOMETRY (in the sense that a GEOGRAPHY value > can be used as an argument to a function with a GEOMETRY parameter? > > I worry about this change creating a lot of new code (possibly copy-pasted > from existing code, possibly generated by agents, but nevertheless > requiring maintenance). Give me a sense of the amount of new code that > would be required, and which components it would reside in. > > I wonder whether GEOGRAPHY could be a GEOMETRY type with a constraint > “srid IS NOT NULL”. We cannot currently attach constraints to types (except > the constraints that are represented as type parameters, e.g. VARCHAR(10) > is “a string whose length is not greater than 10”). Is a constrained > GEOMETRY type the right way to think of this? If so, attaching constraints > to types might be a way to reduce the amount of code that has to be written. > > (I had a similar thought about constraints and types when we had the > discussion about the VECTOR type. I still believe that the VECTOR type is > basically an ARRAY type where the length is a constant. My work on Morel, > and its elegant type system based on Standard ML’s modules and functors, > makes me think about how we remove/reduce code by improving our type > system.) > > Julian > > > > On Nov 3, 2026, at 8:24 AM, Jerome Haltom <[email protected]> > wrote: > > > > I approve of this, as it would let me deprecate my existing > geography-like support. > > > > > https://github.com/ikvmnet/calcite-dotnet/tree/main/src/Apache.Calcite.Geography > > > > This will be weird for you guys, since it's .NET code. But it's an > attempt at a full suite of Geography functions across the existing geometry > types. It is only WGS84 however. It uses S2 and > net.sf.geographiclib:GeographicLib-Java > > > > > > > > ________________________________ > > From: David Chaava via dev <[email protected]> > > Sent: Tuesday, November 03, 2026 08:51 > > To: [email protected] <[email protected]> > > Cc: [email protected] <[email protected]>; [email protected] < > [email protected]>; David Chaava <[email protected]> > > Subject: [DISCUSS] Planner-level GEOGRAPHY type in Apache Calcite > > > > Hi Calcite community, > > > > We would like to discuss adding GEOGRAPHY as a first-class SQL and > > relational type in Calcite, distinct from the existing GEOMETRY type. > > > > This follows the discussion about native GEOGRAPHY support in Flink [1], > > motivated in part by interoperability with Iceberg geography columns. > > Participants raised concerns about maintaining a Flink-only planner type, > > handling validation and type-system edge cases, and eventually migrating > to > > an upstream Calcite type. We would like to address these concerns > through a > > Calcite contribution. > > > > Our proposal is available here [2]. > > > > The proposed first change covers parsing, validation, relational type > > propagation, and unparsing, including nullability, type coercion rules, > > nested types, and SQL/Rel round trips. A separate type family would > > preserve the distinction between geographic and planar values and prevent > > existing GEOMETRY functions from accepting GEOGRAPHY operands > > unintentionally. > > > > The initial type would be unparameterized and independent of a particular > > runtime representation. The proposal leaves CRS/SRID metadata, encoding, > > and runtime execution to consuming engines and adapters. It does not > > introduce spatial functions, constructors, serialization/deserialization, > > or storage-format mappings. > > > > We also want to build on the Sedona discussion. Jia clarified that > > SedonaFlink already supports Geography through RAW with a dedicated > > serializer, and called for joint consideration of CRS/SRID, > spherical-edge > > semantics, validation, equality, and shared serialization. The limited > > Calcite scope proposed here is intended as a first step; it does not > settle > > those broader interoperability choices or assume that Sedona would adopt > a > > particular runtime representation. > > > > We would appreciate feedback on two main questions: > > > > 1. Should Calcite expose an unparameterized, representation-neutral > > GEOGRAPHY type distinct from GEOMETRY? > > 2. Is the proposed parser/validator/type-system scope sufficient for a > > first contribution without constructors or a Calcite runtime value > class? > > > > In considering these questions, we would particularly welcome feedback on > > the proposed semantic boundary: same-type equality is permitted with > > adapter-defined execution semantics, ordering is rejected, and CRS/SRID > is > > not encoded in the Calcite type. Are additional guarantees needed at the > > planner level? > > > > Subject to Calcite review and acceptance, the intended integration path > is > > to merge the necessary support upstream, then bring those changes into > > Flink, with any temporary copies removed when Flink upgrades its Calcite > > dependency. We would also welcome suggestions for regression cases, > > particularly around null handling, nested types, and type-to-SQL > conversion. > > > > The Flink dev list and Jia are copied to help coordinate the discussion. > > Thank you for your feedback. > > > > Best regards, > > David > > > > [1] Flink GEOGRAPHY discussion > > <https://lists.apache.org/thread/flbj8dfdfgs26klrxt7xch3r9785ky67> > > [2] Planner-level GEOGRAPHY type in Apache Calcite proposal > > < > https://docs.google.com/document/d/1Btqd0oZT8ctqIaGI_AROyAFJQe68RsVyeQbtmK4wHQw/edit > > > >
