Thank you for your answers and for the pointers. > PS Regarding which specification we choose to implement. The four principles > you outline sound good to me. It’s always better to follow the standard. If > leading implementations (e.g. PostGIS and H2GIS) diverge from the standard, > we can make a note, and possibly support them as secondary implementations. > > Sometimes there are compatible extensions. E.g. the OpenGIS function has two > arguments, and the PostGIS version accepts two or three arguments. If someone > calls Calcite's implementation of the function with three arguments, it is > reasonable that they get the PostGIS behavior.
My feeling is that spatial is a rather small niche and that developers do not necessarily seek compatibility with Postgis or H2GIS. Personally, I almost always have to refer to the documentation of the RDBMS when writing queries that use spatial functions and I have few expectations regarding their behaviour beyond what is stated in the documentation. In this regard, I feel that a good standalone documentation is preferable to a documentation with references to other implementations that may differ in subtle ways. >> Similar issues have come up with non-GIS functions. For example, the >> DATEDIFF function [1]. Snowflake and MSSQL have ‘DATEDIFF(timeUnit, >> datetime, datetime2)’, whereas MySQL has ‘DATEDIFF(date, date2)’. We >> document which specification we implement, and potentially we could >> implement both specifications, as either functions with different names, or >> by selectively enabling the behavior that the user wants. >> >> The most important thing is to document which specification we are >> implementing (when there is ambiguity). Then if someone would prefer the >> other specification, they can contribute an implementation, and we can >> selectively enable it. Do you think we should eventually add a @LibraryOperator for spatial type functions (i.e. OpenGIS, Postgis, H2GIS)? There is still a TODO (prior to the changes I made) in the SpatialTypeFunctions class asking the following question: Should we create aliases for functions in upper-case [1]? My current understanding of this question is that a possibility may be to have a method named “buffer” in the class and an alias named “ST_Buffer” registered somewhere else. Appart from resolving lots of sonar code smells related to method names, this approach would allow to more easily introduce new methods that don’t have ST_ counterparts in other RDBMS. After merging CALCITE-5367 [2], I think we will have a relatively decent support for spatial types in core. At this stage, I think it would be good to see if the organisation of the code can be improved before investigating support for more advanced spatial functions (e.g. 3D, ST_AsMVT, ST_AsFlatGeobuf, etc.). [1] https://github.com/apache/calcite/blob/ee9b80b0b68d442991dfaa142722e3488ec73e79/core/src/main/java/org/apache/calcite/runtime/SpatialTypeFunctions.java#L94 <https://github.com/apache/calcite/blob/ee9b80b0b68d442991dfaa142722e3488ec73e79/core/src/main/java/org/apache/calcite/runtime/SpatialTypeFunctions.java#L94> [2] https://github.com/apache/calcite/pull/3088 <https://github.com/apache/calcite/pull/3088> [3] https://issues.apache.org/jira/browse/CALCITE-5309 <https://issues.apache.org/jira/browse/CALCITE-5309>
