Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-13540

The geoNear command no longer returns distance in radians for legacy points

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • 2.6.1, 2.7.0
    • Affects Version/s: 2.6.0
    • Component/s: Geo
    • None
    • ALL
    • Hide
      use test
      db.location.save({"_id":1, "position" : [-74.044628, 40.689182]})
      db.location.save({"_id":2, "position" : [-74.041243, 40.700309]})
      db.location.ensureIndex( {position: "2dsphere"} )
      

      The following commands executed against mongodb 2.4.9 result in:

      > db.runCommand( { geoNear : "location" , near : [-74.045255, 40.702554], spherical : true } ).results[0].dis
      0.00006597925143247339 <- radians
      Note that the last command used a "legacy point"
      
      > db.runCommand( { geoNear : "location" , near : { type : "Point" , coordinates: [-74.045255, 40.702554] } , spherical : true } ).results[0].dis
      420.82226356145856 <- meters
      
      Note that the last command used a GeoJSON Point
      

      The following commands executed against mongodb 2.6.0 result in:

      >  db.runCommand( { geoNear : "location" , near : [-74.045255, 40.702554], spherical : true } ).results[0].dis
      420.82602810248557 <- meters
      Note that the last command used a "legacy" Point but returned meters.
      
      >  db.runCommand( { geoNear : "location" , near : { type : "Point" , coordinates: [-74.045255, 40.702554] } , spherical : true } ).results[0].dis
      420.82602810248557 <- meters
      
      Show
      use test db.location.save({ "_id" :1, "position" : [-74.044628, 40.689182]}) db.location.save({ "_id" :2, "position" : [-74.041243, 40.700309]}) db.location.ensureIndex( {position: "2dsphere" } ) The following commands executed against mongodb 2.4.9 result in: > db.runCommand( { geoNear : "location" , near : [-74.045255, 40.702554], spherical : true } ).results[0].dis 0.00006597925143247339 <- radians Note that the last command used a "legacy point" > db.runCommand( { geoNear : "location" , near : { type : "Point" , coordinates: [-74.045255, 40.702554] } , spherical : true } ).results[0].dis 420.82226356145856 <- meters Note that the last command used a GeoJSON Point The following commands executed against mongodb 2.6.0 result in: > db.runCommand( { geoNear : "location" , near : [-74.045255, 40.702554], spherical : true } ).results[0].dis 420.82602810248557 <- meters Note that the last command used a "legacy" Point but returned meters. > db.runCommand( { geoNear : "location" , near : { type : "Point" , coordinates: [-74.045255, 40.702554] } , spherical : true } ).results[0].dis 420.82602810248557 <- meters

      Issue Status as of April 17, 2014

      ISSUE SUMMARY

      In 2.4 the geoNear command returned the distance in radians for legacy coordinate pairs. In 2.6, this behavior changed and the geoNear command returned the result in meters. This behavior change was unintentional and needs to be reverted.

      USER IMPACT
      Users that have their data stored in legacy coordinate pairs (rather than in GeoJSON format) and who use the geoNear command get the results back in an unexpected unit, which may break their applications.

      WORKAROUNDS
      A client-side rescaling of the result back from meters to radians can be used as a workaround.

      RESOLUTION
      Revert the behavior change and return the result in radians again if the coordinates are stored in legacy format.

      AFFECTED VERSIONS
      Version 2.6.0 was affected by this bug.

      PATCHES
      The patch is included in the 2.6.1 production release.

      Original description

      It seems that the distance metric for handling legacy points has changed from mongodb 2.4.x to 2.6.0.

      Previously the distance in geoNear queries for legacy points was returned as radians - since 2.6.0 it is now returned in meters. Since this behaviour is not listed in the incompatibility / changes list and could be seen as a breaking change I suppose that this is a bug.

      See also here:
      https://jira.spring.io/browse/DATAMONGO-906

            Assignee:
            greg_10gen Greg Studer
            Reporter:
            thomasd Thomas Darimont
            Votes:
            1 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved: