fix: incorrect order of parameters when calling PostGIS functions

[bobeal]

When doing a NGSI-LD Geoquery (4.10):

• The target geometry is the Entity's GeoProperty to which the geoquery is to be applied (location by default)
• The reference geometry is the geometry passed as parameter in the query

Then the semantic of the geospatial relationship is for instance:

• within relationship (production rule named withinRel). For an entity to match, the target geometry shall be
  within, as specified by [14], the reference geometry.

However, in Stellio, we were currently implementing such a query with:

ST_Within(
    referenceGeometry,
    targetGeometry
) 

Which says: Returns TRUE if geometry A is within geometry B (https://postgis.net/docs/ST_Within.html). Which is the opposite of what the specification says and is thus being fixed in this PR.

It should only have impact on geoqueries using contains and within.

[github-actions]

Test Results

   69 files  ±0     69 suites  ±0   1m 26s ⏱️ +7s
1 111 tests +1  1 111 ✅ +1  0 💤 ±0  0 ❌ ±0 
1 150 runs  +1  1 150 ✅ +1  0 💤 ±0  0 ❌ ±0 

Results for commit 4c50dea. ± Comparison against base commit e535bee.

This pull request removes 199 and adds 44 tests. Note that renamed tests count towards both.

                                    { "id":…, withTemporalValues=true, withAudit=false, expectation={
                      "@id": "https://uri…
                      "@type": "@json",
                      …
                    "@value": "/A/B"
                    "@value": "/C/D"
                    "@value": 20
                    "…
                    {
                  "@type": "https://uri.etsi.org/ngsi-ld/DateTime",
…

com.egm.stellio.search.entity.service.EntityServiceQueriesTests ‑ [10] georel=disjoint, geometry=Point, coordinates=[101.0, 0.0], expectedCount=2
com.egm.stellio.search.entity.service.EntityServiceQueriesTests ‑ [11] georel=disjoint, geometry=Polygon, coordinates=[[[100.0, 0.0], [101.0, 0.0], [101.0, -1.0], [100.0, 0.0]]], expectedCount=1
com.egm.stellio.search.entity.service.EntityServiceQueriesTests ‑ [3] georel=within, geometry=Polygon, coordinates=[[[90.0, 0.0], [100.0, 10.0], [110.0, 0.0], [100.0, -10.0], [90.0, 0.0]]], expectedCount=1
com.egm.stellio.search.entity.service.EntityServiceQueriesTests ‑ [4] georel=within, geometry=Polygon, coordinates=[[[80.0, 0.0], [90.0, 5.0], [90.0, 0.0], [80.0, 0.0]]], expectedCount=0
com.egm.stellio.search.entity.service.EntityServiceQueriesTests ‑ [5] georel=contains, geometry=Polygon, coordinates=[[[90.0, 0.0], [100.0, 10.0], [110.0, 0.0], [100.0, -10.0], [90.0, 0.0]]], expectedCount=0
com.egm.stellio.search.entity.service.EntityServiceQueriesTests ‑ [6] georel=equals, geometry=Point, coordinates=[100.0, 0.0], expectedCount=1
com.egm.stellio.search.entity.service.EntityServiceQueriesTests ‑ [7] georel=equals, geometry=Point, coordinates=[101.0, 0.0], expectedCount=0
com.egm.stellio.search.entity.service.EntityServiceQueriesTests ‑ [8] georel=intersects, geometry=Polygon, coordinates=[[[100.0, 0.0], [101.0, 0.0], [101.0, 1.0], [100.0, 1.0], [100.0, 0.0]]], expectedCount=1
com.egm.stellio.search.entity.service.EntityServiceQueriesTests ‑ [9] georel=intersects, geometry=Polygon, coordinates=[[[101.0, 0.0], [102.0, 0.0], [102.0, -1.0], [101.0, 0.0]]], expectedCount=0
com.egm.stellio.search.entity.util.PatchAttributeTests ‑ [1] source={
    "attribute": {
        "type": "Property",
        "value": 12.0,
        "observedAt": "2024-04-14T12:34:56Z"
    }
}, target={
    "attribute": {
        "type": "Property",
        "value": 12.2,
        "unitCode": "GRM"
    }
}, expected={
    "attribute": {
        "type": "Property",
        "value": 12.2,
        "unitCode": "GRM",
        "observedAt": "2024-04-14T12:34:56Z"
    }
}
…

♻️ This comment has been updated with latest results.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud