Incorrect handling geo-queries

[Antiavanti]

Query from client:

/api/v1/collection?query={
    "geometry": {
        "$geoIntersects": {
            "$geometry": {
                "type": "Polygon",
                "coordinates": [[
                    [16.14560058593753,51.307365718453234],
                    [18.02151611328128,51.307365718453234],
                    [18.02151611328128,50.79110589223593],
                    [16.14560058593753,50.79110589223593],
                    [16.14560058593753,51.307365718453234]
                ]]
            }
        }
    }
}

Inside of req._ermQueryOptions:

{
    "query": {
        "geometry": {
            "$geoIntersects": {
                "$geometry": {
                    "type": "Polygon",
                    "coordinates": {
                        "$in": [{
                            "$in": [{
                                "$in": [16.092042236328155,51.35713184352065]
                            },
                            {
                                "$in": [17.967957763671905,51.35713184352065]
                            },
                            {
                                "$in": [17.967957763671905,50.841430047612135]
                            },
                            {
                                "$in": [16.092042236328155,50.841430047612135]
                            },
                            {
                                "$in": [16.092042236328155,51.35713184352065]
                            }]
                        }]
                    }
                }
            }
        }
    }
}

Those $in operators are wrong :)

[Zertz]

Interesting, if you want to take a stab at it, this is happening here.

[Antiavanti]

Currently I'm handling it in pre middleware (change it back only for geojsons).
But adding $in operator in this particular case is just incorrect behavior :)

[Zertz]

Yes I was just pointing out the faulty code, feel free to send a PR :)

[muliyul]

This is confirmed to happen in 4.0.2.

My query:

The result:

[Zertz]

Is the result of sw.lng() and sw.lat() a number?

[muliyul]

I posted the result I'm getting in devtools... so yeah I'm pretty sure. also I double checked.
They are taken straight from the google maps api btw.

[Zertz]

Sorry, I somehow completely overlooked the second screenshot. The issue is that we look specifically for numbers, which should be fixed in is-coordinates.

isNumber(34.7403)
//= true

isNumber("34.7403")
//= false

[muliyul]

Do you have any release date for this?

[Zertz]

Probably sometimes this week, but nothing is set in stone.

[muliyul]

Any news on this issue @Zertz ?

[Zertz]

I've been quite busy lately, though I will take some open-source time Friday and/or this weekend :-)

[muliyul]

I'm counting on you! I've tried to fix it but I couldn't figure out how. By the way I'm not entirely sure this has anything to do with strings as I am sending my data as number and it is verified by the is-coordinates. I'm sending a query with the type param to specify a polygon type query and it looks like the query is being understood by ERM as something entirely different.

[MaxVynohradov]

@Zertz have you any success with this issue? I'm going to use this library, and seems will deal with coordinates.