[
https://issues.apache.org/jira/browse/CALCITE-4294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17596916#comment-17596916
]
Julian Hyde edited comment on CALCITE-4294 at 8/29/22 6:02 PM:
---------------------------------------------------------------
As a general rule, tests should not require that [floating point numbers
exactly match|https://blog.marcinchwedczuk.pl/doubles-and-unit-testing].
Floating point calculations can get re-ordered or optimized, which results in
different rounding errors.
In {{SqlOperatorTest}} we use {{{}isWithin{}}}:
{code:java}
f.checkScalarApprox("{fn ACOS(0.2)}", "DOUBLE NOT NULL",
isWithin(1.36943, 0.001));
{code}
You seem to be having the analogous problem with floats in geometries. The
easiest solution may be to round all floats in a geometry value to (say) .0001
degrees, and compare to that rounded value. If I were in your shoes I would
write a function {{roundGeometry4(String)}} that would for example convert the
string
{code}
POLYGON ((-71.1776848522251 42.39028965129019, -71.17768437663263
42.390382947800894, -71.17758443054647 42.39038266779173, -71.17758259272306
42.39028936479872, -71.1776848522251 42.39028965129019)){code}
to
{code}
POLYGON ((-71.1777 42.3903, -71.1777 42.3904, -71.1776 42.3904, -71.1776
42.3903, -71.1777 42.3903)){code}
A function that worked directly on the geometry object might seem better, but
might not handle all geometry types reliably; because this works on a string,
there's a simple implementation using regex. The expected strings are shorter,
and therefore easier for humans to check. If the 4th decimal place of a test's
output actually matters then we should probably write tests with larger
geometry objects.
was (Author: julianhyde):
As a general rule, tests should not require that [floating point numbers
exactly match|https://blog.marcinchwedczuk.pl/doubles-and-unit-testing].
Floating point calculations can get re-ordered or optimized, which results in
different rounding errors.
In {{SqlOperatorTest}} we use {{isWithin}}:
{code}
f.checkScalarApprox("{fn ACOS(0.2)}", "DOUBLE NOT NULL",
isWithin(1.36943, 0.001));
{code}
You seem to be having the analogous problem with floats in geometries. The
easiest solution may be to round all floats in a geometry value to (say) .0001
degrees, and compare to that rounded value. If I were in your shoes I would
write a function {{roundGeometry4(String)}} that would for example convert the
string "POLYGON ((-71.1776848522251 42.39028965129019, -71.17768437663263
42.390382947800894, -71.17758443054647 42.39038266779173, -71.17758259272306
42.39028936479872, -71.1776848522251 42.39028965129019))" to "POLYGON
((-71.1777 42.3903, -71.1777 42.3904, -71.1776 42.3904, -71.1776 42.3903,
-71.1777 42.3903))". A function that worked directly on the geometry object
might seem better, but might not handle all geometry types reliably; because
this works on a string, there's a simple implementation using regex. The
expected strings are shorter, and therefore easier for humans to check. If the
4th decimal place of a test's output actually matters then we should probably
write tests with larger geometry objects.
> Use JTS rather than ESRI as the underlying library for geospatial (ST_)
> functions
> ---------------------------------------------------------------------------------
>
> Key: CALCITE-4294
> URL: https://issues.apache.org/jira/browse/CALCITE-4294
> Project: Calcite
> Issue Type: Bug
> Components: spatial
> Reporter: Julian Hyde
> Assignee: Bertil Chapuis
> Priority: Major
> Fix For: 1.32.0
>
>
> The geospatial functions are currently implemented using the ESRI library. We
> should consider using JTS instead. AT the time we started work on geospatial
> the JTS did not have a suitable license, but this is no longer the case. I
> gather that JTS is a superior library.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
