GEO_CONTAINS() incorrect evaluation in 3.11.2, correct in 3.9.3

[dbenesj]

My Environment

• ArangoDB Version: 3.11.2
• Deployment Mode: Single Server
• Deployment Strategy: Manual Start in Docker
• Configuration: all defaults
• Infrastructure: own
• Total RAM in your machine: 16GB
• Disks in use: HDD
• Used Package: Docker - official Docker library

Component, Query & Data

Affected feature:
AQL query using web interface, GEO_CONTAINS() function

AQL query (if applicable):

let polygon = GEO_POLYGON([
		[19, 47], [16, 47], [16, 49], [19, 49], [19, 47]
])
let point = [18, 48]
// does not matter whether point is defined this way or any other way
// let point = GEO_POINT(18, 48)
// let point = {'type': 'Point','coordinates': [18, 48]}
return GEO_CONTAINS(polygon, point)

AQL explain and/or profile (if applicable):

Query String (138 chars, cacheable: true):
 let polygon = GEO_POLYGON([
 		[19, 47], [16, 47], [16, 49], [19, 49], [19, 47]
 ])
 let point = [18, 48]
 return GEO_CONTAINS(polygon, point)

Execution plan:
 Id   NodeType          Est.   Comment
  1   SingletonNode        1   * ROOT
  4   CalculationNode      1     - LET arangodb/arangodb#2 = false   /* json expression */   /* const assignment */
  5   ReturnNode           1     - RETURN arangodb/arangodb#2

Indexes used:
 none

Optimization rules applied:
 Id   RuleName
  1   move-calculations-up
  2   remove-unnecessary-calculations

Query Statistics:
 Writes Exec   Writes Ign   Scan Full   Scan Index   Cache Hits/Misses   Filtered   Peak Mem [b]   Exec Time [s]
           0            0           0            0               0 / 0          0              0         0.00054

Query Profile:
 Query Stage               Duration [s]
 initializing                   0.00000
 parsing                        0.00006
 optimizing ast                 0.00016
 loading collections            0.00001
 instantiating plan             0.00004
 optimizing plan                0.00019
 instantiating executors        0.00004
 executing                      0.00004
 finalizing                     0.00003

Dataset:
no need for the dataset, just what is provided in AQL is enough

Steps to reproduce

just execute provided AQL

Problem:
this AQL evaluetes to false in 3.11.2, but to true in 3.9.3
3.9.3 behavior is correct in my opinion

Expected result:
should return true also in 3.11.2 version

[MBkkt]

arangodb/arangodb#19215 (comment)

[dbenesj]

@MBkkt thank you for that link.
I saw and read through that before opening this one, but understood, that mentioned one is about an index. Which is not used in this case.
Tried to reverse the order of points in polygon definition and it indeed resulted into expected response also in 3.11.2 👍

Could you please describe in more detail what is mean of the right hand side ordering of points within the polygon definition?
As we are retriving those points from user inputs, we would need to make sure the order is as necessary for ArangoDB and reorder them if need.

As a sidenote, it would be wonderful if GEO_POLYGON function makes sure of those requirements. Or at least mentioning such requirement in the Geo functions section of the documentation.

[MBkkt]

For just aql function (not handled by geo or inverted index) it's impossible to use old behavior :(

[MBkkt]

Could you please describe in more detail what is mean of the right hand side ordering of points within the polygon definition?

exists two way to specify polygon:

            point_a



point_c                   point_b

1. [point_a, point_b, point_c, point_a] -- left hand rule, cw (clock wise)
   and
2. [point_a, point_c, point_b, point_a] -- right hand rule, ccw (counter clock wise)

If both mean same, it's impossible to specify polygon bigger than half world.
(It could be useful to specify something like everything except this small polygon)

Before 3.10 it was same for arangodb, starting from 3.10, we change it, and use right hand rule (2) to define "small" polygons (same as GeoJson standard), and opposite to define "big"

[MBkkt]

https://www.arangodb.com/docs/stable/indexing-geo.html#geojson-interpretation

[dbenesj]

Aha, I see, thank you very much for description and link. Now it makes complete sense. And my tests confirms the behavior.
Still, having some mention also in the Geo functions would be nice as it affects them even without using the Geo index.

[Simran-B]

@dbenesj The documentation team will look into making this information more visible, thank you!