[jira] [Created] (CALCITE-5276) Implicitly convert strings to geometries
Bertil Chapuis created CALCITE-5276: --- Summary: Implicitly convert strings to geometries Key: CALCITE-5276 URL: https://issues.apache.org/jira/browse/CALCITE-5276 Project: Calcite Issue Type: Improvement Reporter: Bertil Chapuis -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5280) Implement geometry aggregate functions
Bertil Chapuis created CALCITE-5280: --- Summary: Implement geometry aggregate functions Key: CALCITE-5280 URL: https://issues.apache.org/jira/browse/CALCITE-5280 Project: Calcite Issue Type: Improvement Components: core Reporter: Bertil Chapuis Geometry aggregate functions (ST_Accum, ST_Collect, and ST_Union) are currently missing in Calcite. Using an AggregateFunctionImpl looks be pretty straightforward, but many aggregate function implement SqlAggFunction directly. What would be the best way to implement them? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5281) Implement geometry set returning functions (SRF)
Bertil Chapuis created CALCITE-5281: --- Summary: Implement geometry set returning functions (SRF) Key: CALCITE-5281 URL: https://issues.apache.org/jira/browse/CALCITE-5281 Project: Calcite Issue Type: Improvement Components: core Reporter: Bertil Chapuis The idea is to implement set returning functions, such as ST_Explode in H2GIS and ST_Dump in PostGIS. Is the Uncollect class a good starting point? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5303) Add support for overloaded aggregate functions
Bertil Chapuis created CALCITE-5303: --- Summary: Add support for overloaded aggregate functions Key: CALCITE-5303 URL: https://issues.apache.org/jira/browse/CALCITE-5303 Project: Calcite Issue Type: New Feature Reporter: Bertil Chapuis The idea would be to make the validation and function resolution process more robust in the presence of overloaded aggregate functions. When determining if a function is an aggregate, the validator simply checks if one of the matching functions is an aggregate. The number of operands, their type, and the precedence of scalar function over aggregate functions are not taken into account. https://issues.apache.org/jira/browse/CALCITE-5280 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5309) Accept cursors as inputs of table functions
Bertil Chapuis created CALCITE-5309: --- Summary: Accept cursors as inputs of table functions Key: CALCITE-5309 URL: https://issues.apache.org/jira/browse/CALCITE-5309 Project: Calcite Issue Type: New Feature Reporter: Bertil Chapuis The TableFunctionTest.testTableFunctionCursorsInputs is currently disabled and a note says that it could not be implemented. This feature is necessary to implement table functions that take a query or a table as an input. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5362) Implement geometry measurement functions
Bertil Chapuis created CALCITE-5362: --- Summary: Implement geometry measurement functions Key: CALCITE-5362 URL: https://issues.apache.org/jira/browse/CALCITE-5362 Project: Calcite Issue Type: New Feature Components: core Reporter: Bertil Chapuis Assignee: Bertil Chapuis The following spatial measurement functions are yet to be implemented: * ST_Area * ST_ClosestCoordinate * ST_ClosestPoint * ST_FurthestCoordinate * ST_Length * ST_LocateAlong * ST_LongestLine * ST_MaxDistance * ST_Perimeter * ST_ProjectPoint -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5367) Implement geometry editing functions
Bertil Chapuis created CALCITE-5367: --- Summary: Implement geometry editing functions Key: CALCITE-5367 URL: https://issues.apache.org/jira/browse/CALCITE-5367 Project: Calcite Issue Type: New Feature Components: core Reporter: Bertil Chapuis Assignee: Bertil Chapuis The following spatial measurement functions are yet to be implemented: * ST_AddPoint * ST_CollectionExtract * ST_Densify * ST_FlipCoordinates * ST_Holes * ST_Normalize * ST_RemoveDuplicatedCoordinates * ST_RemoveHoles * ST_RemovePoints * ST_RemoveRepeatedPoints * ST_Reverse -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5399) Remove Prov4j from Apache Calcite
Bertil Chapuis created CALCITE-5399: --- Summary: Remove Prov4j from Apache Calcite Key: CALCITE-5399 URL: https://issues.apache.org/jira/browse/CALCITE-5399 Project: Calcite Issue Type: Bug Reporter: Bertil Chapuis As explained by [~desruisseaux] in [1], despite being released with an Apache compatible license, Proj4j is a problematic dependency. The EPSG codes used by Proj4j come with restrictive terms of use and we should find an alternative. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5417) Include Proj4J as an api dependency once the license allows it
Bertil Chapuis created CALCITE-5417: --- Summary: Include Proj4J as an api dependency once the license allows it Key: CALCITE-5417 URL: https://issues.apache.org/jira/browse/CALCITE-5417 Project: Calcite Issue Type: Bug Reporter: Bertil Chapuis The EPSG dataset is [scheduled to be removed|https://github.com/locationtech/proj4j/issues/90] from Proj4J. Once this change is released, we will be able to include it as an api dependency and to revert the changes introduced in CALCITE-5399. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5419) Verify that null values are handled properly by spatial type functions
Bertil Chapuis created CALCITE-5419: --- Summary: Verify that null values are handled properly by spatial type functions Key: CALCITE-5419 URL: https://issues.apache.org/jira/browse/CALCITE-5419 Project: Calcite Issue Type: Bug Reporter: Bertil Chapuis We should verify that null values are handled properly in the spatial type functions. We should add test cases to spatial.iq to ensure that this is the case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5437) Implement st_explode with a cursor
Bertil Chapuis created CALCITE-5437:
---
Summary: Implement st_explode with a cursor
Key: CALCITE-5437
URL: https://issues.apache.org/jira/browse/CALCITE-5437
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Bertil Chapuis
The goal is to implement ST_Explode with a cursor function, so that the
geometry column of a row can be unnested into multiple rows. Ideally, we would
like to execute a query such as the following:
SELECT *FROM table(ST_Explode(cursor(
SELECT ST_GeomFromText('MULTIPOINT((1 1), (2 2))') as points
UNION ALL SELECT ST_GeomFromText('MULTIPOINT((3 3), (4 4))') as points
)));
GEOM, INDEXPOINT (1 1), 0
POINT (2 2), 1
POINT (3 3), 0
POINT (4 4), 1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6239) Add a postgis dialect that supports ST functions
Bertil Chapuis created CALCITE-6239: --- Summary: Add a postgis dialect that supports ST functions Key: CALCITE-6239 URL: https://issues.apache.org/jira/browse/CALCITE-6239 Project: Calcite Issue Type: New Feature Components: core Reporter: Bertil Chapuis Calcite implements support for spatial types (geometry, point, etc.) and spatial functions (ST_), and it can connect to PostGIS via a JdbcSchema. However, the Postgresql dialect does not currently handle spatial types and functions. As a result, Calcite tries to execute the spatial functions at the level of the JVM instead of pushing them down to postgis. As a result, the following query gets executed, but the type of the geom column is incorrect: SELECT id, geom FROM public.spatial_table The following query fails with a ClassCastException as Calcite tries to use the java implementation of the ST_SRID function: SELECT id, ST_SRID(geom) FROM public.spatial_table java.lang.ClassCastException: class org.postgresql.util.PGobject cannot be cast to class org.locationtech.jts.geom.Geometry (org.postgresql.util.PGobject and org.locationtech.jts.geom.Geometry are in unnamed module of loader 'app') In my current understanding, this issue could be addressed with a new PostgisSqlDialect that extends PostgresqlSqlDialect and adds support for spatial types and functions. Here is a tentative roadmap: - Add all the spatial functions to the SqlKind class - Create a PostgisSqlDialect class that extends PostgresqlSqlDialect - Add support for the spatial types (geometry) by overriding the getCastSpec method of the SqlDialect class - Add support for the spatial functions by overriding the supportsFunction method of the SqlDialect class - Add support for the spatial aggregate functions by overriding the supportsAggregateFunction method of the SqlDialect class -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6263) Discuss the coupling of Calcite with JTS
Bertil Chapuis created CALCITE-6263: --- Summary: Discuss the coupling of Calcite with JTS Key: CALCITE-6263 URL: https://issues.apache.org/jira/browse/CALCITE-6263 Project: Calcite Issue Type: New Feature Components: jdbc-adapter Reporter: Bertil Chapuis In order to push ST functions down to Postgis in the JDBC adapter, it is necessary to register a type family for geometries in [RelDataTypeFactoryImpl.java|https://github.com/apache/calcite/pull/3668/files#diff-0fa7bd8b0354c8a4c331efa4107242e49c5d521f31adbb71388bcbc9acb7a384]. This changes increases the coupling of Calcite to a geometry library such as JTS. As this is an architectural change, a few options can be considered: # Accepting the coupling of Calcite with JTS. # Introducing an abstraction for geometry libraries in Calcite. # Using reflection to register the type family only if JTS is available in the classpath. Personally, I have a preference for options 1 and 3. Option 3, which is currently implemented in [CALCITE-6239|https://github.com/apache/calcite/pull/3668] has little impact on the current behavior. Option 2 would introduce some additional complexity. For context, here is a [link|https://github.com/apache/calcite/pull/3668#discussion_r1486925458] to the original discussion. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6264) Implement ST functions for the TWKB format
Bertil Chapuis created CALCITE-6264: --- Summary: Implement ST functions for the TWKB format Key: CALCITE-6264 URL: https://issues.apache.org/jira/browse/CALCITE-6264 Project: Calcite Issue Type: New Feature Reporter: Bertil Chapuis TWKB is a popular format supported by postgis. Calcite does not have support for the related ST functions (ST_AsTWKB, ST_GeomFromTWKB). JTS recenlty added support for TWKB so the implementation of these functions should be rather straight forward. [https://locationtech.github.io/jts/javadoc-io/index.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6271) The supportsFunction method of the SqlDialect class is never called in calcite
Bertil Chapuis created CALCITE-6271: --- Summary: The supportsFunction method of the SqlDialect class is never called in calcite Key: CALCITE-6271 URL: https://issues.apache.org/jira/browse/CALCITE-6271 Project: Calcite Issue Type: Bug Components: core Reporter: Bertil Chapuis Several sql dialects implement the supportsFunction method. However, after searching Calcite's code base, it looks like this function is never called. This seems to affects the ablity to push functions down such as in CALCITE-6239. -- This message was sent by Atlassian Jira (v8.20.10#820010)
