Mongo: Fix reversing polygon coordinates

[dplewis]

Closes: #4607

Has been tested on the latest parse-dashboard.

https://docs.mongodb.com/manual/reference/glossary/#term-wgs84

[codecov]

Codecov Report

Merging #4609 into master will increase coverage by 0.06%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #4609      +/-   ##
==========================================
+ Coverage   92.59%   92.65%   +0.06%     
==========================================
  Files         119      119              
  Lines        8562     8566       +4     
==========================================
+ Hits         7928     7937       +9     
+ Misses        634      629       -5

Impacted Files	Coverage Δ
src/Adapters/Storage/Mongo/MongoTransform.js	85.99% <100%> (+0.09%)	⬆️
src/RestWrite.js	93.41% <0%> (+0.36%)	⬆️
src/Routers/PushRouter.js	96.42% <0%> (+3.57%)	⬆️
src/Adapters/Cache/InMemoryCache.js	100% <0%> (+8.33%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c723582...9dfbd6b. Read the comment docs.

[JacobJT]

I'm still not getting the expected results when querying using query.polygonContains('polygonKey', geoPoint); No results are found when the point is definitely inside the polygon. I cloned @dplewis 's repo, switched to the regression-4608 branch, ran npm install and npm run build, then copied the lib folder and replaced the lib folder in my node_modules/parse-server/ folder on my local server I'm using to test.

Example:

This is the polygon object attached to an instance of my class:

[
  [
    42.631655189280224,
    -83.78406753121705
  ],
  [
    42.633047793854814,
    -83.75333640366955
  ],
  [
    42.61625254348911,
    -83.75149921669944
  ],
  [
    42.61526926650296,
    -83.78161794858735
  ],
  [
    42.631655189280224,
    -83.78406753121705
  ]
]

This is the point I'm searching for: (42.624599,-83.770162) (this is a Parse GeoPoint)

The point is definitely within the bounds of the polygon.

I modified my code to create a new Parse GeoPoint with the latitude = original.latitude, and longitude = original.longitude, and I get the expected result.

[JacobJT]

OK, did more testing and it looks like this change modified how Polygons are saved. That's where the coordinate reversal is taking place. So, the Polygon format should be [long, lat], but it was [lat, long].

I created a new instance of a Polygon instead of using the old one and saw that change. The method works as expected.

So, the problem is that this is going to mean that all polygons currently stored are in reverse order, at least for people using mongo (I recall my Postgres tests were still passing when I modified the test case to highlight this error).

[dplewis]

@JacobJT What you see in the dashboard and input into your objects are in lat/lng. The databases are saved as lng/lat.(Postgres already stored at lng/lat)

I didn't realize until today that I haven't updated my dashboard to support type Polygon which is why I missed this issue.

@flovilmart How does this look?

[JacobJT]

The polygon in my comment above was taken directly from the dashboard, and was created using the release version of parse-server. The query using a polygonContains constraint yielded no results when using your parse-server branch.

The polygon value below is created using the same Parse GeoPoints, but created using your parse-server branch. The query now works as expected and returns this object, but the fix is not compatible with old polygon data

[
  [
    -83.78406753121705,
    42.631655189280224
  ],
  [
    -83.75333640366955,
    42.633047793854814
  ],
  [
    -83.75149921669944,
    42.61625254348911
  ],
  [
    -83.78161794858735,
    42.61526926650296
  ],
  [
    -83.78406753121705,
    42.631655189280224
  ]
]

[flovilmart]

this is against the documentation for the GeoPoints,m where the list of corrdinates should be provided as lat,lng pairs, not lng,lat pairs.

http://parseplatform.org/Parse-SDK-JS/api/v1.11.1/Parse.GeoPoint.html

If the storage need to be reveresed, that's another issue but should not for something un natural for the user.

[dplewis]

I wrote it this way to highlight that the input and output are going to be reversed.

The current GeoPoint transform tests are slightly confusing at a glance.

Shouldn't this be testing mongoObjectToParseObject input -> lng/lat output -> lat/lng?

[flovilmart]

OK I misread. Do you have a test that ensures the input / output orders are preserved? ie the mongo transformation is properly applied and reversed?

[dplewis]

@JacobJT Thanks for helping with this one.