Mathematics of distance and area calculations on an ellipsoid

[cportele]

Meeting 2020-09-14: We need to check what we need to say about this in the document, to make implementers aware of what they need to know. Have a look at the material created by John Herring.

[cportele]

Meeting 2020-10-12: @cportele will review this and propose any actions, most likely informative text pointing to the additional documentation.

[cportele]

I don't think that strictly we have to say anything on the topic, since CQL as currently defined only supports the topological relationships and does not specify operators or functions that compute or depend on the length of a curve or the area of a surface.

But maybe we should point out in the spatial operator section that Simple Features (the normative reference for the spatial operators) assumes Euclidean geometry / Pythagorean metric. See the note under the definition of "4.19 simple feature".

[jratike80]

There is a note in http://docs.ogc.org/DRAFTS/19-079.html#simple-cql_spatial

 # NOTE: The buffer operators (DWITHIN and BEYOND) are not included because
 #       these are outside the scope of a "simple" core for CQL.  These
 #       can be added as extensions.

There is also "Example 14. Example of a spatial relationship between a property and a function that return a geometry value." that is using buffer

road WITHIN Buffer(geometry,10,"m")

Perhaps this example should be removed or changed to use for example Envelope instead because the example may lead readers to think that this extension defines also the buffer function and its usage.

[cportele]

Thanks @jratike80 - good point. I will update the example.

[pvretano]

@jratike80 @cportele The unsupported operators are DWITHIN and BEYOND. This example does not make use of either and the example clearly states that this illustrates a predicate with a spatial operator (i.e. WITHIN) and a function (i.e. Buffer()). What if I add additional text clarifying that Buffer() is not part of the CQL language but simply a function that an implementation MAY provide.

[jratike80]

I try to prepare for the wrong interpretations that the developers and users will make in the future. It is clear for us that Buffer is used as an example of a function that returns a geometry. But because it is an example, does it need to be just Buffer that most probably will be defined later in some extension? Then the usage may not be exactly Buffer(geometry,10,"m"), or at least it may have optional parameters for making a selection between cartesian length vs. length along ellipsoid, mitre shapes etc.

I was thinking that Envelope is by nature so well defined that it cannot lead to any trouble ever but additional text is a good alternative.