You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Mongo has a $geoIntersects that I want to use to return all polygons that contains a single point. Unfortunately it only supports 2dsphere indexes and parse-server currently doesn't use geoJson.
Maybe we can reopen #524 to support legacy coordinates (2d) as well as geoJSON (2dsphere) indexes.
We need to introduce a new type to the schéma, i’m all Open for it as Long as we don’t break legacy points. We’ll also need to define those types in the client SDKs!
I've also read the 2dsphere indexes can cover multiple geospatial fields in a document. It might get rid of that MongoDB only supports one GeoPoint field in a class error
You can have multiple geospatial indexes per collection. Unless you are using $geoNear which we aren't using. I just created both on the same collection without problems.
Could the $nearSphere dilemma be solved by adding the equivalent SDK methods for a $geoWithin query? We could have withinCenterSphereRadians and the equivalent withinCenterSphereMiles and withinCenterSphereKilometers convenience methods. Then, for people who wants to use 2dsphere indexes, add in the documentation that the legacy calls to $nearSphere are deprecated? I don't know about adding the indexes… maybe for starters we would have to do that manually?
@madsbwithinCenterSphere doesn't sort like $nearSphere which a lot of applications have sorting. But not sorting leads to faster queries, we can use this as a option for users who don't care about sorting. To get $nearSphere to work with 2dsphere is just changing the mongo transform, using createIndexIfNeeded and updating to geoJSON
You're right about the sorting, I totally missed that (I'm not using sorting either in my app).
Still a bit novice about the whole index 2d/2dsphere thing. Databases are not my strong suit. Would probably be up to @drew-gross or @flovilmart to decide if now is the time to support GeoJSON. My vote is squarely in the 'yes' camp 😄
I closed #4060. I may re-open it at a later point, but I made another pull request (#4064) that I'd prefer to have merged sooner, that allows for basic coordinate pairs in a $polygon query.
Activity
flovilmart commentedon Jun 21, 2017
We need to introduce a new type to the schéma, i’m all Open for it as Long as we don’t break legacy points. We’ll also need to define those types in the client SDKs!
dplewis commentedon Jun 21, 2017
I've also read the 2dsphere indexes can cover multiple geospatial fields in a document. It might get rid of that MongoDB only supports one GeoPoint field in a class error
flovilmart commentedon Jun 21, 2017
Yeah if using polygons obviously :)
dplewis commentedon Jun 21, 2017
Maybe a tool to convert legacy to 2dsphere would help.
flovilmart commentedon Jun 21, 2017
Yeah but that imply migrating data in production more likely, which could be problematic at large scale.
dplewis commentedon Jun 21, 2017
The main issue I see is $nearSphere. I can test for 2d vs 2dsphere but the rest format are different.
2d2dsphereFor polygonContain I could only use geojson for Type Polygon and keep geopoints 2d for now
flovilmart commentedon Jun 21, 2017
Also the indexes are different and I’m not sure you can index the same column 2 2D and 2dsphere
dplewis commentedon Jun 21, 2017
You can have multiple geospatial indexes per collection. Unless you are using $geoNear which we aren't using. I just created both on the same collection without problems.
https://docs.mongodb.com/manual/core/2dsphere/#geonear-and-geonear-restrictions
dplewis commentedon Jul 14, 2017
I'll probably do 2dsphere indexes for legacy GeoPoints at a later date just closing this for now.
madsb commentedon Jul 25, 2017
Could the $nearSphere dilemma be solved by adding the equivalent SDK methods for a $geoWithin query? We could have
withinCenterSphereRadiansand the equivalentwithinCenterSphereMilesandwithinCenterSphereKilometersconvenience methods. Then, for people who wants to use 2dsphere indexes, add in the documentation that the legacy calls to$nearSphereare deprecated? I don't know about adding the indexes… maybe for starters we would have to do that manually?flovilmart commentedon Jul 25, 2017
@madsb do you wanna try adding a PR for it? Which version of mongodb do they start using those indexes?
madsb commentedon Jul 25, 2017
I'll try to take a stab at it. I think $geoWithin queries are supported from version 2.4 and upwards: https://docs.mongodb.com/manual/reference/operator/query/geoWithin/
dplewis commentedon Jul 28, 2017
@madsb
withinCenterSpheredoesn't sort like$nearSpherewhich a lot of applications have sorting. But not sorting leads to faster queries, we can use this as a option for users who don't care about sorting. To get$nearSphereto work with2dsphereis just changing the mongo transform, usingcreateIndexIfNeededand updating to geoJSONWhat do you think?
madsb commentedon Jul 29, 2017
You're right about the sorting, I totally missed that (I'm not using sorting either in my app).
Still a bit novice about the whole index 2d/2dsphere thing. Databases are not my strong suit. Would probably be up to @drew-gross or @flovilmart to decide if now is the time to support GeoJSON. My vote is squarely in the 'yes' camp 😄
madsb commentedon Jul 30, 2017
I closed #4060. I may re-open it at a later point, but I made another pull request (#4064) that I'd prefer to have merged sooner, that allows for basic coordinate pairs in a $polygon query.