Hi all, I helped with the JTS-based geometry support, so here are a few comments.
Geometry values already carry an SRID, but that doesn’t make them geographies: a geometry in SRID 4326 is still planar. With JTS, geometry treats lon/lat as x/y and joins vertices with straight lines on a plane. Geography joins them with arcs on the sphere. Since the same coordinates give different answers, I would probably treat geography as a distinct type with no implicit casts. https://postgis.net/workshops/postgis-intro/geography.html For a runtime, JTS could probably work as the value model for geography, geometry, and for WKT/WKB. We could probably get quite far with a small subset of functions that need a spherical kernel, such as intersects, distance, length and area, and rely on JTS for parsing, serialization and simple accessors. It’s indeed a fair amount of code, but it would mostly sit in well-isolated UDFs. Still, test and maintainance is the hard part. Best, Bertil On Tue, 3 Nov 2026 at 20:05, Julian Hyde <[email protected]> wrote: > Is there actually a requirement to overload? The function could check at > runtime whether it has a GEOMETRY or GEOGRAPHY value. > > > On Nov 3, 2026, at 10:54 AM, Jerome Haltom <[email protected]> > wrote: > > > > It has been a couple months since I had thought through this, but I > think the downside of my approach was there was no way to overload > functions in a way that made sense. I don't think you could overload by > constraint. > > > > So, so you couldn't validate. Which most engines do. > > > > ________________________________ > > From: Julian Hyde <[email protected]> > > Sent: Tuesday, November 03, 2026 12:11 > > To: [email protected] <[email protected]> > > Subject: Re: [DISCUSS] Planner-level GEOGRAPHY type in Apache Calcite > > > > 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 > > > > > >
