[SERVER-34766] Allow $expr or $$field in the $geoNear stage Created: 01/May/18  Updated: 05/Dec/22  Resolved: 16/Nov/22

Status: Closed
Project: Core Server
Component/s: Aggregation Framework
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Travis Brown Assignee: Backlog - Query Optimization
Resolution: Duplicate Votes: 24
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
duplicates SERVER-58604 Allow $geoNear 'near' argument to be ... Closed
is duplicated by SERVER-54105 $geoNear in $lookup with dynamic coor... Closed
is duplicated by SERVER-67149 $geoNear in $lookup with dynamic coor... Closed
Related
related to SERVER-9606 $cond operator should allow $match as... Backlog
related to SERVER-49953 allow $expr as RHS expression in regu... Closed
is related to SERVER-47218 Geo-spatial $lookup Closed
is related to SERVER-37675 Allow $geoWithin and $geoIntersects t... Backlog
is related to SERVER-38198 Remove the requirement that $geoNear ... Closed
Assigned Teams:
Query Optimization
Participants:
Case:

 Description   

When trying to use a $lookup with pipeline and a $geoNear stage, there is no way to pass an argument in the let field into the $geoNear stage.

e.g.

{ 
            "$lookup" : {
                "from" : "regions", 
                "let" : {
                    "point" : "$location"
                }, 
                "pipeline" : [
                    {
                        "$geoNear" : {
                            "spherical" : true, 
                            "maxDistance" : 10000.0, 
                            "distanceField" : "distance", 
                            "uniqueDocs" : true, 
                            "near" : "$$point"
                        }
                    }
                ], 
                "as" : "regions"
            }
}



 Comments   
Comment by Jens Ehlers [ 16/Nov/22 ]

I can acknowlege that it works as documented here in version 6.0.

Comment by Yoni Heiblum [ 06/Sep/22 ]

Was this issue solved in version 5.1 + version 6.0?  In the documentation for version 6.0 it appears that it's supported.

Comment by Barys Ilyushonak [ 27/May/19 ]

Hi everybody, we are also affected by this issue. Could you provide an update about the future of the ticket? 

Comment by Jim Blackhurst [ 13/Feb/19 ]

would geoWithin support this too?

Comment by Ashish [ 13/Feb/19 ]

@Asya Kamsky `near` should accept the `$expr`

Comment by Romano [ 31/Jul/18 ]

Same problem for me. There is a trick to do this or no?

Comment by Asya Kamsky [ 04/May/18 ]

$expr can only be used as a top level expression in a match stage, and there is no way to express geoNear condition in aggregation syntax - SERVER-9606 describes the issue.

 

Comment by Travis Brown [ 03/May/18 ]

The $expr expression also appears to not function in the query parameter of this stage.

Comment by Travis Brown [ 01/May/18 ]

Some extra information on things I tried

{
   $geoNear:{
      $expr:{
         spherical:true, 
         maxDistance:10000, 
         uniqueDocs:true, 
         near:"$$point"
      }
   }
}

Which results in `"$geoNear requires a 'near' option as an Array"`

and

{
				$geoNear: {
					spherical: true,
					maxDistance:10000,
					uniqueDocs: true,
					near: {$expr:"$$point"},
					distanceField:"distance"
				}
			}

Which results in `near must be a point`

Generated at Thu Feb 08 04:37:47 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.