Hi Julian,

the Flink community is very thankful for the OpenGIS efforts done by the Calcite community and I think both project can benefit from it. As Xingcan mentioned, we are thinking about contributing a GeoOperatorTable similar to SqlStdOperatorTable. We don't want to reimplement the functions. The only concern that I raised was about exposing the data type through Flink. Instead of exposing `org.apache.calcite.runtime.GeoFunctions.Geom` as a type to our users, I was thinking about a Flink specific type that implements the interface. Flink also needs to implement serializers for this type.

We saw that GeoFunctions has a `protected bind()` method and were wondering if one could open the binding/type creation and make it more flexible.

Regards,
Timo


Am 23.05.18 um 19:19 schrieb Julian Hyde:
I am wondering why it is necessary to have a different geometry type in Flink 
than in Calcite.

If you think that the implementation in Calcite sucks, then rather than making 
a different one for Flink, how about making a different one for Calcite, and 
use that in Flink? I’m not super-proud of the implementation in Calcite; it was 
the best I could do given the time available.

In Calcite we are extremely short of development resources. All of the spatial 
work in Calcite has been done by me, on my own time. It is depressing to see 
someone use it and immediately decide they are going to re-implement it all in 
their own project.

Julian



On May 22, 2018, at 8:28 PM, Xingcan Cui <xingc...@gmail.com> wrote:

Hi all,

Recently, the flink community aims to add some OpenGIS functions (see
FLINK-9219 <https://issues.apache.org/jira/browse/FLINK-9219>) provided in
CALCITE-1968 <https://issues.apache.org/jira/browse/CALCITE-1968>. For some
reasons, we plan to implement some Flink Geom types (as illustrated in this
comment
<https://issues.apache.org/jira/browse/FLINK-9219?focusedCommentId=16483965&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16483965>),
but the private constructor in `o.a.c.r.GeoFunctions` makes that impossible.

We are confused about the protected method `bind()`, as well as other
private modifiers in `o.a.c.r.GeoFunctions`. I wonder if someone could help
to give some explanations about that. Do we in the right direction?

Besides, maybe there should be a new Geom operand type in
`o.a.c.q.t.OperandTypes`?

Thanks,
Xingcan


Reply via email to