I've tried to cast the Zip's loc column into double like this:
SELECT
"city", cast("loc" [0] AS DOUBLE) AS "lon", cast("loc" [1] AS DOUBLE) AS
"lat"
FROM "geode"."Zips"
LIMIT 10;
This seems to work fine. But when i try to use the ST_Point function i
get: "No match found for function signature ST_Point(<NUMERIC>, <NUMERIC>)"
(full stack is below)
It seems like i've not registered a jar dependency or haven't enabled
something else?
jdbc:calcite:conformance=LENIENT> SELECT "city", "ST_Point"(cast("loc" [0]
AS DOUBLE), cast("loc" [1] AS DOUBLE)) FROM "geode"."Zips"LIMIT 10;
2017-11-28 10:19:15,199 [main] ERROR -
org.apache.calcite.sql.validate.SqlValidatorException: No match found for
function signature ST_Point(<NUMERIC>, <NUMERIC>)
2017-11-28 10:19:15,199 [main] ERROR -
org.apache.calcite.runtime.CalciteContextException: From line 1, column 16
to line 1, column 79: No match found for function signature
ST_Point(<NUMERIC>, <NUMERIC>)
Error: Error while executing SQL "SELECT "city", "ST_Point"(cast("loc" [0]
AS DOUBLE), cast("loc" [1] AS DOUBLE)) FROM "geode"."Zips"LIMIT 10": From
line 1, column 16 to line 1, column 79: No match found for function
signature ST_Point(<NUMERIC>, <NUMERIC>) (state=,code=0)
On 28 November 2017 at 09:32, Christian Tzolov <ctzo...@pivotal.io> wrote:
> @Julian are there some tests, json datasets? Perhaps in
> calcite-test-dataset?
> Also I will try to cast the "loc" from Zips into DOUBLE columns to test
> the ST_Point
>
> On 28 November 2017 at 02:24, Julian Hyde <jh...@apache.org> wrote:
>
>> It’s true that you can’t define a GEOMETRY column in a foreign table. But
>> you can define a VARCHAR column and apply the ST_GeomFromText to it, or if
>> you want a point you can define a pair of DOUBLE columns and apply the
>> ST_Point function.
>>
>> In essence, our implementation of GEOMETRY is only an in-memory format
>> right now, not an on-disk format. It’s a little less efficient than a
>> native GEOMETRY data type but hopefully over time we will write optimizer
>> rules that push down filters etc. so we don’t literally construct an
>> in-memory geometry object for every row, only the rows we are interested in.
>>
>> Julian
>>
>> > On Nov 27, 2017, at 2:59 AM, Christian Tzolov <ctzo...@pivotal.io>
>> wrote:
>> >
>> > Hey there,
>> >
>> > I'm exploring the new Spatial (https://calcite.apache.org/do
>> cs/spatial.html)
>> > functionality and i've been trying to figure out what are the minimal
>> > requirements for using it with my custom adapter.
>> >
>> > Following the guidelines i've set LENIENT conformance in my jdbc URL (
>> > jdbc:calcite:conformance=LENIENT;
>> > model=...my model
>> >
>> >
>> > )
>> >
>> > But I am not sure how define the GEOMETRY column types?
>> >
>> > Currently my custom Schema/Table factory implementation infers the
>> column
>> > types from the underlaying system's field types.
>> >
>> > So it seems that i need to change my implementation and somehow to hint
>> > which fields needs to be mapped to GEOMETRY types? Or perhaps i can
>> try to
>> > do some expensive casting in SQL?
>> >
>> > Are there any guidelines, examples for using Spatial functionality on
>> 3rd
>> > party (e.g. custom) adapters?
>> >
>> > Thanks,
>> > Christian
>>
>>
>
>
> --
> Christian Tzolov <http://www.linkedin.com/in/tzolov> | Principle Software
> Engineer | Spring <https://spring.io/>.io | Pivotal <http://pivotal.io/>
> | ctzo...@pivotal.io
>
--
Christian Tzolov <http://www.linkedin.com/in/tzolov> | Principle Software
Engineer | Spring <https://spring.io/>.io | Pivotal <http://pivotal.io/> |
ctzo...@pivotal.io
